Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?

Sara Dickinson <sara@sinodun.com> Tue, 13 December 2016 15: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 AE148129AED for <dns-privacy@ietfa.amsl.com>; Tue, 13 Dec 2016 07:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 WGMnmgZdDzBw for <dns-privacy@ietfa.amsl.com>; Tue, 13 Dec 2016 07:22:54 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08DB1293E3 for <dns-privacy@ietf.org>; Tue, 13 Dec 2016 07:22:53 -0800 (PST)
Received: from [2001:b98:204:102:fffa::a] (port=52239) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <sara@sinodun.com>) id 1cGoup-0000U0-Kt; Tue, 13 Dec 2016 15:22:52 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <20161210085205.GA6532@laperouse.bortzmeyer.org>
Date: Tue, 13 Dec 2016 15:22:50 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <73C3176A-9A02-4CD4-9632-E8DE690AD961@sinodun.com>
References: <6cdc7899-f0f4-e735-a844-1a40bf1314fb@gmail.com> <EF0487AF-5D73-417F-A4C3-F3D42CCA3E05@sinodun.com> <20161210085205.GA6532@laperouse.bortzmeyer.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3251)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: State = no_sa; Score =
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/nQBPL-3OgVvSl7t1S2ZNLMr1RjQ>
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] More WGLC reviews for TLS Profiles draft?
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: Tue, 13 Dec 2016 15:22:55 -0000

> On 10 Dec 2016, at 08:52, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> On Thu, Dec 08, 2016 at 09:51:51AM +0000,
> Sara Dickinson <sara@sinodun.com> wrote 
> a message of 138 lines which said:
> 
>> Just to follow up on Tim’s mail. Any reviews of
>> https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/ <https://datatracker.ietf.org/doc/draft-ietf-dprive-dtls-and-tls-profiles/> would be much appreciated to try to wind up the WGLC asap.
> 

Hi Stephane, 

> I've read draft-ietf-dprive-dtls-and-tls-profiles-07 and I've little
> to add to what I said in
> <https://mailarchive.ietf.org/arch/msg/dns-privacy/qKI3hnyCDywqYqCxFIyRDkYOvIA>
> The points I raised there have been well addressed.

Thanks for that. 

> 
> I'm still a bit concerned about the issue of detection (that there is
> an attack). Detection for passive attacks is only possible if there is
> a prior history, unlike the detection for active attacks,

I’m not sure it is true that detection requires prior history, it just makes any attack more obvious. In this text

  "However, if it is available and the user is informed that
   an unencrypted connection was used to connect to a server then the
   user should assume (detect) that the connection is subject to both
   active and passive attack since the DNS queries are sent in clear
   text.  This might be particularly useful if a new connection to a
   certain server is unencrypted when all previous connections were
   encrypted. "

I was trying to indicate that simply using clear text is essentially the same as an attack because the traffic _can_ be subject to passive eavesdropping. 

Would it help to replace the “N, D” labels in the table with just “N” and update the text to say “N == no protection, may be subject to attack”

Sara.