In my view we need to consider different privacy issues in the
stub-resolver and resolver-authoritative interactions.
In the stub-resolver interaction the primary objective is to encrypt
requests and responses without impacting latency.
For a heavily trafficked resolver, the resolver-authoritativ
* Stephane Bortzmeyer:
> On Sat, Mar 08, 2014 at 06:07:48PM +0100,
> Florian Weimer wrote
> a message of 17 lines which said:
>
>> > It is. Section 2.2.2
>>
>> Can you quote it here?
>
> 2.2.2. In the authoritative name servers
Ahhh, this section heading is wrong, the section is actually
d
I think we need some use cases to ground discussion. These are the use
cases I have been considering:
A) Alice, surfing the Web from her own machine at home does not want her
Web browsing history to be revealed to other parties.
A1) Note here that Alice might also use the same machine to access
On Sat, Mar 08, 2014 at 06:07:48PM +0100,
Florian Weimer wrote
a message of 17 lines which said:
> > It is. Section 2.2.2
>
> Can you quote it here?
2.2.2. In the authoritative name servers
A possible solution would be to minimize the amount of data sent from
the resolver. When a r
> ?I don't even see DNSSEC helping much here, either, given that the
attacker could just strip out the DNSSEC
> info (unless, perhaps, the home computers were running full (vs stub)
recursive resolvers that also did DNSSEC-validation).
Recursive resolvers, if run responsibly can help alleviate som
* Stephane Bortzmeyer:
> On Sat, Mar 08, 2014 at 05:50:55PM +0100,
> Florian Weimer wrote
> a message of 22 lines which said:
>
>> The -sol draft mentions QNAME minimization without defining the
>> term.
>
> It is. Section 2.2.2
Can you quote it here? It seems to be missing from the 00 versi
On Sat, Mar 08, 2014 at 05:50:55PM +0100,
Florian Weimer wrote
a message of 22 lines which said:
> The -sol draft mentions QNAME minimization without defining the
> term.
It is. Section 2.2.2
I'll add some more cross-references to make it easier to find it.
_
* Stephane Bortzmeyer:
> I just posted a new version of the DNS privacy draft,
> draft-bortzmeyer-dnsop-dns-privacy-01. The most important difference
> is that it is now split in two, one pure problem statement,
> draft-bortzmeyer-dnsop-dns-privacy and an exploration of possible
> solutions, draft
On 8 Mar 2014, at 09:00, Mark Andrews wrote:
> But they get told to do EPP to talk to the registries.
Correction: some registrars are obliged to use EPP to talk to some registries.
The followup to that is all TLD registries are exactly the same. Except where
they are different.
Even in ICANN
On Sat, 8 Mar 2014, Mark Andrews wrote:
Our audience should be the CPE developer with the one "turn on
DNSSEC" button which generates the keys, signs the zone, pushes
keys upstream at the right time. It has a username/password field
for zones where it is not automatically installing KEY records
In message , Paul Hoffm
an writes:
> On Mar 7, 2014, at 10:05 AM, Mark Andrews wrote:
>
> > I know Registrars don't like to be told what to do
>
> +1
But they get told to do EPP to talk to the registries.
They have failed to invent / document a common standard way for
machine updates to w
11 matches
Mail list logo
