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

Bob Harold <rharolde@umich.edu> Fri, 28 October 2016 15:27 UTC

Return-Path: <rharolde@umich.edu>
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 9F2DC129407 for <dns-privacy@ietfa.amsl.com>; Fri, 28 Oct 2016 08:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 Y-pz1jIlBFvs for <dns-privacy@ietfa.amsl.com>; Fri, 28 Oct 2016 08:27:05 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88451294F4 for <dns-privacy@ietf.org>; Fri, 28 Oct 2016 08:27:05 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id g68so37828807ybi.0 for <dns-privacy@ietf.org>; Fri, 28 Oct 2016 08:27:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; 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; d=1e100.net; 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 10.37.219.3 with SMTP id g3mr12656849ybf.23.1477668424726; Fri, 28 Oct 2016 08:27:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.209.70 with HTTP; Fri, 28 Oct 2016 08:27:04 -0700 (PDT)
In-Reply-To: <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> <30ADBA4B-A18B-4537-865B-92076AF546B6@sinodun.com>
From: Bob Harold <rharolde@umich.edu>
Date: Fri, 28 Oct 2016 11:27:04 -0400
Message-ID: <CA+nkc8AyagJSwc=mCEO=xc-jzt7MMUmvEGzpPV3rTDfEYKJ=Lw@mail.gmail.com>
To: Sara Dickinson <sara@sinodun.com>
Content-Type: multipart/alternative; boundary=94eb2c1870548d7412053fee7d2f
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/3-89ocKpsNEH8yauomiwE6lwmMs>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.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 15:27:07 -0000

On Fri, Oct 28, 2016 at 6:21 AM, Sara Dickinson <sara@sinodun.com> wrote:

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