Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy

Sara Dickinson <sara@sinodun.com> Fri, 28 October 2016 10:22 UTC

Return-Path: <sara@sinodun.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89281129644 for <dns-privacy@ietfa.amsl.com>; Fri, 28 Oct 2016 03:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O41izx0gFyKN for <dns-privacy@ietfa.amsl.com>; Fri, 28 Oct 2016 03:22:09 -0700 (PDT)
Received: from shcp01.hosting.zen.net.uk (shcp01.hosting.zen.net.uk [88.98.24.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA60C12955C for <dns-privacy@ietf.org>; Fri, 28 Oct 2016 03:22:09 -0700 (PDT)
Received: from [62.232.251.194] (port=5028 helo=virgo.sinodun.com) by shcp01.hosting.zen.net.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <sara@sinodun.com>) id 1c04IN-000616-JY; Fri, 28 Oct 2016 11:22:06 +0100
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>
X-Mailer: Apple Mail (2.3226)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - shcp01.hosting.zen.net.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - sinodun.com
X-Get-Message-Sender-Via: shcp01.hosting.zen.net.uk: authenticated_id: sara+sinodun.com/only user confirmed/virtual account not confirmed
X-Authenticated-Sender: shcp01.hosting.zen.net.uk: sara@sinodun.com
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
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 10:22:11 -0000

> On 27 Oct 2016, at 19:28, Paul Hoffman <paul.hoffman@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. 

> 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’.  

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. 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. 

Sara.