Subject: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Wed, 07 Feb 2018 06:34:40 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This draft seems generally sound, but I believe there are pieces that
are still underspecified. These should be easy to fix.

the Signer's Name field in canonical form and the signature field
   excluded.

IMPORTANT: I'm not sure that this is actually sufficient to allow an
independent implementation without referring to the other documents. I
mean, I think I pretty clearly can't validate this chain from the
above. Similarly, although I think this is enough to break apart the
RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
each other. I think you need to either make this a lot more complete
or alternately stop saying it's sufficient.

   abort the connection, the server uses the domain name associated with
   the server IP address to which the connection has been established.
IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple names for the same IP.

   DNSSEC authentication chain extension from a server, SHOULD use this
   information to perform DANE authentication of the server.  In order
   to do this, it uses the mechanism specified by the DNSSEC protocol

IMPORTANT: What happens if the DANE validates but the cert is revoked
or alternately the cert validates but DANE does not?

[RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
   DNSSEC validation engine or library.
IMPORTANT: shouldn't it be a requirement to perform this validation?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

typically not be used for general DNSSEC validation of TLS endpoint
   names.
Can you rephrase this. I *think* it means "it's not used to validate the A/AAAA
lookup"...?

   validation of endpoint names, but is more appropriate for validation
   of DANE TLSA records.
Same comment as abive

   This mechanism is useful for TLS applications that need to address
   the problems described above, typically web browsers or VoIP and XMPP
   applications.  It may not be relevant for many other applications.
Nit; cites to SIP/XMPP appropriate here,

   ClientHello message that the DNS authentication chain be returned in
   the (extended) ServerHello message.  If the server is configured for
   DANE authentication, then it performs the appropriate DNS queries,
This is not correct for TLS 1.3.

3.1.  Protocol, TLS 1.2
You should probably provide some guidance about whether the server should still
provide the whole X.509 chain to the client. I believe with these semantics,
the server cannot tell which DANE mode the client wants and therefore has to
provide the entire chain.

   Servers receiving a "dnssec_chain" extension in the ClientHello, and
   which are capable of being authenticated via DANE, MAY return a
   serialized authentication chain in the extended ServerHello message,
Nit: I believe you want to remove the commas here, as they indicate a
nonrestrictive clause.

   arbitrary domain names using this mechanism.  Therefore, a server
   MUST NOT construct chains for domain names other than its own.
"its own" is a bit fraught, as servers may not actually know all their domain
names, at least at the TLS layer.. Can you be more specific about what the
server algorithm is.

   Servers receiving a "dnssec_chain" extension in the ClientHello, and
   which are capable of being authenticated via DANE, SHOULD return a
   serialized authentication chain in the extension block of the
Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below is a
MAY?

   to a DNSSEC trust root.  This has the added benefit of mitigating an
   unknown key share attack, as described in [I-D.barnes-dane-uks],
   since it effectively augments the raw public key with the server's
"unknown key share (UKS)"

   handshake, to a domain name which has been validated as belonging to
   the owner name.
The key point here is that the commitment is bound to the EE key. Also, this
only really works for TLS 1.3 and modes with EMS because otherwise there are
other UKS attacks

I think you probably want to cite SIGMA and triple handhshake here.

             opaque AuthenticationChain<0..2^16-1>
Is 0 actually appropriate here as a lower bound? Presumably at least one such
instance must be present?

             RR(i) = owner | type | class | TTL | RDATA length | RDATA
I assume the notation here is "i is the ith RR"?

Is there a reason not to describe this in TLS language?

             . DNSKEY
             RRSIG(. DNSKEY)
How does this differ from the algorithm that you would use in response to the
TLSA query?

   the draft is adopted by the WG, the authors expect to make an early
   allocation request as specified in [RFC7120].
Do you want this to be marked RECOMMENDED?

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Feb 2018 09:18:36 -0500

> draft-ietf-tls-dnssec-chain-extension-06: Discuss

Thanks Eric for your detailed review and comments.

> above.

We could add an explicit reference here to the DNS protocol document(s)
and sections within them that define the canonical form of domain
names (RFC 4034, Section 6 probably is the best reference), or even
excerpt the relevant text from that document. Would this satisfy your
concern?

We deliberately didn't include in this document a detailed description
of the DNSSEC validation algorithm. The algorithm is sufficiently
complicated (and lengthy to describe) that those details are best left
to the relevant DNSSEC RFCs. I think it would be helpful to point
specifically to which documents and sections here though (mainly
RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a
brief synopsis of the algorithm and refer to these documents for
further details.

Otherwise, can you suggest more specifically what level of additional
detail you'd like to see in this document?

> Similarly, although I think this is enough to break apart the

We can add some text about this. Basically the client would scan the chain
reading RRs and group adjacent RRs that share the same RR name, type, and
class into a distinct RRset.

> IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple
names for the same IP.

Yes, indeed. This sentence is dealing with the case where the client has
not indicated to the server which name it wants to connect to, so the
server is basically guessing anyway. Perhaps we could reword this to say
something like, "the server picks one of its configured domain names for
the associated IP address".

(This situation could also have been avoided by mandating client use of
the SNI extension).

> or alternately the cert validates but DANE does not?

This depends on the mode of DANE in use (i.e. the Certificate Usage
field of the TLSA record). If I recall correctly, this should all be
covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").

* With DANE-EE, only the EE certificate is matched against the
  certificate data/hash in the TLSA record. There is no CRL/OCSP
  style revocation. Revocation would be performed by removing the
  TLSA record from the DNS.

* With DANE-TA, the indicated CA certificate referenced in the TLSA
  record may have advertised revocation mechanisms that need to be
  consulted.

* With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms
  need to be consulted and honored.

Would you like us to discuss this in the draft? Or is referring to
RFC 7671 sufficient?

On your last case, "cert validates but DANE does not", I assume
you mean the cert validates via PKIX but not DANE? I'm not sure this
is explicitly discussed in any other DANE document but presumably
if DANE is being used, DANE must validate. I suppose individual
application protocols could specify a fallback mode where the
client could fallback to normal PKIX if DANE failed.

On a related note, I believe most envisioned use cases of this draft
will be for the DANE-* modes. The PKIX constraining modes have the
issue that for them to work securely, the client must be able to
confirm the presence of DANE records, which leads to the issues of how
to mandate use of this mechanism (Section 8 of this document).

> IMPORTANT: shouldn't it be a requirement to perform this validation?

Your question I assume is about the sentence preceding this:

   "A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, SHOULD use this
   information to perform DANE authentication of the server."

Yes, I think I agree. If the client is using this spec, then presumably
it intends to use DANE if available. So this should be a "MUST".

Yes, that makes it clearer (and is it what it means). We'll reword.

>    validation of endpoint names, but is more appropriate for validation

Ok.

> Nit; cites to SIP/XMPP appropriate here,

Ok.

> This is not correct for TLS 1.3.

Right, this text predated TLS1.3 ..

The TLS version-specific protocol elements involved in delivering this
extension are described in Section 3. For the Introduction section from
which the above text is excerpted, I would suggest the following rewrite:

   The extension described here allows a TLS client to request that
   the TLS server return the DNSSEC authentication chain corresponding
   to its DANE record. If the server is configure for DANE ...

> provide the entire chain.

Sure, we can elaborate.

The DANE mode to be used is advertised by the server in its TLSA record(s),
so the server already knows whether it needs to return the X.509 chain.
If the TLSA RRset has only DANE-EE, then only the end-entity certificate
needs to be returned. If DANE-TA, then only the chain from the TA cert to
the
EE needs to be returned. If using the PKIX modes, then yes, the entire X.509
chain has to be sent.

> Nit: I believe you want to remove the commas here, as they indicate a

Ok.

> names, at least at the TLS layer.. Can you be more specific about what the

To implement this specification, the TLS layer does need to have
preconfigured knowledge of the names for which it has DANE records.

This text is also a bit imprecise and should be improved anyway. The
server doesn't construct chains for its own domain name, but rather
the TLSA record name corresponding to that domain name. This domain
name is either one explicitly indicated by the client via SNI (assuming
that the indicated name is one the server recognizes as its own),
or if no SNI is provided, one that the server picks from its known
set of names (as discussed previously).

The purpose of the MUST NOT sentence here is to prevent clients from
using the TLS server to lookup arbitrary domain names.

> Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below
is a

They should clearly be consistent. My preference would be "SHOULD" for
both.

> only really works for TLS 1.3 and modes with EMS because otherwise there
are

Ok, we will clarify this.

> I think you probably want to cite SIGMA and triple handhshake here.

Ok.

> instance must be present?

Yes, there should be a non-zero number of bytes in the extension data.
So: opaque AuthenticationChain<1..2^16-1>

> I assume the notation here is "i is the ith RR"?

Yes, we can mention that.

> Is there a reason not to describe this in TLS language?

I think because the extension data contains only a sequence of DNS wire
format RRs which are precisely defined in DNS documents, and we felt it
was redundant to redefine them in another format.

> How does this differ from the algorithm that you would use in response to
the

Sorry, I don't follow your comment here. Differ from what? Can you
elaborate?

> Do you want this to be marked RECOMMENDED?

In response to Mirja's earlier comment, I think we are taking out this
sentence.

Shumon Huque

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Feb 2018 06:49:16 -0800

> excerpt the relevant text from that document. Would this satisfy your

Well, and remove your text about it being possible to implement solely from
this
document.

> brief synopsis of the algorithm and refer to these documents for

It's not the algorithm. I don't believe this document is sufficient to
parse the
structure.

> detail you'd like to see in this document?

See above.

> class into a distinct RRset.

I'd have to review your text to know if it was sufficient.

> the associated IP address".

Yes, that would be fine.

>   need to be consulted and honored.

Well, neither of these modes is useful here, as an attacker will simply
ignore the
extension.

> RFC 7671 sufficient?

I think you should discuss it in the draft as it is relevant to TLS
implementation.

> if DANE is being used, DANE must validate.
>

Why would that be so? This only is useful in DANE-EE and DANE-TA modes in
the first place, and so there is a possibilityt aht PKIX is valid.

 note, I believe most envisioned use cases of this draft
> to mandate use of this mechanism (Section 8 of this document).

Yes, I don't think those modes are useful here.

>    to its DANE record. If the server is configure for DANE ...

Yes, this is fine.

> EE needs to be returned. If using the PKIX modes, then yes, the entire

The problem is that the client is the decider about what it wants to
accept, not
the server.

> using the TLS server to lookup arbitrary domain names.

OK. Well, perhaps some better text is needed here.

> They should clearly be consistent. My preference would be "SHOULD" for

That's a WG decision.

> Sorry, I don't follow your comment here. Differ from what? Can you

You provided an algorithm for how to construct responses. How is it
different from the
algorithm that the  name server would  use to respond to a query for the
TLSA record.

> In response to Mirja's earlier comment, I think we are taking out this

You're still registering the code point, so you need to determine if it's
RECOMMENDED or not.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Feb 2018 11:35:51 -0500

> On Feb 8, 2018, at 9:49 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Well, neither of these modes is useful here, as an attacker will simply ignore the
> extension.

Good point.

Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service
certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is
precisely because they believe that PKIX alone is not enough, and
would like to require at least one of the specified constraints to
be satisfied.

So if the records do make it to the client, the client should
probably honour them if it is doing DANE-based authentication.

However, as you correctly observe, with this in-band TLSA record
delivery mechanism, an attacker who is able to able PKIX-verifiable
certificates and keys for the target domain can simply not respond
with the extension and deliver just the PKIX key material.  So if
a client is willing to go with just PKIX for servers that don't
support the extension, then it subject to a "dane-stripping"
downgrade attack when using this mechanism.

We should also note that clients might cache the obtained TLSA
records, and so might not accept just PKIX while cached records
are available, even if TLSA records are stripped on a subsequent
connection.

But the key question boils down to whether the client is configured
to *require* DANE for the connection (in which case just PKIX is
clearly not enough), or whether it is doing a form of "opportunistic
DANE" (for lack of a better term in this message) with the server
optionally providing the records, but otherwise the client resorts
to using just PKIX.

In the "opportunistic DANE" case one might argue that, when PKIX-TA(0)
or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client
should accept PKIX alone, since a downgrade attack can typically strip
DANE.  But if the client is caching previously seen TLSA records, then
the downgrade attack is partially mitigated (for the TTL of the cached
records).  The client may elect to request new TLSA records before the
expiration of the previous ones are expired, extending such protection
until it stops communicating with the server sufficiently regularly to
be able to keep a copy of unexpired TLSA records in its cache.

So all in all, I think there may be enough merit in rejecting on DANE
failure, subject to local policy, but the client might elect to trust
bare PKIX.

For clients that do reject PKIX success based on DANE failure, and
cache obtained TLSA records, it might have been good to recommend
refreshing the TLSA records while the cached data is still valid
(say the smaller of some refresh time or 50% of TTL has expired).
That way, for a client that keeps communicating regularly may be
(partially) protected against downgrades.  Perhaps it is too late
to make such a change at this stage in the document's life-cycle.

Summary as I see it:

  * Mandatory DANE:
 MUST Refuse absence of TLSA RRs or failure
    of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
    are cache and the server does not present the extension.

  * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
    if caching replies, and SHOULD attempt to refresh cache before
    expiration to reduce opportunity for downgrades.  Non-caching
    clients don't really gain security by refusing valid PKIX on
    DANE failure, and MAY choose to continue.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Feb 2018 16:47:25 -0800

Yeah this doesn't seem unreasonable

-Ekr

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Feb 2018 10:52:38 -0500

Sorry for my belated follow-up. Was temporarily overwhelmed by the
day job ..

> Well, and remove your text about it being possible to implement solely
from

Yes, I agree, we need to remove that.

> It's not the algorithm. I don't believe this document is sufficient to

Okay, got it. For people that have already implemented this, I think
there has been an implicit understanding that the format of the chain
data is a sequence of concatenated wire format RRs exactly as they appear
in a DNS message section (with one injunction against doing DNS name
compression). I'll write some text to make this more explicit and describe
the format in more detail with references to the appropriate DNS specs.

This is also the format that is readily generated and consumed by some
DNS libraries and the Intro section of this document has the following
assumption: "... (assuming that the data will be prepared and consumed
by a DNS-specific library) ..."

> I'd have to review your text to know if it was sufficient.

Ok. I'm working on text for this ..

> Well, neither of these modes is useful here, as an attacker will simply

Just to confirm, I assume the attacker here is an entity attempting
to impersonate the TLS server (with presumably valid PKIX credentials).
If so, yes it can trivially ignore the extension, but this is the case
for any DANE usage mode (not just the PKIX constraining ones).

As discussed in Section 8, the protocol as currently specified really
only allows opportunistic DANE authentication, unless some mechanism
external to TLS is employed to mandate DANE usage. (The protocol could
be extended to require TLS servers to also provide a DNSSEC proof that
they don't have a signed TLSA record, but that could only be deployed
in a TLS application system where all servers supported this extension).

> the first place, and so there is a possibilityt aht PKIX is valid.

I think Viktor's earlier reply to this thread goes into detail about
possible
client behaviors here and what we might recommend (which seems reasonable
to me). I'll follow-up there.

> The problem is that the client is the decider about what it wants to

My comment was about what DANE mode choices the server is offering to
the client. Certainly, the client can decide whether it wants to use
DANE or not, and whether it wants to fallback to PKIX. The protocol
should probably not be proscriptive here, and allow different TLS
applications (or configurations of such applications) to make choices.
But maybe there are some general recommendations to be made.

One additional comment about PKIX fallback on DANE failure: If a
server is using DANE-EE or DANE-TA, it has the ability to send back
a much shorter Certificate message - just the EE certificate for the
former, and typically a very short X.509 chain for the latter. But
this means that for fallback to PKIX, the client would have to start
a new handshake omitting the dnssec_chain extension. For efficient
fallback within the same handshake, the server would always have to
send back the full PKIX X.509 chain. Maybe that's what we need to
recommend for servers that support both DANE and traditional PKIX.

> OK. Well, perhaps some better text is needed here.

Fair enough. I'll propose some new text to make this clear.

> > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and
below
> > They should clearly be consistent. My preference would be "SHOULD" for

Ok. Let me know how you want to handle this question. I'd be happy to
send a separate note to the WG list about it.

> algorithm that the  name server would  use to respond to a query for the

Well, the algorithm the DNS server (specifically a DNSSEC aware
resolver) uses is the DNS iterative resolution algorithm - the TLS server
would just treat that as a blackbox (unless it implemented its own
resolver).

I think the more important question is how the TLS server issues a
sequence of queries to the resolver to obtain the data it needs to
construct
the dnssec chain, and then extracts the corresponding RRsets from the
responses to those queries.

Section 4 (paragraphs 4 through 6) describe that process. Again, we could
go into more detail here, but we were working with the assumption in the
intro ( ".. the data will be prepared and consumed by a DNS-specific
library.")

> You're still registering the code point, so you need to determine if it's

Sorry for being dense - this protocol requires a new codepoint. Do we
need to say we RECOMMEND that a new code point be registered?

Or are you asking that we RECOMMEND that IANA allocates our preferred
extension type value (53)?

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Feb 2018 10:57:31 -0500

>     DANE failure, and MAY choose to continue.

This seems reasonable to me too.

Shumon

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Feb 2018 12:05:51 -0500

> On Feb 21, 2018, at 10:57 AM, Shumon Huque <[email-masked]> wrote:
> 
> On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni <[email-masked]> wrote:
> 
> Summary as I see it:
> 
>   * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure

Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to
consider failure to satisfy the usual PKIX verification requirements
for these certificate usages. Naturally, mandatory DANE can also be
satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken
DANE-TA(2) or DANE-EE(3).

> This seems reasonable to me too.

Here too, a client MAY choose to fail when the presented certificate
chain fails all the associated (cached or freshly obtained) DANE TLSA
records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture.
The restricted focus on just PKIX-TA/PKIX-EE is not needed.

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Feb 2018 12:30:52 -0500

> DANE-TA(2) or DANE-EE(3).

Yup, I understood, but thanks for clarifying ...

> The restricted focus on just PKIX-TA/PKIX-EE is not needed.

Yes, no need to restrict such a policy choice to only the PKIX-* modes.

Shumon.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Feb 2018 09:51:38 -0800

> by a DNS-specific library) ..."

Sure. I'm not arguing that this is a bad format. It's just a matter of
making
clear to the user what they have to do to parse it.

> for any DANE usage mode (not just the PKIX constraining ones).

Agreed. It's just a less useful form of attack for the DANE modes where
you are authenticating with DANE only, as it's basically just a form of DOS.

> in a TLS application system where all servers supported this extension).

I agree.

> recommend for servers that support both DANE and traditional PKIX.

That would be my proposal, but I think at least you need to provide the
kind of analysis you do here.

> send a separate note to the WG list about it.

Sorry, I didn't mean to discount your view. I meant that I didn't think it
was
role to say which one it should be.

This is actually a question for the chairs and the AD (Kathleen). If they
think the
WG decided this, then you can just do "SHOULD". If they think it requires WG
consultation, then you should do that

> intro ( ".. the data will be prepared and consumed by a DNS-specific

OK.

> extension type value (53)?

No. There is a column in the code point assignment for IANA that says
whether the IETF recommends the use of this extension or whether we're
just assigning the code point but don't recommend it. So you need to say
which one it is. I assume the WG wants "Recommended"

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Feb 2018 14:21:34 -0500 (EST)

> to make such a change at this stage in the document's life-cycle.

Is it customary for TLS clients that do PKIX validation to check the
certificate expiry for long lived TLS connections?

I assumed most TLS clients verification is done at the start of the
connection only and the connection is then deemed verified until it
closes - irrespective of the signature lifetimes of the certificate?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 21 Feb 2018 14:48:08 -0500 (EST)

On Wed, 21 Feb 2018, Shumon Huque wrote:

> in a DNS message section

Note, I would not call it "sequence of concatenated wire format RRs", as
it is simply the wireformat of a DNS message. The fact that some parts
are concatenated RR's is just part of the wireformat of the DNS reply
message. That is, this isn't introducing some new form of concatenated
content - it is _just_ a regular DNS wire format message, and the
document should not go deeper into its explanation.

I noticed some discussion about the ordering of this content. I am not
sure why that should be done. DNS doesn't care about the order, and
neither should producers or consumers of this extension. DNS has no
ordering inside its message. In pseudo code, they should simply:

while(not stuck and not empty(RRlist)):
 	stuck = True
 	for each RR in RRlist:
 		if validated_with_cache(RR):
 			add_to_cache(RR)
 			remove_from_RRlist(RR)
 			stuck = False

And then the order of RRs doesn't matter.

I don't think getting unrelated DNSSEC records would be an issue. TLS
has its maximum sizes for the handshake. In fact, it could allow the
extension to have some useful data in the case of MX or SRV.  (and could
be a feature to build a nice resolver over TLS using 1 tor circuit)

I'm also not sure about the talking of unsigned CNAME records from
DNAME. The above pseudo code (extended with special cases) should be
in some DNS library, and that library will know what records to expect
unsigned which are proven by the DNAME (or wildcard) synthesis and knows
when/if to add it to the validated cache. I don't think that should be
explained in this RFC at all. The DNS implementation does not need
to be specified in this document and it should just focus on saying
that "the DNS message response is validated and upon validation the
content can be considered DANE validated".

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Feb 2018 14:52:09 -0500

> On Feb 21, 2018, at 2:21 PM, Paul Wouters <[email-masked]> wrote:
> 

The text you're responding to is NOT about long-lived TLS connections,
rather it addresses the case where the client makes repeated connections
frequently enough to benefit from caching previously obtained TLSA
records for verifying future connections.  In that case it makes sense
to "refresh" the TLSA records (include the extension in a new request)
even before the previously cached data has expired.

> closes - irrespective of the signature lifetimes of the certificate?

Correct, but not applicable to the topic at hand.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Feb 2018 13:30:38 -0800

> closes - irrespective of the signature lifetimes of the certificate?

To the best of my knowledge you are correct.

-Ekr

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 22 Feb 2018 10:44:50 -0500

On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <[email-masked]> wrote:

> it is simply the wireformat of a DNS message.

The fact that some parts
> document should not go deeper into its explanation.

It would _not_ be correct to say that this is a "DNS wire format message" -
that
would mean there is a DNS header section with flags and response codes,
and other sections. The chain data structure as currently specified really
is
concatenated wire-format RRs (as they appear _within_ a DNS message
_section_). Let me know if that is unclear in the draft (or my proposed
edits).

I recall at one point way back there was a discussion about whether the
chain
data should just be a fully formed DNS message, but I don't believe that
idea
had much support in the working group (personally I would have been fine
with
that choice too, if it did have support).

> ordering inside its message.
>

Yes, that is in fact where we ended up, roughly.

The draft does currently say that the answer record(s) appear first. And
then
the authentication chain records follow and that TLS client should be
prepared
to receive the authentication chain records in any order.

Requiring the answer records first seems logical to me - it is what
existing
libraries do, and also what the EDNS chain query spec does (answer records
appear first in the ANSWER section, and DNSSEC authentication chain records
appear in the AUTHORITY section in any order).

There is some residual wording in the draft about ordering of CNAMEs etc in
the answer records part. Assuming the WG agrees, I am fine with relaxing
that requirement - that ended up in there because although there is no
defined
ordering of RRs within a DNS message section, as a practical matter CNAMEs
are almost always ordered since there are some DNS queriers that get
confused
otherwise. This is a new protocol though, so we can be more faithful to the
DNS
spec.

> be a feature to build a nice resolver over TLS using 1 tor circuit).
>

The draft currently doesn't address the MX or SRV use case. I suggest
that we tackle that in a future version.

> content can be considered DANE validated".

Where we ended up, is that WG participants asked for some level of DNSSEC
detail to be included in this doc.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 22 Feb 2018 11:11:06 -0500

> kind of analysis you do here.

Okay, I'll include that analysis and recommendation.

Ok.

> which one it is. I assume the WG wants "Recommended"

Ah, got it. Since the WG adopted this document, "Recommended" would
be my assumption too.

I'll start making edits based on issues/comments raised in this thread in
the github
repo, if folks want to follow along, and/or participate:

    https://github.com/tlswg/dnssec-chain-extension

I'll circle back on list when it's ready for review ..

Shumon.

---

From: Willem Toorop <[email-masked]>
Date: Fri, 23 Feb 2018 11:49:02 +0100

Op 22-02-18 om 16:44 schreef Shumon Huque:
> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> It would _not_ be correct to say that this is a "DNS wire format
> message" - that 
> and other sections. The chain data structure as currently specified
> really is 

A DNS message is a 12 octet header followed by a question, followed by a
list of RRs.  The header does not contain any relevant information with
respect to the chain query.  The question is unnecessary, because only a
TLSA record for the name and port of the service (or a secure path from
the name of the service, via CNAME or DNAME to the name of the TLSA
RRset), is acceptable for a client, so a client would have to disregard
the question in a DNS message anyway.  The list of RRs remains and is
sufficient for the DNSSEC chain extension.

A response of a rfc7901 EDNS chain query can be used almost directly as
the content for the extension.  You just have to strip/skip the
irrelevant data from the front of the message (i.e. the 12 byte header,
the query name and 8 octets type/class/ttl).

> otherwise. This is a new protocol though, so we can be more faithful to
> the DNS 
> spec.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 26 Feb 2018 09:26:59 -0500 (EST)

On Thu, 22 Feb 2018, Shumon Huque wrote:

> It would _not_ be correct to say that this is a "DNS wire format message" - that 
> and other sections. The chain data structure as currently specified really is 
> _section_). Let me know if that is unclear in the draft (or my proposed edits).

So it was decided to not use a full DNS packet format? And then since you
miss the structure of the Answer Section and Additional/Authority
Section, you require the "answer RR's" come first where you basically
emulate an Answer Section?

Isn't that an indication that we should really use the wireformat of an
entire DNS message here? Maybe some DNS library/tools people can chime
in here to tell us if this matters much to them (assuming they are
adding support for creating/consuming these chains of RRsets in wire
format.

I am personally a little sad we cannot have a dig +chainquery command
where we write out the entire answer packet format to a blob, to be loaded by
the TLS server. And where a TLS client cannot just hand over the blob
"as if it came in as a reply from a DNS server" to its DNS/cache
receiving code path.

> I recall at one point way back there was a discussion about whether the chain
> data should just be a fully formed DNS message, but I don't believe that idea
> had much support in the working group (personally I would have been fine with 

Do you remember why not? I'll see about checking the archives, but to me
the hint that you are losing information and require some kind of
ordering seems to suggest there is a need for using the full DNS message
reply format.

> that requirement - that ended up in there because although there is no defined
> are almost always ordered since there are some DNS queriers that get confused 
> otherwise. This is a new protocol though, so we can be more faithful to the DNS 
> spec.

I would prefer the residual wording to go away. Any hints at order being
important should be squashed.

> that we tackle that in a future version.

Jus make sure the document doesn't forbid any such data, and allow the
client to ignore these or put them in the cache as it sees fit.

> detail to be included in this doc.

Again, that will only lead to bad implementations. There should be no
need to update this document once something like ANAME, ALIAS or ZNAME
is introduced to the DNS. So you should not talk about these things at
all. TLS client should use a dns library that knows these things, or if
they want to write one from scratch, these implementors should look at
the DNS RFCs and not this RFC for guidance on how the DNS protocol
works.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 26 Feb 2018 12:20:36 -0500

> On Feb 26, 2018, at 9:26 AM, Paul Wouters <[email-masked]> wrote:
> 

The latter would require compression support on the receiving side, which
has been specifically excluded so far.  I am not against making the data
more compact, though it is rather late in the process, but I have a more
pressing issue.

I think that as it stands, lack of authenticated denial of existence is
a *fatal* flaw in the protocol.  I just don't see a sufficiently practical
scenario in which this extension confers a useful security benefit.

Perhaps this draft should go back to the working group, to consider a new
protocol element, by which the server commits to support the extension for
a time that is substantially longer than the underlying DNS TTLs.  During
this time (suggested to be weeks or months, when in production after initial
testing), the server MUST support the extension and respond with EITHER a
valid TLSA RRset chain, or with a valid denial of existence.

The protocol, thus extended, can then be seen as a more robust form of key
pinning, in which pins are stored server-side, and only the fact that
pinning is expected is stored client-side (for any length of time, the
client may still do short-term caching of TLSA RRs based on the DNS TTL).

The protocol is still subject to downgrade (to PKIX) on first contact,
but is this a common element of all protocols that bootstrap security
on first use.  Indeed the WebPKI itself is largely TOFU as most certs
(which are predominantly DV certs) are issued by CAs based on rather
weak initial evidence.

-- 
	Viktor.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Feb 2018 08:34:23 -0600

> scenario in which this extension confers a useful security benefit.

It of course would not be a fatal flaw if the document was targeting
Experimental status, but I do not have the sense that the authors wish
to make that switch.

> client may still do short-term caching of TLSA RRs based on the DNS TTL).

There doesn't seem to be much interest in pinning-like schemes for TLS
at this point (see also the "TLS server identity pinning" proposal from
the SAAG/secdispatch session at IETF 100).
And I do think the lack of authenticated denial of existence is
something the WG was aware of during our earlier discussions, so it's
unclear that there is a need to hold things up for this issue.

-Benjamin

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Feb 2018 10:12:15 -0500

> On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

Awareness of is different from thinking through the full implications.
I for one did not have the cycles to consider all the implications,
and many others likely also focused on the data format, and may not
have considered the use-cases with care.

Note that DANE-based "pinning" is fundamentally different from other
"pinning" approaches, in that the client does not store the key
digests for any significant length of time.  All it may do is
cache the DANE TLSA records for a short time bounded by the DNS TTL.
The digests that "pin" the server's (or issuing CA's) keys are managed
in the server's DNS zone, and can be promptly updated by the server,
and the client can learn of the change when presented with new TLSA
records, OR as I now believe is essential for this specification to
be at all useful, presented with authenticated denial of existence.

The only thing needed for denial of existence to be workable, is
that the client cache a commitment by the server (a boolean value)
to support the extension until such time as the server provides
authenticated denial of existence of TLSA records.

This is much less brittle than client-side key pinning, with all
its attended problems with stale data.

If this protocol has no denial of existence, I don't see any reason
for anyone to deploy it.  Why publish something that's basically
useless?

-- 
	Viktor.

---

From: Willem Toorop <[email-masked]>
Date: Tue, 27 Feb 2018 16:47:24 +0100

> for anyone to deploy it.  Why publish something that's basically

Well.. support of the option could be obligatory for new TLS services,
like DNS over TLS.  With DNS over TLS there is no user interaction
making third-party PKIX (i.e. a CA store) impractical.

Another possibility to authenticate DNS-over-TLS upstreams by clients,
is to setup the TLS without authentication, and then use that to do the
DANE queries over it (for privacy and to bypass hampering middle-boxes),
then authenticate the certificate and upgrade the connection to be
usable for all queries.  This works but is harder to implement and
causes a latency penalty because of the extra negotiations.

Note that the new initial draft (not WG yet) for encrypting the path
from the recursive to the authoritative, suggests DANE authentication of
the authoritative, and references the tls-dnssec-chain-extension draft
as the initial method -of acquiring the needed DNSSEC data- to try:

https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth

Also, with DANE I like the fact that a DNS domain holder/owner can vouch
for it's own domain name instead of needing a third party.  And
although, opposed to DANE over DNSSEC, this extension doesn't add any
security, it still has that property.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Feb 2018 10:59:00 -0500

> scenario in which this extension confers a useful security benefit.

Viktor,

Is this a new realization you've recently arrived at? You've been
commenting on this draft for a number of years now, and I have
assumed that you were well aware of the lack of authenticated denial.
In fact, there is text in the Intro section that declares that
this protocol is unsuitable for SMTP/DANE precisely because it
requires confirmation of the existence or not of the TLSA record -
that text came about because of discussion with you.

Several of us were well aware of this during the early days of the
draft, but perhaps many folks did not fully appreciate the impacts
until I elaborated on them last year, and added text that described
the "adversary with fraudulently obtained PKIX credentials" attack.

It is certainly a limitation/flaw. Whether or not it is fatal is
debatable. What this means is that this protocol allows opportunistic
use of DANE authentication, but guarantee of use needs mechanisms
external to the protocol. Section 8 already describes several such
mechanisms that could be employed. So, I think this topic is covered.

This limitation also may not be applicable at all for green field
TLS/DNSSEC applications that can require the use of the extension
unconditionally.

Having an authenticated denial mechanism would allow the TLS client
to have an inband way to enforce DANE authentication if available.
I suspect though that re-introducing a debate on this topic will
lead us into an argument about what it means for a server to publish
a TLSA record. Is it just a mechanism to use the DNSSEC to authenticate
keys and certificates? Or is it also a policy signal that says DANE
must be used? I do not think the latter idea has any consensus in the
IETF currently.

> valid TLSA RRset chain, or with a valid denial of existence.

This is a rather substantial change proposal. It's worth considering,
but I'd like to hear others chime in. But as I said, there are ways
to use this spec and address some of the limitations outside the
protocol today - you can cache and pin knowledge of TLSA existence,
even without an in-protocol commitment, although the latter would be
better. That may be good enough for the first iteration of the protocol.

Note that extending the protocol to incorporate authenticated denial
also means that the chain data would likey need a DNS response code.
That's a stronger argument to move to a full DNS message format (I'll
answer Paul Wouter's specific comments on that topic separately later).

Shumon.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 27 Feb 2018 11:11:25 -0500

> On Feb 27, 2018, at 10:47 AM, Willem Toorop <[email-masked]> wrote:
> 

Sure, if restricted to applications in which the extension is mandatory,
the problem goes away.  But much of the appeal of this specification was
I believe that it would finally make it possible to do use DANE between
a browser and web server, and without authenticated DoE, it falls well
short of at least that goal.

> https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth

This is a very different context from that faced by most other application
clients.  Here the client is a DNS server (iterative resolver) talking to
authoritative servers, and sending the TLSA records over TLS is just an
optimization, the client can retrieve these separately.

> security, it still has that property.

For existing applications, with a deployed base of PKIX (WebPKI) servers,
this extension provides no secure upgrade path.  This problem severely
limits the utility of this extension.  I now think we can and should do
better.

Otherwise, this specification will not be a suitable basis for DANE-based
peer authentication in HTTPS, except for a narrow set of situations in which
DANE is required by some out-of-band external mechanism.

I think it makes sense to add a DANE latch TTL to the server's response,
which communicates to the client that the server commits to continue to
support the extension for some time considerably in excess of the TLSA
record TTL.  The client can cache that commitment for use with future
connections to the server.  With that in place, we get meaningful
applicability to HTTPS as used by general-purpose web browsers.

Or have we given up on ever using DANE for HTTPS in browsers?

-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 27 Feb 2018 11:24:31 -0500

> the "adversary with fraudulently obtained PKIX credentials" attack.

Following up to my own message, sorry ..

It occurred to me that perhaps a good way to mitigate this risk is
a combo of mechanisms like CAA and Certificate Transparency logs.

Shumon Huque

---

From: Nico Williams <[email-masked]>
Date: Tue, 27 Feb 2018 17:36:12 -0600

> a combo of mechanisms like CAA and Certificate Transparency logs.

NO.  That's insanely complicated.  A pin-for-X-minutes TTL is trivial.
Let's do this pin-to-DANE thing.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 27 Feb 2018 17:38:55 -0600

> Let's do this pin-to-DANE thing.

And I should add that if you'd work around downgrades by using CT, then
why bother with this extension *AT ALL*?!

I can't be emphatic enough about this.  This is an utter waste of
everyone's time here if we don't have this pin-to-DANE feature in this
draft.  The authors' time, the WG's time, the IESG's time, and
implementors' time.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Feb 2018 14:07:10 -0600

IF there's an objection to modifying the extension in order to add a
pin-to-DANE TTL field, I would propose the following instead:

    Make the pin-to-DANE be "forever" but make it so it can easily be
    cleared if DANE is undeployed for the service.

That would look like this:

 - if the server sends the extension with a valid DANE RR chain

   -> pin to DANE (no TTL needed; see below)

 - if the server sends the extension with a non-existence proof for DANE

   -> clear the PIN to DANE

 - if the server sends the extension with proof that an intermediate
   domain is not signed

   -> clear the PIN to DANE

This has the great benefit that it is simple.

Also, I'm not at all sure that a pin TTL is actually useful.  If I know
bar.foo.example. supports DANE, why would I want to asynchronously stop
expecting it to use DANE when it could just tell me (with a suitable
proof)?

Nico
--