On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <shu...@gmail.com> wrote:
> 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? > Well, and remove your text about it being possible to implement solely from this document. 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. > It's not the algorithm. I don't believe this document is sufficient to parse the structure. Otherwise, can you suggest more specifically what level of additional > detail you'd like to see in this document? > See 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. > > 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. > I'd have to review your text to know if it was 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. > > > > 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". > Yes, that would be fine. (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. > Well, neither of these modes is useful here, as an attacker will simply ignore the extension. Would you like us to discuss this in the draft? Or is referring to > RFC 7671 sufficient? > I think you should discuss it in the draft as it is relevant to TLS implementation. 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. > 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 > 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). > Yes, I don't think those modes are useful here. 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 ... > Yes, this is fine. > 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. > The problem is that the client is the decider about what it wants to accept, not the server. > 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. > OK. Well, perhaps some better text is needed here. > 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. > That's a WG decision. > > > > 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? > 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. > > > > 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. > You're still registering the code point, so you need to determine if it's RECOMMENDED or not. -Ekr > Shumon Huque > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls