On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque <shu...@gmail.com> wrote:
> 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) ..." > Sure. I'm not arguing that this is a bad format. It's just a matter of making clear to the user what they have to do to parse it. > > > * 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). > Agreed. It's just a less useful form of attack for the DANE modes where you are authenticating with DANE only, as it's basically just a form of DOS. > 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). > I agree. > > 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. > That would be my proposal, but I think at least you need to provide the kind of analysis you do 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. > > 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. > Sorry, I didn't mean to discount your view. I meant that I didn't think it was role to say which one it should be. This is actually a question for the chairs and the AD (Kathleen). If they think the WG decided this, then you can just do "SHOULD". If they think it requires WG consultation, then you should do that 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.") > OK. > > > 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)? > No. There is a column in the code point assignment for IANA that says whether the IETF recommends the use of this extension or whether we're just assigning the code point but don't recommend it. So you need to say which one it is. I assume the WG wants "Recommended" -Ekr > Shumon. > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
