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

Bob Harold <> Fri, 28 October 2016 15:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F2DC129407 for <>; Fri, 28 Oct 2016 08:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 Y-pz1jIlBFvs for <>; Fri, 28 Oct 2016 08:27:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B88451294F4 for <>; Fri, 28 Oct 2016 08:27:05 -0700 (PDT)
Received: by with SMTP id g68so37828807ybi.0 for <>; Fri, 28 Oct 2016 08:27:05 -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=aVvjD0KtmLwh5/cC2rTPT2JCzizwu/aB5U6ttMFkQhs=; b=Kufa36vld8Ua4jh5GW4d7UjT6b/l1bL3JJIGN846tYoR59qzYDQBNeh5x2KZEci11F qUCDYm6U5InqHnoWhKXIgMWgHYgwOCymzLINGe5PHQ29cQC2raMmiRdRkM2hnWtTZ1Kb 9v6p90+LYIGboNDVzWKovtzkhUT4/nqVO/oEtXLotJ1I2Ph0cJpmqu7MiTfYmde8B55d jqyuIwURaVQ0hl5y9Gpgs6GC5EIslCqTp96PbeCdLmWGOvuvvdTLbtHBs+zh7FwkUL98 m8fDumtJEvVZCuEb0NAarQlHRdNEVSu8ITVcCoCpnxRA2fh9/qNylyAarEETqqTDWgUH 2upQ==
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=aVvjD0KtmLwh5/cC2rTPT2JCzizwu/aB5U6ttMFkQhs=; b=T1M0T4Ru7923Euqi4RY1LG23aBcbne4qIC87sT34OOQjmGoKCRsm8GmEY7g5uWPNZk gt3ekqlixeBReUZxPcbtGMIfAWNPswrWx+80kr4qP+GWVqeyxws9Sx5XtgGoqaQ42tLD uL3m1+LHhrcpeoB40gL/z74eZ6jKlAbpNlajyISxBrN2MOGiJpmRqGQ3X3D6nAaZKDox Db/Kfw3F/uR1Jc8cA6zgtNwLjo+gKH4ECmLQLB0f2p9TpgQR9IyjW/2LZZ8THW+C1Mj1 SDLnh7uuMedkORpE9fA2BPqfWrp/LT1XYb3rtyR33XDESwfFUT6ENkRbmIlVcSJ+pkq9 BywA==
X-Gm-Message-State: ABUngvc6BSrvdIiJAFngFFk/+uvtjiVn5wSn5wPNVuEfJBtK3OHB470V1q5+xhdod0/v4IC6yrQLWjnf6RoN8xCe
X-Received: by with SMTP id g3mr12656849ybf.23.1477668424726; Fri, 28 Oct 2016 08:27:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 28 Oct 2016 08:27:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Bob Harold <>
Date: Fri, 28 Oct 2016 11:27:04 -0400
Message-ID: <>
To: Sara Dickinson <>
Content-Type: multipart/alternative; boundary="94eb2c1870548d7412053fee7d2f"
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: Fri, 28 Oct 2016 15:27:07 -0000

On Fri, Oct 28, 2016 at 6:21 AM, Sara Dickinson <> wrote:

> > On 27 Oct 2016, at 19:28, Paul Hoffman <> 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.
In Section 5 on Opportunistic Privacy, I am not sure "MAY" is correct.  If
the user chooses Opportunistic, I would think the server MUST try to be
secure, in whatever ways are possible, but MAY fall back to less secure,
only if those fail.

Bob Harold