On 3/12/19, 11:40 PM, "Doh on behalf of Christian Huitema"
wrote:
> Why do you think you can filter content? Who made you king?
[JL] End users may have opted into / subscribed to such a parental control
system. An enterprise may say we'll only connect to the Internet and allow
traffic of X
All,
I am saying this with my dprive WG chair hat on...
As Eliot points out, this conversation has deteriorated beyond
repair. I will now politely ask that these non-technical discussions
cease on the dprive mailing list. I would recommend that everyone
document their concerns with DoH
Please see inline
From: Eric Rescorla
Sent: Tuesday, March 12, 2019 9:28 PM
To: Konda, Tirumaleswar Reddy
Cc: d...@ietf.org; dn...@ietf.org; dns-privacy@ietf.org; Vittorio Bertola
; Stephen Farrell
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
CAUTION:
Gentlemen,
This conversation has gone to the zoo. What is or is not political doesn’t
matter at this stage in the game, and neither is arguing over rights over bits.
If people want to do that I suggest doing so in the HRPC WG and with a draft
in hand. Flaming back and forth without an
On 3/12/2019 9:25 PM, Vittorio Bertola wrote:
>> Il 13 marzo 2019 alle 4.39 Christian Huitema ha
>> scritto:
>>
>> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
>>> The reaction I got from some policy people when I mentioned this kind of
>>> arguments going on here is "when did the IETF get
> Il 13 marzo 2019 alle 4.39 Christian Huitema ha scritto:
>
> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
> > The reaction I got from some policy people when I mentioned this kind of
> > arguments going on here is "when did the IETF get the mandate to decide for
> > everyone that content
Hiya,
On 13/03/2019 01:04, Paul Wouters wrote:
> RPZ allows filtering answers which would turn into BOGUS for
> DNSSEC validating clients.
Could well be my terminology was imprecise. What I recalled
from some discussion a year or more ago was that RPZ MUST NOT
change a DNSSEC-signed answer that
On Wed, 13 Mar 2019, Stephen Farrell wrote:
Hmm. Not sure what to make of that. DNSSEC presumably makes it
possible to detect interference, and yet RPZ (IIRC) calls for
not changing DNSSEC-signed answers. I don't get why an inability
to change is ok for the RPZ/DNSSEC context but not for DoH.
Hiya,
On 12/03/2019 22:51, Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
>> On 12/03/2019 21:11, Paul Vixie wrote:
>>> ...
>>
>> There are reasons to want confidentiality for DNS queries
>> and answers, and access patterns, for which the IETF has
>> achieved
On 12/03/2019 21:11, Paul Vixie wrote:
> he's trying to achieve a political aim using technology.
Ok, now I think I understand and am pretty sure I disagree
with you there.
There are reasons to want confidentiality for DNS queries
and answers, and access patterns, for which the IETF has
Paul,
On 12/03/2019 20:51, Paul Vixie wrote:
> just as i've cautioned the RFC 8484 authors against imposing their anti-
> censorship views on my parental controls or corporate network policies, let
> me
> here caution you against imposing your (clearly) western liberal-democratic
> views on
On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <
tirumaleswarreddy_ko...@mcafee.com> wrote:
> Hi Eric,
>
>
>
> In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and
> white-list, black-list and grey-list TLS session based on the server
> identity. In other words,
Hi Eric,
In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and
white-list, black-list and grey-list TLS session based on the server identity.
In other words, middleboxes are conditionally acting as TLS proxies to specific
servers (categorized in the grey-list).
With TLS
On Mon, Mar 11, 2019 at 09:59:11AM +0530,
nalini elkins wrote
a message of 231 lines which said:
> Companies also (validly, in my opinion) wish to know if their
> employees are going to fantasyfootballgame.com while they are
> supposedly doing work and of course, other sites which people
That's what they told me.
On Mar 11, 2019, 14:20, at 14:20, Daniel Stenberg wrote:
>On Mon, 11 Mar 2019, Paul Vixie wrote:
>
>> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24
>
>If that's what you believe and block, then you're not blocking
>Cloudflare DoH
>very effectively... =)
On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie wrote:
>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> > > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to
On Mon, 11 Mar 2019, Paul Vixie wrote:
CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24
If that's what you believe and block, then you're not blocking Cloudflare DoH
very effectively... =)
--
/ daniel.haxx.se
___
dns-privacy
Hi Paul,
> On 11 Mar 2019, at 19:12, Paul Vixie wrote:
>
>
>
> nalini elkins wrote on 2019-03-11 10:26:
>> Tiru,
>> Thanks for your comments.
>> > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is going
> to
18 matches
Mail list logo
