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

Bob Harold <> Thu, 27 October 2016 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4666D1295D9 for <>; Thu, 27 Oct 2016 11:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tAmbY2h8yWgd for <>; Thu, 27 Oct 2016 11:03:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 300D7127078 for <>; Thu, 27 Oct 2016 11:03:21 -0700 (PDT)
Received: by with SMTP id w3so52027550ywg.1 for <>; Thu, 27 Oct 2016 11:03:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4emgbG4zxOonyb6/v4bD3Zk8YAVfVpjZD5KoZcchzB0=; b=m7dL+2CSJV20dpD/6evN2441KCCEefpbOudksETyAlNI2YU1fzTK5uWFxXdwoMX6iF AwAU2avUk7uCne2jnccfHuBKSgqXAOsyEhoIJPxXgrl4y9XMbWCgVMSkhNFdUO5xS1dM ROJrxjySx8Sb04SIGkxBB7GObFVlSOL8gpsRczi7a6nisgqyTXHiboA6D1QWAY01a66c TRwkLFNmFYrMZj3Y1NVTLYi4pNSZzIdYmBImo2eEBQ7xrZQGAIAbSP96C+iXEC7t/sKy w7tWuSYxLw6qADw8+QufZV7b06iq1kDxipgYWwzsH+UrJSkq4vXzIJ+LUvr/rOW1gKME e2JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4emgbG4zxOonyb6/v4bD3Zk8YAVfVpjZD5KoZcchzB0=; b=QYDisJsS3J4/yiwHzvn6YyD5+uWeiQzJyIqICsrQlCMLdUmVzKs25w/ce+SVQB8JMD riLZR6Qlw18FOEkSrhPnKKuZMZ1dxu/j6WDs1eupIQozjds3biYs/+QmhpVzn+XC1gUd zBS/cf1rKu9xmOd8gUnF1LOM7majTbFmpzdydlrdkhBrPgwO0/Hq/l0IXcfMEHJg74zw aUZ7Fl35IY5/xCuzBtLEsvB4C8eo0d8o8KXVmKPWP1uOE9XzFtpuY7DogVBvrkvMgFfj CQNLB6G1FBO7Pa1uHTttD2c7UrmPgQzEUKE/CkCBqQu6nj9gaUhJi+INPWzudoqo6JtO 2YjA==
X-Gm-Message-State: ABUngveb6FtBW7wikM1DWhfYIGG+Qp3PUjo7bCOdQbTOSpZ3W6poMzvY40dV1D++uR/iVvkoGJ8vc47vq8PnBgIb
X-Received: by with SMTP id n126mr8149336ywe.279.1477591401071; Thu, 27 Oct 2016 11:03:21 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 27 Oct 2016 11:03:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Bob Harold <>
Date: Thu, 27 Oct 2016 14:03:20 -0400
Message-ID: <>
To: Sara Dickinson <>
Content-Type: multipart/alternative; boundary="94eb2c03557895e171053fdc8efd"
Archived-At: <>
Cc: "" <>, Paul Hoffman <>
Subject: Re: [dns-privacy] draft-ietf-dprive-dtls-and-tls-profiles: strict privacy
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Oct 2016 18:03:24 -0000

On Thu, Oct 27, 2016 at 12:43 PM, Sara Dickinson <> wrote:

> I didn’t get any further feedback on this so didn’t include the text in
> the next version (which I really should have). I’d like to think we could
> work on improving this text to paint the correct picture of the 2 classes
> of user and which profile is most suitable for them?
> I apologize for not giving feedback at the time; I was waiting for other
> people to chime in and then forgot.
> My bad, I should have included the text regardless.
> That text is really good. However, instead of at the end of Section 4, I
> would put it right after Table 1, replacing "Since Strict Privacy provides
> the strongest privacy guarantees it is preferable to Opportunistic Privacy”.
> Yes indeed - I meant at the end of section 4.2 which is exactly there.
> Also: why is "hard failure" the fourth bullet describing Opportunistic
> Privacy? That would only apply to Strict Privacy, correct?
> Not necessarily. From RFC7435: “Opportunistic security protocols may
> hard-fail with peers for which a
>   security capability fails to function as advertised. “
> Yes, I saw that there, but it makes no sense in this document because we
> explicitly allow for both going to no TLS and not telling the user about
> whether TLS is in use. I think that bit in RFC 7435 only applies to systems
> where the user sees that TLS is in use. We really should take it out of
> this document; otherwise, we have to add in a lot more about users knowing
> about the use of TLS.
> 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.
> 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?
> Sara.
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.

Bob Harold