On 28 Oct 2016, at 3:21, Sara Dickinson wrote:
On 27 Oct 2016, at 19:28, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
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.
As the draft stands it is clear about what Strict is and allows for
all flavours of OS, essentially leaving it as an implementation
choice. If, because of the nature of DNS, the feeling is it makes more
sense that Opportunistic _always_ falls back to clear text in order to
get service then I can see the value in that. It is just a question of
spelling this out clearly in the draft.
Right. However, the draft currently says in a few places that you choose
opportunistic if you want to be sure you get DNS service. So you either
have to remove those, or remove the possibility that OS will not go to
cleartext.
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?
There was some discussion in Buenos Aires (I think) about an
intermediate ‘Relaxed’ mode where a client is willing to use a
(weakly) encrypted connection but not willing to fallback to clear
text so as to have some protection against passive monitoring. But
IIRC the consensus was ‘keep it simple, Strict or Opportunistic’.
I don't remember the conversation, but I really don't remember anyone
advocating for "more complicated". Strict,
Opportunistic-only-to-good-crypto, and Opportunistic-to-cleartext is
more complicated than Strict and Opportunistic-to-cleartext. Users don't
know how to set "good crypto".
For me the other ‘intermediate’ case I was really thinking of in
the hard-fail case for Opportunistic is when the client does have
authentication information configured (as opposed to having none) but
the authentication fails.
That's Strict, yes?
Should there be scope for the client to decide in that case that
something is wrong enough it doesn't want to continue? As you say,
maybe this is complicating the picture too much.
We can make this as complicated as we want. My goal is to prevent people
from turning it off when the Internet doesn't work and they find out
it's because DNS-over-TLS was turned on.
--Paul Hoffman
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
