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

Eric Rescorla <ekr@rtfm.com> Wed, 07 February 2018 14:34 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9125012D779; Wed, 7 Feb 2018 06:34:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey <joe@salowey.net>, shuque@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com>
Date: Wed, 07 Feb 2018 06:34:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_M693JN_GJGK1ssJAf_pKIAeopQ>
Subject: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2018 14:34:41 -0000

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?