On Sunday, April 26, 2015 06:41:58 PM Paul Wouters wrote: > On Sun, 26 Apr 2015, Viktor Dukhovni wrote: > > On Sun, Apr 26, 2015 at 04:59:12PM -0400, Paul Wouters wrote: > >>> Great, it looks like the proposed standard for hardening SMTP/TLS > >>> could be repurposed for either http(s) or arbitrary ports as per my > >>> proposal no? > >> > >> There is nothing left to harden. The presence of TLSA means, never go > >> to the insecure port. > > > > Yes, when the client is not already committed to using TLS, i.e. it is > > opportunistic. > > Unfortunately, the use of the standalone word "opportunistic" is > confusing as it means different things. > > >> I tried to get this meaing into the original TLSA spec, and there was > >> resistence to it. It was sidetracked into the HASTLS record, which never > >> saw the light. I'm not sure if the DANE OPS (SRV) draft clarifies this, > >> but any sane client implementation of TLSA should really assume this. > > > > We don't currently have a generic "opportunistic DANE TLS" document, > > the SMTP draft directly specifies this behaviour for SMTP. The > > SRV draft mostly does the same, withouth explicitly calling this > > out as being opportunistic. > > > > I expect the OPS draft LC to start any day now. If it should > > generalize this observation, this is a good time to suggest suitable > > language. > > I'm behind on my dane and dnsop document reading :( > > > When I started work on what is now the SMTP draft, it originally > > was a generic opportunistic DANE TLS document. It later split into > > SMTP and OPS, with the former not covering non-SMTP use-cases, and > > the latter not covering opportunistic security. > > The opportune part is "hey, they are publishing a key to use for > crypto". Once you're at that stage, doing TLS is not optional, but > mandatory (IMHO, because people did not want to commit to this > in the original DANE RFC)
Given https://tools.ietf.org/html/rfc7435 I don't see where there's ambiguity about what opportunistic is. Scott K _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
