On 27 Oct 2016, at 11:03, Bob Harold wrote:
On Thu, Oct 27, 2016 at 12:43 PM, Sara Dickinson <[email protected]>
wrote:
So I’m not sure here. The aim here was to try to keep this section
flexible in terms of the interpretation of OS but perhaps this needs
discussion.
It seems like it does need discussion.
RFC 7435 says "An OS protocol first determines the capabilities of
the
peer with which it is attempting to communicate. Peer capabilities
may be
discovered by out-of-band or in-band means. (Out-of-band mechanisms
include the use of DANE records….”
and then allows for the hard failure if the capability isn’t as
described.
So this seems to leave the door open for clients to choose to
hard-fail in
certain circumstances which seem relevant to this document (I don’t
see any
caveats about this only happening if users know what is going on). It
seems
overkill to completely override that here with something like
"Opportunistic clients MUST fallback to clear text…” unless there
is
consensus that that is how it should work for DNS in all cases?
It seems that there are levels of Opportunistic Security (OS), either
falling back to TLS to an un-authenticated server, or falling back to
clear
text (no TLS). We should make it clear that there are various levels,
and
that there should be some way to choose what minimum level is allowed.
I will admit that I thought there was just one bottom level of OS in our
discussion, cleartext. If there are two (cleartext; no communication),
the document needs more discussion in multiple places because it would
be surprising to any implementer who didn't follow the long discussion
during the end stages of RFC 7435.
Which users do we think would not want to negotiate weak TLS (such as
DES-MD2) but would be willing to go to cleartext? For other than crypto
experts (who are likely to only want Strict), how would weak TLS be
worse than cleartext?
It feels like this is adding a layer of operational complexity for an
audience who probably doesn't exist.
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
