On Fri, Jul 7, 2017 at 3:13 PM, Tom Ritter <t...@ritter.vg> wrote: > As a note, I didn't see anything in this draft (from a quick read) > that precludes any of DANE's Certificate Usage, Selector, or Matching > Type fields. If that's not the case, perhaps someone can correct me. >
Yes, that's correct. Is there any reason it should? TLS applications are free to preclude the use of DANE parameters, but a more general purpose protocol I feel probably should not. The draft does refer several times to RFC 7671 (DANE updates and operational guidelines), which has some recommendations which ought to be followed. > A client must not be able to force a server to perform lookups on > arbitrary domain names using this mechanism. Therefore, a server > MUST NOT construct chains for domain names other than its own. > > What about the reverse? Do we care about a server tricking a client > into priming its DNS cache? > -tom > Yes, we want to avoid that, but I would expect that any sane client implementation, as a basic precaution, would only accept a DNSSEC chain corresponding to the TLSA name that it expected to see. If the server presented anything else, it would not be considered invalid. Similarly, if the chain included embedded unexpected extraneous records, I would expect the client implementation to ignore those (or even invalidate the whole chain if it wanted to be more draconian). If necessary, we could have explicit text about this. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
