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

Sara Dickinson <> Thu, 27 October 2016 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A19E1294BF for <>; Thu, 27 Oct 2016 09:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bK186gxxg6KR for <>; Thu, 27 Oct 2016 09:49:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79BCC12953F for <>; Thu, 27 Oct 2016 09:43:43 -0700 (PDT)
Received: from [] (port=32118 by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from <>) id 1bznmC-0005Xf-UN; Thu, 27 Oct 2016 17:43:39 +0100
From: Sara Dickinson <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9D72ED7-6616-495F-BC19-03040715A313"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Date: Thu, 27 Oct 2016 17:43:38 +0100
In-Reply-To: <>
To: Paul Hoffman <>
References: <> <> <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
Archived-At: <>
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 16:49:51 -0000

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