6 mar 2013 kl. 20:52 skrev Paul Wouters <[email protected]>: > On Wed, 6 Mar 2013, Viktor Dukhovni wrote: > >>> But since HASTLS seems dead, please interpret "TLSA record present" as >>> "don't deliver without TLS" >>> >>> *ducks* >> >> No need to duck > > I was ducking for other people :) > >> , if DNSSEC serves-up usable TLSA records, then >> indeed Postfix won't deliver without TLS. > > And that is what the majority did not want the specification to mean. > They wanted the "is TLS mandatory for this connection or not" to be > signaled with a separate record, the draft had HASTLS. However, that > draft hasn't moved at all in over a year, and I am personally in favour > of using the presence of a TLSA record to mean "do not contact without > TLS". In SIP we use NAPTR records to indicate choice of transport to contact a specific domain name. In NAPTR, I can say "I'm only available over TLS".
Just for the archive... /O > >> If *all* the records are >> malformed or use unsupported parameters, then my reading of DANE >> 6698 is that one should behave as though no TLSA records were >> present. This is based on 6698 #4.1: >> >> If an application receives zero usable certificate associations from >> a DNS request or from its cache, it processes TLS in the normal >> fashion without any input from the TLSA records. If an application >> receives one or more usable certificate associations, it attempts to >> match each certificate association with the TLS server's end entity >> certificate until a successful match is found. During the TLS >> handshake, if none of the certificate associations matches the >> certificate given by the TLS server, the TLS client MUST abort the >> handshake. >> >> Are you saying that an RRset consisting entirely of unusable TLSA >> records should force TLS (to always fail)? > > That section does not talk about whether or not to use non-TLS. It only > talks about "if you want to do TLS and you find one or more TLSA > records". It does not talk about "should we connect using TLS or > without?" > > Paul > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
