[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?
- [TLS] Eric Rescorla's Discuss on draft-ietf-tls-d… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Benjamin Kaduk
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Nico Williams
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Nico Williams
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Nico Williams
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Eric Rescorla
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Willem Toorop
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Viktor Dukhovni
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Paul Wouters
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Kathleen Moriarty
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Ilari Liusvaara
- Re: [TLS] Eric Rescorla's Discuss on draft-ietf-t… Shumon Huque