Sorry for my belated follow-up. Was temporarily overwhelmed by the day job ..
On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla <e...@rtfm.com> wrote: > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <shu...@gmail.com> wrote: > > > > 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. Yes, I agree, we need to remove that. > It's not the algorithm. I don't believe this document is sufficient to > parse the > structure. Okay, got it. For people that have already implemented this, I think there has been an implicit understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section (with one injunction against doing DNS name compression). I'll write some text to make this more explicit and describe the format in more detail with references to the appropriate DNS specs. This is also the format that is readily generated and consumed by some DNS libraries and the Intro section of this document has the following assumption: "... (assuming that the data will be prepared and consumed by a DNS-specific library) ..." > > 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. Ok. I'm working on text for this .. > > > > * 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. Just to confirm, I assume the attacker here is an entity attempting to impersonate the TLS server (with presumably valid PKIX credentials). If so, yes it can trivially ignore the extension, but this is the case for any DANE usage mode (not just the PKIX constraining ones). As discussed in Section 8, the protocol as currently specified really only allows opportunistic DANE authentication, unless some mechanism external to TLS is employed to mandate DANE usage. (The protocol could be extended to require TLS servers to also provide a DNSSEC proof that they don't have a signed TLSA record, but that could only be deployed in a TLS application system where all servers supported this extension). > 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. I think Viktor's earlier reply to this thread goes into detail about possible client behaviors here and what we might recommend (which seems reasonable to me). I'll follow-up there. > > 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. My comment was about what DANE mode choices the server is offering to the client. Certainly, the client can decide whether it wants to use DANE or not, and whether it wants to fallback to PKIX. The protocol should probably not be proscriptive here, and allow different TLS applications (or configurations of such applications) to make choices. But maybe there are some general recommendations to be made. One additional comment about PKIX fallback on DANE failure: If a server is using DANE-EE or DANE-TA, it has the ability to send back a much shorter Certificate message - just the EE certificate for the former, and typically a very short X.509 chain for the latter. But this means that for fallback to PKIX, the client would have to start a new handshake omitting the dnssec_chain extension. For efficient fallback within the same handshake, the server would always have to send back the full PKIX X.509 chain. Maybe that's what we need to recommend for servers that support both DANE and traditional PKIX. > > > > 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. Fair enough. I'll propose some new text to make this clear. > > 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. Ok. Let me know how you want to handle this question. I'd be happy to send a separate note to the WG list about it. > > > . 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. Well, the algorithm the DNS server (specifically a DNSSEC aware resolver) uses is the DNS iterative resolution algorithm - the TLS server would just treat that as a blackbox (unless it implemented its own resolver). I think the more important question is how the TLS server issues a sequence of queries to the resolver to obtain the data it needs to construct the dnssec chain, and then extracts the corresponding RRsets from the responses to those queries. Section 4 (paragraphs 4 through 6) describe that process. Again, we could go into more detail here, but we were working with the assumption in the intro ( ".. the data will be prepared and consumed by a DNS-specific library.") > > > 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. Sorry for being dense - this protocol requires a new codepoint. Do we need to say we RECOMMEND that a new code point be registered? Or are you asking that we RECOMMEND that IANA allocates our preferred extension type value (53)? Shumon.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
