Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <48A008D3-BEA0-43A6-AF96-C053CBCD3370@vpnc.org>
Date: Fri, 28 Oct 2016 11:21:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <30ADBA4B-A18B-4537-865B-92076AF546B6@sinodun.com>
References: <2203A3DE-5A8A-4364-ABAB-B8BA9BB19FDF@vpnc.org>
 <28B31793-B7D7-4DE5-B9A2-12AE639EC26C@sinodun.com>
 <7361F8F2-76B9-4608-A734-99EC04BD391A@vpnc.org>
 <6B53F353-CD20-4025-A992-7D5C1AB7B7F2@sinodun.com>
 <CA+nkc8A=jU-jUFdbs3ZUYd4+-jPNbe6qJO5FVENd1SrXRiwWxw@mail.gmail.com>
 <48A008D3-BEA0-43A6-AF96-C053CBCD3370@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/7UMit8Z0xlhTYFlb2hfaz3uUm8Q>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Subject: Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict
 privacy
Precedence: list


> On 27 Oct 2016, at 19:28, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>=20
> 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.=20

> 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 =E2=80=98Relaxed=E2=80=99 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 =E2=80=98keep it simple, Strict or Opportunistic=E2=80=99=
. =20

For me the other =E2=80=98intermediate=E2=80=99 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. 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.=20=


Sara.=20