On Mon, Mar 11, 2019 at 05:58:13PM +0100,
Stephane Bortzmeyer wrote
a message of 19 lines which said:
> [Sorry for the long list of working groups but the discussion already
> started in different places.]
> It was suggested to have a side meeting in Prague at IETF 104. I
> propose monday
On 20/03/2019 05:46, Brian Dickson wrote:
> On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell
> wrote:
>
>>
>>
>> On 20/03/2019 03:17, Brian Dickson wrote:
>>
>>> - If a network operator has any policy that is enforceable, ONLY the
>>> technical policy enforcement model scales.
>>
>> My mail was
> On Mar 19, 2019, at 11:17 PM, Brian Dickson
> wrote:
>
>
>
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell
> wrote:
>
> Hiya,
>
> One individualistic data point on this sub-topic, and a real point:
>
> On 20/03/2019 01:13, Jared Mauch wrote:
> > My impression is there are people who
[There is actually a proposal at the bottom of this e-mail. Bear with me.]
On 20 Mar 2019, at 11:09, Jared Mauch wrote:
> Often as an industry we may discuss various solutions that are great for
> oneself but don’t scale when looking at the big picture.
I think what we are seeing is the fundam
There's still no link to meeting agenda of dnsop sessions on the
IETF104 agenda page: https://datatracker.ietf.org/meeting/104/agenda/
Is it some kind of operation error or is the agenda still unavailable?
If it's the latter, when can we expect to see it?
--
JINMEI, Tatuya
___
Hi
I've been trying to push out a version but has been tied up in all day work
meetings this week with poor internet sadly.
We should have one up today.
Tim
On Wed, Mar 20, 2019 at 10:32 AM 神明達哉 wrote:
> There's still no link to meeting agenda of dnsop sessions on the
> IETF104 agenda page: h
All
I've put together a rough agenda from our agenda requests and uploaded
into the data tracker:
https://datatracker.ietf.org/meeting/104/materials/agenda-104-dnsop-00
I've probably missed something in our email, but don't blame the other
chairs for anything. I will be in Prague Thursday even
I'm trying to balance in my mind the requirements to protect the DNS vs. what
is happening on the wire, in the end, the browser will connect to an IP address
which can be (in most case) mapped to a domain name, which we're trying to
protect/hide with all sorts of encryption. Someone that has ac
On 3/20/19 12:59 PM, Jacques Latour wrote:
I'm trying to balance in my mind the requirements to protect the DNS vs. what
is happening on the wire, in the end, the browser will connect to an IP address
which can be (in most case) mapped to a domain name
I don't think this second assertion is
At Wed, 20 Mar 2019 12:38:05 +0100,
Joe Abley wrote:
> > Often as an industry we may discuss various solutions that are great
for oneself but don’t scale when looking at the big picture.
>
> I think what we are seeing is the fundamental tension between privacy and
control. You need to give up som
It's not what you access, it's what you block, since reverse DNS is not a good
solution in this instance, you need to map the DNS block list to it's IP
addresses and block those IPs, and readjust based on TTL, you'll end up
blocking more stuff than intended, huge mess, but if you can't trust the
On Tue, 19 Mar 2019 at 13:37, Christian Huitema wrote:
>
> On 3/19/2019 12:50 AM, Eliot Lear wrote:
>
> On 19 Mar 2019, at 01:50, Matthew Pounsett wrote:
>
> Somewhere up-thread it was suggested that there are other reasonable steps
> that a network/security operator can take to maintain the con
On Tue, 19 Mar 2019 at 13:45, Ted Hardie wrote:
>
>> I have a relationship with my users and I can control the configuration
>> of their *known* applications. I do not have a relationship with the
>> malware author that is trying to steal their data, and cannot control the
>> configuration of th
It’s also about DLP and other related topics. There is a deep well here we keep
tiptoeing around. Some things are mitigated by enterprise certificates and
others are far more tricky.
Doing this with DNS helps with that defense in depth. Removing that layer of
defense will increase risks on one
On Wed, 20 Mar 2019 at 07:38, Joe Abley wrote:
> [There is actually a proposal at the bottom of this e-mail. Bear with me.]
>
And it's a good proposal!
>
> Standardise this privacy mechanism, and specify (with reasoning) that it
> should be implemented such that the existence of the channel (b
> Il 20 marzo 2019 alle 12.38 Joe Abley ha scritto:
>
> Seems to me that there's a middle ground within sight here.
>
> Standardise this privacy mechanism, and specify (with reasoning) that it
> should be implemented such that the existence of the channel (but not the
> content) can be identif
A new Request for Comments is now available in online RFC libraries.
BCP 222
RFC 8552
Title: Scoped Interpretation of DNS Resource Records
through "Underscored" Naming of Attribute Leaves
Author: D. Crocker
Status:
A new Request for Comments is now available in online RFC libraries.
BCP 222
RFC 8553
Title: DNS Attrleaf Changes: Fixing Specifications
That Use Underscored Node Names
Author: D. Crocker
Status: Best Current Pract
18 matches
Mail list logo
