Re: [Add] meeting hum: should the IETF take up this work?

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 27 July 2019 21:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B1312007A for <add@ietfa.amsl.com>; Sat, 27 Jul 2019 14:52:46 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 uO_sgCfkeUqN for <add@ietfa.amsl.com>; Sat, 27 Jul 2019 14:52:44 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522C3120052 for <add@ietf.org>; Sat, 27 Jul 2019 14:52:44 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 427143818C; Sat, 27 Jul 2019 17:52:22 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 460DB5D3; Sat, 27 Jul 2019 17:52:42 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eric Rescorla <ekr@rtfm.com>
cc: ADD Mailing list <add@ietf.org>
In-Reply-To: <CABcZeBPZBksubxV6WANToTWB=LbTbRKksv6f87taDLW4A0Bpeg@mail.gmail.com>
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <AAEA003A-58DB-4FEE-81B2-BBFE9BBB2A37@rfc1035.com> <CAChr6SwA+HM4u5-xpUxQXPH8G8k7sfm6AETJJ019HE=bsq+OXA@mail.gmail.com> <8F094057-DFBC-4732-9DA4-BE46E7914C8A@rfc1035.com> <20190724165951.GB29051@laperouse.bortzmeyer.org> <821B448B-F7EA-46A5-837D-DA0E8C60643A@open-xchange.com> <d653d422-4a71-9fab-fd2e-b8ddaa476f91@nostrum.com> <25583.1564181379@dooku.sandelman.ca> <CABcZeBNnajRyEtOdhk2nS7uNgQM_z04FbEyxSFWMQ8ho82dPiQ@mail.gmail.com> <1856.1564239150@localhost> <CABcZeBPZBksubxV6WANToTWB=LbTbRKksv6f87taDLW4A0Bpeg@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 27 Jul 2019 17:52:42 -0400
Message-ID: <29249.1564264362@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/_bK63Vkt2Q9_4fJa1ElEb47Xc8Y>
Subject: Re: [Add] meeting hum: should the IETF take up this work?
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2019 21:52:47 -0000

Eric Rescorla <ekr@rtfm.com> wrote:
    > If the extension said what the privacy was, rather than just that
    > Mozilla
    > had vetted it, then perhaps there could be other levels of privacy.

    > It's not quite clear to me what you have in mind here, but one thing I
    > would like to emphasize is that the Mozilla TRR program is more than
    > just a self-assertion about privacy policy, in that we actively manage
    > the list, rather than just trusting people's self-assertions. If people
    > were interested in some other set of privacy policies, then it's not
    > clear to me who would be responsible for running such a program.

I'm not clear either at this point, because we don't have any feedback from
any other entities.  There seems to be significant interest in having TRRs
running internal to enterprises, for the benefit for BOYDs, which would do as
much as possible in that environment.

It might be that some TRR's are unable for local legal reasons to comply
to the exact same criteria as Mozilla would like for a TRR to be used by the
general public.   For instance, enterprises might be required by some other
local law to retain detailed data for 24 hours or something like that, but
not disclose it without judicial review. 

The fact that Mozilla is not just depending upon self-assertions is part of
what is of interest to end users, I think.  While a policy OID might work for
some things, I agree that it is probably a self-assertion.  It could be more
complex:  The CA signing might actively investigating before signing such
a policy OID, or a third party might be providing a separately signed
assertion that goes into a (new?) extension.

I will drop this here, as I think you've answered my query as to the degree
of interest Mozilla has.


-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-