On Fri, Jul 7, 2017 at 11:59 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 06/28/2017 04:15 PM, Joseph Salowey wrote: > > This is the working group last call for > draft-ietf-tls-dnssec-chain-extension-04. > Please send you comments to the list by July 12, 2017. > > > Just a couple minor things I don't remember being mentioned already that I > noticed in a quick read: > > When section 3.4 mentions that "this document describes the data structure > in sufficient detail that implementors if they desire can write their own > code to do this", it seems that this really on makes sense when the "this" > is for the encoding side, not the decoding side. That is, in that we > expect future DNS clients to continue to process responses in the current > format, but future DNS servers might generate responses that cannot be > properly decoded just following this document. (E.g., what would happen if > NSEC5 became popular?) > I think it's best to take that sentence out. It's a remnant of much earlier versions of the draft where we did describe the decoding (and validation) side in more detail, whereas now a lot of the client side processing is being referred to DNSSEC specs. Regarding future DNSSEC protocol enhancements that may necessitate format and protocol processing changes, maybe it's best to defer those to future revisions of the spec. But feel free to propose any specific wording on this topic for inclusion. (NSEC5 adoption in DNSOP is still very much an open question. The other possible enhancement that might need to be considered in the future is records related to key transparency - "CT for DNSSEC", which could happen someday.) > In section 8: > > Mandating this extension for Raw Public Key > authentication (where there are no X.509 certificates) could employ > configuration mechanisms external to the TLS protocol > > this sentence structure is a little confusing; it might be better to say > something like "If needed, configuration mechanism external to the TLS > protocol could be used to mandate the use of this extension for Raw Public > Key authentication". > > -Ben > > Yes, your suggested text sounds much better. We can incorporate that. However, there is larger concern that I have with section 8 that probably deserves working group discussion. This section might imply that there is a (protocol resident) way to mandate the use of this extension, but I don't think there is an easy way. Even in the case of X.509 certificates, the TLS feature extension can only dictate the delivery of this extension when the client has connected to the right server presenting that certificate. A TLS client misdirected to a rogue TLS server (e.g. via DNS spoofing, a routing attack, or other means) that has fraudulently acquired a public CA issued certificate for the legitimate server name, could be induced to establish a (PKIX) verified connection to that rogue server that precludes DANE authentication, when in fact it was available. Some TLS applications may desire to mandate DANE authentication where available, and protect themselves against malicious or tricked CAs. What is the best way to accommodate them? TLS clients could keep a whitelist of DANE servers, which doesn't scale very far; they could use TOFU/HPKP like methods: add DANE supporting sites to a whitelist dynamically as they are seen, etc. Some other applications use the presence of an authenticated TLSA record to enforce DANE authentication (RFC 7672 for SMTP STARTTLS). The last time this was discussed in the context of tls-dnssec-chain, it was argued that this "mandatory use" was not a semantic that the generic TLSA record provides, so only specific applications should specify that behavior. But if a specific TLS application using this extension did want to specify this behavior, how could it happen? In a hypothetical world where all TLS clients & servers understood this extension, we could have required the TLS server to either (1) present the dnssec_chain for their TLSA record, or (2) present a dnssec_chain that demonstrates that there is no secure TLSA record, or that there is no secure delegation to the zone. I think this would solve the problem, but this isn't practical any time soon (or perhaps ever). I'm not suggesting that we need to come up with a solution for this, but I believe the issue probably needs some sort of mention somewhere (in Security Considerations?). -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
