Subject: [TLS] Proposed text for dnsssec chain extension draft

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Apr 2018 01:33:54 -0400

I've been asked to write up proposed changes to the DNSSEC chain
extension draft (with the 16-bit extension support lifetime field).
In doing that I've discovered that adding the 16-bit field is a
minor tweak to the document text, but, ironically, describing
denial of existence, though a simple idea, requires extensive
surgery to the document.  Below I do both, in the hope that either
or both will prove useful.  Perhaps a concrete proposal will make it
easier to reach a mutually-agreeable consensus position, and make it
clear that the requested 16-bits are a reasonable consensus outcome.

I'm also willing to create a pull request against:

   https://github.com/MelindaShore/dnssec-serialization

if there's interest in me doing that.  Below I list OLD/NEW text
chunks with the name of the section in which they fit.

--- Change 1:  Section 2.  Introduction.
  * Add denial of existence

OLD:

   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 configured for DANE
   authentication, then it performs the appropriate DNS queries, builds
   the authentication chain, and returns it to the client.  The server
   will usually use a previously cached authentication chain, but it
   will need to rebuild it periodically as described in Section 5.  The
   client then authenticates the chain using a pre-configured trust
   anchor.

NEW:

   The extension described here allows a TLS client to request that the
   TLS server return the DNSSEC authentication chain corresponding to
   its DANE TLSA resource record set (RRset), or authenticated denial
   of existence of that RRset.  If the server supports this extension
   it performs the appropriate DNS queries, builds the authentication
   chain, and returns it to the client.  The server will usually
   use a previously cached authentication chain, but it will need
   to rebuild it periodically as described in Section 5.  The client
   then authenticates the chain using a pre-configured trust anchor.

   When the requested TLSA RRset does not exist, and/or the containing
   DNS zone is not DNSSEC-signed, the server MAY return a chain of
   records that establish authenticated denial of existence of the
   TLSA RRset, or prove insecure delegation (an ancestor) of that domain.
   Alternatively, the server MAY simply not negotiate the extension.

--- Change 2:  Section 3.4.  DNSSEC Authentication Chain Data
  * Add 16-bit SupportLifetime field

OLD:

   The "extension_data" field of the "dnssec_chain" extension MUST
   contain a DNSSEC Authentication Chain encoded in the following form:

             opaque AuthenticationChain<1..2^16-1>

NEW:

   The "extension_data" field of the "dnssec_chain" extension MUST
   contain a DNSSEC Authentication Chain encoded in the following form:

        struct {
             uint16 SupportLifetime;
             opaque AuthenticationChain<1..2^16-1>;
        } DnssecChainExtension;

   A zero "SupportLifetime" prohibits the client from unilaterally
   requiring ongoing use of the extension based on prior observation
   of its use (pinning).

   A future specification will define the semantics of non-zero
   values of the SupportLifetime field.  Servers implementing only
   the present specification MUST set the SupportLifetime element
   to zero.  Clients implementing only the present specification MUST
   treat any value received as though it were zero.

--- Change 3:  Section 3.4.  DNSSEC Authentication Chain Data
  * Add denial of existence

OLD:

   The first RRset in the chain MUST contain the TLSA record set being
   presented.  [...]

   The subsequent RRsets MUST contain the full set of DNS records needed
   to authenticate the TLSA record set from the server's trust anchor.
   [...]
   
NEW:

   When the response contains validated TLSA records,
   the first RRset in the chain MUST contain the TLSA record set being
   presented.  [...]

   When the response is an authenticated denial of existence, after
   any initial DNSSEC-signed CNAME and/or DNAME records redirecting
   the requested TLSA RRset, the next RRset in the chain MUST be the
   signed SOA record of the domain that is proving the non-existence
   of the TLSA RRset or its insecure delegation.  The SOA record MUST
   be followed by the relevant signed NSEC or NSEC3 records.

   The subsequent RRsets MUST contain the full set of DNS records
   needed to authenticate the TLSA record set or denial of existence
   response via the server's trust anchor.  [...]

--- Change 4:  Section 3.4.  DNSSEC Authentication Chain Data
  * Add denial of existence examples:

OLD:

   The following is an example of the records in the AuthenticationChain
   [...]
             RRSIG(. DNSKEY)

NEW:
   The following is an example of the records in the AuthenticationChain
   [...]
             RRSIG(. DNSKEY)

   The following is a TLSA RRset denial-of-existence example:

             example.com. IN SOA
             RRSIG(example.com. SOA)
             example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC
             RRSIG(example.com. NSEC)
             example.com. DNSKEY
             RRSIG(example.com. DNSKEY)
             example.com. DS
             RRSIG(example.com. DS)
             com. DNSKEY
             RRSIG(com. DNSKEY)
             com. DS
             RRSIG(com. DS)
             . DNSKEY
             RRSIG(. DNSKEY)

   The following is an insecure delegation example (with NSEC3 opt-out):

             com. IN SOA
             RRSIG(com. SOA)
             GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3 (1 1 0 -
                - GPIOVE5CC3CA0D1H14G1GI4J0835GEKB  NS DS RRSIG)
             RRSIG(GPINPHP5MI1PVD5L045CP3KP81E0JHAS.com. NSEC3)
             com. DNSKEY
             RRSIG(com. DNSKEY)
             com. DS
             RRSIG(com. DS)
             . DNSKEY
             RRSIG(. DNSKEY)

--- Change 5: Section 6.  Verification
  * Add denial of existence
  * Note that TLSA records might not be "usable" (new issue
    in the document, sorry, but clients should not have to
    honour unusable TLSA records)

OLD:

   A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, MUST use this
   information to perform DANE authentication of the server.  In order
   to do this, it uses the mechanism specified by the DNSSEC protocol
   [RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
   DNSSEC validation engine or library.

NEW:

   A TLS client making use of this specification, which receives
   a verifiable DNSSEC authentication chain extension from a server,
   MUST use this information to perform DANE authentication of the
   server when the response is not a denial of existence and has
   at least one "usable" TLSA record as defined in [RFC6698], [RFC7671]
   and any other applicable specifications (perhaps application-specific).

   Verification of the authentication chain extension uses the
   mechanism specified by the DNSSEC protocol [RFC4035] [RFC5155].
   This mechanism is sometimes implemented in a DNSSEC validation
   engine or library.

   [... New final paragraph for Section 6 ...]

   Clients MAY also cache a denial of existence response up to the
   validated negative TTL of such a response.

--- Change 6: Section 8.  Mandating use of this extension
  * Prohibit unilateral pinning, clarify downgrade.

OLD:

   If TLS applications want to mandate the use of this extension for
   specific servers, clients could maintain a whitelist of sites where
   the use of this extension is forced.  The client would refuse to
   authenticate such servers if they failed to deliver this extension.
   Client applications could also employ a Trust on First Use (TOFU)
   like strategy, whereby they would record the fact that a server
   offered the extension and use that knowledge to require it for
   subsequent connections.

   This protocol currently provides no way for a server to prove that it
   doesn't have a TLSA record.  Hence absent whitelists, a client
   misdirected to a server that has fraudulently acquired a public CA
   issued certificate for the real server's name, could be induced to
   establish a PKIX verified connection to the rogue server that
   precluded DANE authentication.  This could be solved by enhancing
   this protocol to require that servers without TLSA records need to
   provide a DNSSEC authentication chain that proves this (i.e. the
   chain includes NSEC or NSEC3 records that demonstrate either the
   absence of the TLSA record, or the absence of a secure delegation to
   the associated zone).  Such an enhancement would be impossible to
   deploy incrementally though since it requires all TLS servers to
   support this protocol.

NEW:

   Pending a future specification that defines the semantics of
   non-zero values of the SupportLifetime element of the extension,
   clients MUST NOT employ "pinning" to require use of the extension
   by servers previously observed to support it.  Servers that
   implement only this specification MUST set the SupportLifetime
   element to zero.

   In the absence of "pinning", when the extension is not mandatory,
   a client cannot reliably determine which servers don't have TLSA
   records. Hence, a client communicating with a server that has
   fraudulently acquired a public CA issued certificate for the real
   server's name, could be induced to establish a PKIX verified
   connection to a rogue server that simply omits this extension.

--- Editorial Appendix A.  Test vectors

  s/reproducability/reproducibility/

  This section should probably include new denial of existence test vectors.

-- 
	Viktor.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 25 Apr 2018 11:51:58 +0200

On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> Perhaps a concrete proposal will make it

Hi, Viktor:

This doesn't actually reflect the consensus called by the
chairs, as I understand what was posted.  It may be useful
to start work on a new draft describing your proposal.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Willem Toorop <[email-masked]>
Date: Wed, 25 Apr 2018 16:02:32 +0200

Thanks for the suggestions,

>    https://github.com/MelindaShore/dnssec-serialization

We're actually working on

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

> chunks with the name of the section in which they fit.

If you do, could you please make separate pull requests for denial of
existence and another one for the lifetime field.

Are you sure 16 bits is enough?  Other STS specs appear to use seconds
for the max-age directive.  They are also extensible with new directives
(which have been introduced too, to overcome initial unforeseen
limitations (i.e. preloading)).

Why do you require the SOA?  It is not needed for the denial of
existence (or insecurity) proof.  NSEC ttls tell how long to cache the
non-existence so it is not needed for the minimum field either.

>              RRSIG(. DNSKEY>

---

From: Willem Toorop <[email-masked]>
Date: Wed, 25 Apr 2018 16:36:14 +0200

>              example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC

Hopefully the DNSKEY rrtype is included in this NSEC too :), so:

   example.com. IN NSEC www.example.com. A NS SOA MX RRSIG NSEC DNSKEY

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2018 09:57:22 -0500

> to start work on a new draft describing your proposal.

The chair said there is consensus for (A) with no pinning.  Viktor's
proposal is (A) with no pinning.  It's not at all clear to me that the
two reserved bytes are outside the consensus, and anyways, their cost is
minimal.

However, if you object to turning the extension contents into a struct,
then I would propose a slight tweak to Viktor's proposal:

   Two-byte elements of the AuthenticationChain are reserved for future
   use.  Pending future specifications, clients MUST discard any two-
   byte elements of the AuthenticationChain, and servers MUST NOT send
   any such elements.

We might as well say that all too-small-to-be-DNS-payloads elements of
the AuthenticationChain are reserved and discarded:

   Any elements of the AuthenticationChain that are too small to contain
   DNS RRset payloads are reserved for future use.  Pending future
   specifications, clients MUST discard any such AuthenticationChain
   elements, and servers MUST NOT send any such elements.

The nice thing about this is that it makes it easier to extend this
extension later, while also adding minimal complexity now ("clients MUST
discard such elements").

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 25 Apr 2018 11:19:35 -0400

> On Apr 25, 2018, at 10:02 AM, Willem Toorop <[email-masked]> wrote:
> 

I'll try to get that done.  Thanks for the right repository pointer.

> for the max-age directive.

Yes, I'm sure that 16-bits is enough.  This is because an extension support
lifetime measured in seconds makes little sense, once this gets below an
hour it is commensurate with and often smaller than the TTL of the TLSA RRset.

There's no point in "pinning" the extension for a shorter time, the client
can just cache the TLSA records instead. The point of the extension support
lifetime is for ongoing downgrade resistance *beyond* the DNS TTL of the TLSA
records.  16 bits of hours is sufficient for a commitment between 1 hour and
7.5 years.

> They are also extensible with new directives

Here I'm proposing a simple and general mechanism broadly applicable to
all TLS applications.  It would cover, for example, downgrade protection
for SUBMIT, POP, IMAP and XMPP clients.  There is deliberately no support
for including sub-domains as that would likely drag in the public suffix
list as a co-requisite and complicate deployment.

Preloading is rather browser-specific, and can be handled at the HTTPS
layer if desired.  Preloading only scales to the extent that it is not
too popular.

> non-existence so it is not needed for the minimum field either.

You're probably right about that, the NSEC or NSEC3 records are required
to carry the same negative TTL (also limited by the RRSIG original TTL
and RRSIG expiration).  So probably the SOA can be omitted, with the NSEC
or NSEC3 records first after the relevant DNAME/CNAME chain.

-- 
	Viktor.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 25 Apr 2018 08:48:41 -0700

To clarify, I asked for exact text to understand better what is being asked
for, since it wasn't very clear to me what the scope fo the change is.

On Wed, Apr 25, 2018 at 2:51 AM, Melinda Shore <[email-masked]
> wrote:

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

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2018 10:40:02 -0500

>    byte elements of the AuthenticationChain, and servers MUST NOT send

Ay, never mind, this isn't XDR, so that wouldn't work.

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2018 10:46:27 -0500

> Ay, never mind, this isn't XDR, so that wouldn't work.

Actually, since the extension's body is an opaque<1..2^16-1>, and the
extension is itself an opaque<>, it's possible to have data past the end
of the body of the extension.  But at this point I prefer Viktor's
struct proposal.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 25 Apr 2018 21:13:37 -0700

This proposal is quite a bit more than just a two byte reserved field.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Apr 2018 00:17:21 -0400

> existence and another one for the lifetime field.

I made a single pull request with two commits, I hope that's OK.

The 16-bit field is the second commit, and if that fails to get
adopted, then you can use just the first commit.

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

The text is slightly different from my earlier post based on
a revisions already staged by the authors which adds a section
containing a brief overview of the the two types of a denial
of existence response.  The first commit makes what I think
are additional necessary adjustments elsewhere in the document.

It also changes MUST use DANE when TLSA records are present to
SHOULD use DANE when TLSA records are present AND "usable".
With the protocol subject to downgrade attacks, the MUST does
not afford any downgrade resistance.  The client may do as it
pleases and the server is none the wiser, so MUST does not
make sense here.

-- 
	Viktor.

[ Drafting revisions to a document sure forces one to read the fine
  print in ways that a mere "review" often fails to achieve. :-( ]

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2018 23:15:53 -0500

> This proposal is quite a bit more than just a two byte reserved field.

What, Viktor's text?  Most of it has to do with the denial of existence,
not with those two bytes.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Apr 2018 00:26:03 -0400

> On Apr 26, 2018, at 12:13 AM, Joseph Salowey <[email-masked]> wrote:
> 

I am not sure what you mean.  The proposed text adds the field, tells
servers to set it to zero, and tells clients to treat it as though it
were zero even if a non-zero value is seen.  So far, so good right?
Please help me understand...

The only extra bit is that the client *explicitly* MUST NOT PIN when
the field is zero.  So the pinning prohibition is stronger than what
you get if you just remove description of pinning, and my bet would
be that left unsaid, and if we don't standardize downgrade-protection
in a timely manner, some clients might unilaterally decide to pin.

I did not expect prohibiting pinning at this time to be controversial.
That should have broad support.

The relevant diff is at:

  https://github.com/tlswg/dnssec-chain-extension/pull/14/commits/034da27062b53fe4a7460536187220585df13f0d

Or see below:

commit 034da27062b53fe4a7460536187220585df13f0d
Author: Viktor Dukhovni <[email-masked]>
Date:   Thu Apr 26 00:00:55 2018 -0400

    Describe new 16-bit SupportLifetime extension element
    
    This both actively inhibits "pinning" in the present,
    and serves to facilitate it in the future.

diff --git a/draft-ietf-tls-dnssec-chain-extension-08.xml b/draft-ietf-tls-dnssec-chain-extension-08.xml
index ffec606..5a4b685 100644
--- a/draft-ietf-tls-dnssec-chain-extension-08.xml
+++ b/draft-ietf-tls-dnssec-chain-extension-08.xml
@@ -304,13 +304,29 @@
 
       <figure>
         <artwork>
-
-          opaque AuthenticationChain&lt;1..2^16-1&gt;
+    struct {
+        uint16 SupportLifetime;
+        opaque AuthenticationChain&lt;1..2^16-1&gt;;
+    } DnssecChainExtension;
         </artwork>
       </figure>
 
       <t>
-    The AuthenticationChain structure is composed of a sequence of 
+      A zero "SupportLifetime" prohibits the client from unilaterally
+      requiring ongoing use of the extension based on prior observation
+      of its use (pinning).
+      </t>
+
+      <t>
+      A future specification will define the semantics of non-zero
+      values of the SupportLifetime field.  Servers implementing only
+      the present specification MUST set the SupportLifetime element
+      to zero.  Clients implementing only the present specification MUST
+      treat any value received as though it were zero.
+      </t>
+
+      <t>
+    The AuthenticationChain is composed of a sequence of
     uncompressed wire format DNS resource record sets (RRset) and 
     corresponding signatures (RRSIG) record sets.
       </t>
@@ -691,6 +707,15 @@ RRSIG(. DNSKEY)
       extension, could of course unconditionally mandate its use.
     </t>
 
+    <t>
+      Pending a future specification that defines the semantics of
+      non-zero values of the SupportLifetime element of the extension,
+      clients MUST NOT employ "pinning" to require use of the extension
+      by servers previously observed to support it.  Servers that
+      implement only this specification MUST set the SupportLifetime
+      element to zero.
+    </t>
+
     <t>
       This protocol allows TLS servers to prove that they don't have a
       signed TLSA record by returning a denial of existence chain.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Apr 2018 23:30:02 -0700

Hi Victor,

Thanks for producing some text. I understand why one might think that
having a
reserved 16-bit field is useful here, but I don't really agree.

The conventional reason to reserve this kind of field is that you need to
leave
space for an extension in some PDU, because it's hard to add later. But
that's
not true here (or in TLS in general) because we already have an extension
mechanism (indeed, the one that's being used by this specification). If we
end up having consensus to do pinning, then it's straightforward to define
a new TLS extension that provides it.

If you look at HPKP and Expect-CT, you will note that there are a number of
other fields besides just lifetime (report-uri, include subdomains). I
recognize
that opinions vary about whether these are good, but the advantage of having
a whole new extension is that we need not resolve those now in order to move
this document forward. As far as I can tell, the primary disadvantage of a
new
extension is a slight increase in the size of the TLS handshake if the
extension
is used (balanced against two wasted bytes in this proposed design if it is
not used). That doesn't seem like a good set of tradeoffs.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Apr 2018 09:51:37 -0400

> On Apr 26, 2018, at 2:30 AM, Eric Rescorla <[email-masked]> wrote:
> 
> other fields besides just lifetime (report-uri, include subdomains). I recognize
> this document forward.

Let's ignore HPKP, as discussed previously it is a poor analogy
here, (and, not entirely surprisingly an impractical design).
A somewhat better comparison is Expect-CT or MTA-STS.

Both of these have a max-age.  Neither of them is "forever".  We
can safely assume that *any* mechanism to negotiate downgrade
protection for this extension between server and client will
have a finite duration.

Neither of the comparison specs are TLS extensions intended to cover
a broad range of applications.  They are single application policy
mechanisms communicated via HTTP headers.

Here, our scope is *all* end-user applications that choose to use
the DNSSEC chain extension to access the server's DANE TLSA
records.

If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
find:

  * a lifetime field
  * enforce vs. test
  * a report URI

This specification is always "enforce" (though my pull request
changes a MUST use DANE to a SHOULD with some necessary added
conditions) and since the report URI is in good measure to
support non-enforce mode, we're back to just max-age.

> As far as I can tell, the primary disadvantage of a new
> extension is a slight increase in the size of the TLS handshake if the extension

Well, here I appeal to Melinda's observation that specifications
need to closely consider implementation complexity, not just
specification complexity.  Indeed implementation complexity
should be the primary concern.

A major disadvantage of a separate extension (rather than
adding semantics to an existing field) is that implementations
will then need to add code to generate and consume a second
extension, integrate the new code point, handle combinatorial
logic of receiving either extension or both, ...

Including the field now removes the need to ask libraries to
add code for a second extension, complicating the API and
complicating the code that applications need to call to
make use of the combined data.

Worst case the chain extension carries an extra 16 bits of
zeros, which by the way explicitly signal: do not do
unilateral pinning.  There's really much too little to
object to and real potential benefit.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Apr 2018 07:50:08 -0700

> support non-enforce mode, we're back to just max-age.

But this reinforces my point. I think we ought to have an enforce vs test
flag and a report URI (and I I don't find your arguments above about why we
shouldn't do this persuasive.)  Standardizing this functionality would
require resolving these issues.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Apr 2018 11:05:32 -0400

> On Apr 26, 2018, at 10:50 AM, Eric Rescorla <[email-masked]> wrote:
> 
> But this reinforces my point. I think we ought to have an enforce vs test flag and a report URI (and I I don't find your arguments above about why we shouldn't do this persuasive.)  Standardizing this functionality would require resolving these issues.

We should observe that "enforce vs. test" is already moot, this document
implies enforce.  If you wanted a test mode and a reporting URI, these
would have to be part of the present extension.  When the server presents
is DANE TLSA records, the client will enforce them (for just one session,
but we should assume that downgrade attacks, while evermore common are not
the norm).

The signal to do DANE (by virtue of delivering TLSA records) is the primary
change, and it is delivered via the present extension, the "pinning" we're
proposing is NOT "pinning" to deliver TLSA records and do DANE, it is merely
downgrade protection for the signalling channel!  The "pin" can be satisfied
with a denial of existence response.  Compliant servers merely need a software
capability (to send the signal), the "pin" does not enforce new security
mechanisms.

Downgrade protection for DANE signalling DOES NOT need any of those other
bells and whistles.  They would, if needed, belong in this specification,
not in a tweak to harden the signalling.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Apr 2018 08:14:16 -0700

On Thu, Apr 26, 2018 at 8:05 AM, Viktor Dukhovni <[email-masked]>
wrote:

> > But this reinforces my point. I think we ought to have an enforce vs
> test flag and a report URI (and I I don't find your arguments above about
> why we shouldn't do this persuasive.)  Standardizing this functionality
> would require resolving these issues.
>
> would have to be part of the present extension.

You seem to be assuming that the only thing you might want to test is
the DANE chain for this specific connection.

Consider the case where you have a big server farm and you want to
roll this mechanism out, but you're concerned about whether you're getting
every server configured properly. You set this with pinning on and test mode
+ reporting URI, and then wait to see if you get reports, which would
indicate
that a server is misconfigured.

Anyway, we're now having the discussion about exactly what would be be
required to make pinning work, which, as I said, demonstrates that it's
premature to just add a placeholder age field for this functionality.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2018 10:13:07 -0500

On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> having a reserved 16-bit field is useful here, but I don't really
> agree.
> 
> The conventional reason to reserve this kind of field is that you need
> to leave space for an extension in some PDU, because it's hard to add
> later. But that's not true here (or in TLS in general) because we

-07 has text on pinning.  There is no consensus on making that work
_now_.  There is only consensus on removing that text and revisiting
pinning later.  Well, later we will need these two bytes.

So there's the conventional reason to reserve this kind of field:
because we know we will need it, and adding it via some extension
facility will be harder than... already having it.

And yes, we (the IETF) do use reserved fields even in protocols where
there is extensibility.

> already have an extension mechanism (indeed, the one that's being used
> by this specification). If we end up having consensus to do pinning,
> then it's straightforward to define a new TLS extension that provides
> it.

Having these two bytes now will mean that they are always present, which
will make it a lot easier for implementations to a) start sending
non-zero values, b) start handling non-zero values, once we write a spec
on what non-zero values mean.  (And we know what that spec will say,
which is why we know we need two bytes.)

> If you look at HPKP and Expect-CT, you will note that there are a
> [...]

HPKP is completely different.  The idea here is NOT to pin key material,
CAs, or anything of the sort.  The idea here is to pin only the use of
this extension, and this does not even bind one to use DANE because the
extension can carry a denial of existence.

Nico
--

---

From: Richard Barnes <[email-masked]>
Date: Thu, 26 Apr 2018 11:22:40 -0400

> And yes, we (the IETF) do use reserved fields even in protocols where

[citation-needed]

All the instances of "reserved" I can think of are either due to bit
alignment or blocking off old stuff.

--Richard

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2018 10:22:07 -0500

On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> > On Apr 26, 2018, Eric Rescorla <[email-masked]> wrote:
> >
> >   * a lifetime field
> >   * enforce vs. test
> >   * a report URI

We will need only the TTL.  We will not need anything else.  This is NOT
like HPKP.  This will pin only the use of the extension, and NOT EVEN
the use of DANE since you can send a denial of existence and you can
*always*[*] do that if you stop wanting DANE.

[*] unless you're operating in an alternate DNS universe where no zone
    is signed, not even the root zone, but then you wouldn't have used
    this extension ever, and you'd not have pinned it).

Because we'd pin only to the use of this extension, the TTL is
sufficient.

> test flag and a report URI (and I I don't find your arguments above
> about why we shouldn't do this persuasive.)  Standardizing this
> functionality would require resolving these issues.

Strawman.  These are make-believe issues.  Is it just to give the
appearance that we couldn't possibly reach consensus on just two bytes?

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Thu, 26 Apr 2018 11:30:53 -0400 (EDT)

On Wed, 25 Apr 2018, Eric Rescorla wrote:

> The conventional reason to reserve this kind of field is that you need to leave
> space for an extension in some PDU, because it's hard to add later. But that's

The pinning is not about DANE pinning but about extension pinning. To
make a 2nd extension to pin a 1st extension seems very wrong to me.

Additionally, as explained before, since all pinning text has consensus
to be removed, this would leave clients completely in the dark about
what to do when the extension vanishes. Adding the two byte zeroes
allows the document to clearly and unequivocally say to NOT pin this
extension with some magic local policy.

> That doesn't seem like a good set of tradeoffs.

This has nothing to do with trade-offs. It has to do with carefully
specifying client behaviour for use with _this_ extension. It makes
no sense to leave that unspecified for another document.

Paul

---

From: Richard Barnes <[email-masked]>
Date: Thu, 26 Apr 2018 11:41:05 -0400

On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams <[email-masked]>
wrote:

> > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni <[email-masked]
> >
> > wrote:

Until my DNSSEC signing infra breaks, the signatures expire, and now my
server is bricked.

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Apr 2018 08:41:18 -0700

> Because we'd pin only to the use of this extension, the TTL is

I explained in my response to Victor why this isn't so.

> appearance that we couldn't possibly reach consensus on just two bytes?

This discussion would probably be a lot more productive if you were able to
have it without accusing other participants of acting in bad faith.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Apr 2018 11:53:29 -0400

> On Apr 26, 2018, at 11:41 AM, Richard Barnes <[email-masked]> wrote:
> 
> Until my DNSSEC signing infra breaks, the signatures expire, and now my server is bricked.

If that happens, you're bricked anyway, the 1.1.1.1, 8.8.8.8, 9.9.9.9,
64.6.64.6, ... resolvers all validate and are used by a broad and
rapidly growing set of users.

Sites that consider DNSSEC too risky, won't deploy DNSSEC and then of
course won't deploy this extension.

That said, the explicit lifetime field also in part addresses your
concerns about recovery from operational errors.  Set it to zero or
a small number (of hours, units deliberately left out of proposed
changes to this draft to make sure non-zero values are unspecified).

Of course given evermore sophisticated BGP attacks:

  https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/

you might actually want to consider DNSSEC, implement it properly
and monitor, and the bricking won't happen.

-- 
-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2018 10:49:35 -0500

> Until my DNSSEC signing infra breaks, the signatures expire, and now my

There is no way in which you can break your zone such that this pinning
gets you into trouble.  Here's why, there are only these possible
states:

 - you have TLSA RRs with a valid chain all the way to the root
   (works)

 - you don't have TLSA RRs and have a denial of existence chain
   (works)

 - your zone isn't signed, in which case you can prove this and we call
   that a denial of existence too
   (works)

 - your zone is bricked
   (fails because lookups fail)

If your zone is bricked then this extension doesn't even come into play
because clients will not be able to resolve your servers' hostnames,
therefore they won't even connect.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2018 10:50:39 -0500

> I explained in my response to Victor why this isn't so.

I don't accept that explanation.  It's based on a strawman argument.

> have it without accusing other participants of acting in bad faith.

Sounds good to me.  One way to make this more civil is to not make
strawman arguments.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 26 Apr 2018 10:53:49 -0500

> and monitor, and the bricking won't happen.

Good point!

DNSSEC is the only defense against such attacks at this point.

Pinning this extension sure seems like a desirable thing in that
context!

We're not asking for pinning _now_ because as the WG chair says there is
no consensus to add pinning _now_.  We're only trying to make it
*easier* to add it _later_.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Apr 2018 12:06:45 -0400

> On Apr 26, 2018, at 11:41 AM, Eric Rescorla <[email-masked]> wrote:
> 
> This discussion would probably be a lot more productive if you were
> able to have it without accusing other participants of acting in bad
> faith.

[ Well the objections do seem rather hypothetical, and the thing being
  objected to (a 16-bit reserved field) so minimally objectionable, that
  it is   perplexing why it is so important to avoid reaching a compromise
  by   allowing the 2-byte to be added.  Indeed it sure looks like the
  separate document that might define the follow-on extension would
  be strongly opposed in any form by those opposing the reserved 2 bytes,
  but I'd be thrilled to learn of your support in principle for such a
  document, perhaps you'd even be willing to author (or co-author) the
  initial draft? ]

I rather like Paul's point that the lifetime of support for
this extension belongs with this extension.  Adding an extension to
signal ongoing support for another extension rather unnatural.

-- 
	Viktor.