On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla <e...@rtfm.com> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>
Thanks Eric for your detailed review and comments.
> 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.
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
> 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.
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.
>
> 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.
>
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).
> 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?
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).
> [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?
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".
> ----------------------------------------------------------------------
> 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"...?
Yes, that makes it clearer (and is it what it means). We'll reword.
>
> validation of endpoint names, but is more appropriate for validation
> of DANE TLSA records.
> Same comment as abive
>
Ok.
> 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,
Ok.
>
> 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.
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 ...
>
> 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.
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.
> 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.
Ok.
> 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.
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.
>
> 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?
They should clearly be consistent. My preference would be "SHOULD" for
both.
> 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
Ok, we will clarify this.
> I think you probably want to cite SIGMA and triple handhshake here.
Ok.
>
> opaque AuthenticationChain<0..2^16-1>
> Is 0 actually appropriate here as a lower bound? Presumably at least one
such
> 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>
>
> RR(i) = owner | type | class | TTL | RDATA length | RDATA
> 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.
>
> . DNSKEY
> RRSIG(. DNSKEY)
> How does this differ from the algorithm that you would use in response to
the
> TLSA query?
Sorry, I don't follow your comment here. Differ from what? Can you
elaborate?
>
> 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?
In response to Mirja's earlier comment, I think we are taking out this
sentence.
Shumon Huque
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
