In message <55e63378.3010...@mirix.org>, Matthias-Christian Ott writes:
> Since 6renum is concluded I thought this WG could most likely help to
> address the following problem:
>
> If the IPv6 network of an authoritative nameserver is renumbered and the
> parent zones of zones that are served by
Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-onion-tld-00: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://ww
Since 6renum is concluded I thought this WG could most likely help to
address the following problem:
If the IPv6 network of an authoritative nameserver is renumbered and the
parent zones of zones that are served by the nameserver contain glue
records for the nameserver, the glue records need to be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/01/2015 07:39 PM, Jacob Appelbaum wrote:
>
> Tor doesn't leak .onions
>
> If the name is reserved and the process is followed, we'll hopefully
> be able to stop most of the leakage in the DNS.
>
One clear example that was documented earlier
On Sep 1, 2015, at 6:06 PM, John R Levine wrote:
> That's what I said. "It's more work than we were willing to do" is a
> reasonable criterion, but it's not the same as "it's impossible".
I think it’s "fixing this would involve pervasively fixing a wide range of
software we didn’t write and do
On 9/1/15, John R Levine wrote:
> Speaking of which ...
>
>> It is a critical flaw that fails open. The DNS continues to work but
>> users are put into harm's way. ...
>
>>> Also please keep in mind that we're having this discussion because of
>>> design tradeoffs in the implementation of Tor. If
In message , "Joe Abley" writ
es:
>
>
> On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
>
> > In my view and the DNS has a critical flaw: it does not provide query
> > privacy.
>
> You're on the wrong list. The people working on DNS privacy are over at
> DPRIVE. For the problem statement, se
Speaking of which ...
It is a critical flaw that fails open. The DNS continues to work but
users are put into harm's way. ...
Also please keep in mind that we're having this discussion because of
design tradeoffs in the implementation of Tor. If they'd made onion a
URI scheme rather than a p
I'm aware of the context, I'm a co-author of the RFC in question. The
solution you present is not practical for integration across most
programs without huge modifications to nearly every program.
That's what I said. "It's more work than we were willing to do" is a
reasonable criterion, but it
On 9/1/15, John R Levine wrote:
>>> Please do not put words in my mouth. They're important but they're not
>>> a
>>> DNS problem.
>>
>> I think reasonable people might disagree?
>
> Not really. It's a layering issue.
It is a design flaw from an era when fax machines roamed the earth.
>> In my
Please do not put words in my mouth. They're important but they're not a
DNS problem.
I think reasonable people might disagree?
Not really. It's a layering issue.
In my view and the DNS has a critical flaw: it does not provide query privacy.
It can't be a critical flaw -- if it were we'd
On 1 Sep 2015, at 11:45, Jacob Appelbaum wrote:
In my view and the DNS has a critical flaw: it does not provide query
privacy.
You're on the wrong list. The people working on DNS privacy are over at
DPRIVE. For the problem statement, see RFC 7626, recently published.
Joe
___
On 9/1/15, John R Levine wrote:
>>> In any event, from the point of the DNS, a reservation that just says
>>> don't resolve .onion would be quite adequate.
>>
>> You may consider the privacy leakage issues of no consequence. Others do
>> not.
>
> Please do not put words in my mouth. They're
In any event, from the point of the DNS, a reservation that just says
don't resolve .onion would be quite adequate.
You may consider the privacy leakage issues of no consequence. Others
do not.
Please do not put words in my mouth. They're important but they're not a
DNS problem.
R
> On 1 Sep 2015, at 10:35 pm, John Levine wrote:
>
>> This is a language quibble. I said ICANN had no mechanisms for
>> specifying how a domain should be handled, and I would think a SHOULD
>> specification is exactly that in formal language.
>
> ICANN has vast sets of rules about how GTLDs are
>This is a language quibble. I said ICANN had no mechanisms for
>specifying how a domain should be handled, and I would think a SHOULD
>specification is exactly that in formal language.
ICANN has vast sets of rules about how GTLDs are handled at the server
end. They have rules about DNSSEC and ab
16 matches
Mail list logo
