On Tue, May 23, 2017 at 06:22:30AM +0900, Eric Rescorla wrote: > On Tue, May 23, 2017 at 6:00 AM, Nico Williams <n...@cryptonector.com> > wrote: > > > I don't understand the question. If you treat them as unknown then > > > either your path construction code will route around them or once you > > > try to verify, it will fail. > > > > That *really* seems like a layer violation! > > As I said, I don't have a problem with it. It's TLS giving instructions to > the PKI subsystem.
It implies more APIs. > > Well, I want it to be crystal clear that the "not MD5 and such" > > requirement need not apply to opportunistic TLS usage. > > I don't think "opportunistic" is a clearly enough defined category to be > useful here. Rather, I think the relevant criterion is the one I > listed above. If people agree, I'd be happy to make that change (and > can produce text) because I think it conforms to the WG consensus. Opportunistic == "If the server got authenticated great, if not, that's fine too" If the server was not authenticated, the app might use channel binding, or learn the server's cert (TOFU), or just use the connection because the only thing the application cares about is key agreement (defeat eavesdropers, but not active attackers). The last one is Viktor's use case (SMTP). Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
