This is what I added in new version of CGA-TSIGe when I considered the
encryption and talked about encryption. It wasn't clear in the draft and
some people asked me about that.
Best,
Hosnieh
From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of
Guangqing Deng
Sent: Friday, May
Paul,
Data integrity is different than authentication. I am not talking
about data integrity. If you can verify the data integrity of a node,
it doesn't mean that it is authenticated. DNSSEC, at the moment is
unable at the moment to protect his last mile and your draft is
supposed to
I change my story a bit based on some offlist discussions ...
So the point 1 from summary email changes like this
1- Opportunistic encryption is not appropriate for the privacy of stub
resolver to recursive resolver scenario unless the node has a possibility to
authenticate this resolver.
If you
On Wed, 20 Aug 2014, Hosnieh Rafiee wrote:
The important thing is stub resolver is not recursive resolver and
the expectation of querying different authoritative DNSSEC server for
this verification seems to be impractical.
So you have two choices in that case:
1 Become a dnssec
Hi Stephane,
-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
Sent: Monday, October 27, 2014 9:23 AM
To: Hosnieh Rafiee
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] What about CGA-TSIG as a solution for DNS
privacy?
On Mon, Oct 27, 2014 at 08:03
On Mon, Oct 27, 2014 at 09:55:08AM +, Hosnieh Rafiee
hosnieh.raf...@huawei.com wrote a message of 28 lines which said:
This is the problem of IETF mailinglist that categorized my message
automatically under your thread here
I strongly doubt it, since *your* message included
Hi Paul,
On Oct 27, 2014, at 1:03 AM, Hosnieh Rafiee hosnieh.raf...@huawei.com
wrote:
I guess you have heard about CGA-TSIG. What do you think about the
approach explained there?
Is still has many confusing dependencies that make it hard to
understand, and it vastly oversells the IPv4
So why do you think it is distraction for the WG that addresses
privacy?
I said I thought it was a distraction; discussing it further would be
more of a distraction.
Unfortunately, I haven't received any answer to the question that why it is
distraction?. I only received ambiguous answer
Hi Phillip,
Thanks for your message. I tagged my message with my name since I converted it
to text.
TSIG is only authentication so you have to add encryption. And the original
TSIG assumed keys would be passed out of band so it needs a key exchange.
[Hosnieh] Yes that is true. It is only
Hi Christian,
Thanks for sharing your opinion about current approaches and also CGA-TSIG.
If we do change the client and resolver, a number of alternatives can
be used, such as:
* Use the same trick as CGA but encode the hash of the certificate as a
name part, e.g.
Hi,
There is one question from folks. There are some existing approaches that does
not change DNS protocol. There are also new proposal that needs change on DNS
protocol.
For example, my proposal, cga-tsig, does not change DNS protocol. So is there
any decision for the scope of solution
Hi Warren,
On , Warren Kumari wrote:
On Wed, Feb 18, 2015 at 3:26 PM, Hosnieh Rafiee i...@rozanak.com
wrote:
Does it mean that you want to only go with solution to change DNS
protocol?
You don't want to put any other solution in agenda which doesn't
change much
the DNS protocol such as cga
Question: Is anyone proposing that we can achieve DNS privacy while
maintaining the current practice of the client defaulting to the DNS server
advertised in DHCP?
Yes, cga-tsig *might* be an option but for DHCP security, it is dependent to
SAVI-DHCP or any monitoring mechanism in the
I'm not. Currently, it's really too confused for me, and backed by
dubious claims.
Is it the same as new version? my explanation wasn't clear? What did you find
confusing?
___
dns-privacy mailing list
dns-privacy@ietf.org
[mailto:dns-privacy-boun...@ietf.org] On Behalf Of Bob Harold
Sent: Friday, February 27, 2015 4:14 PM
To: Hosnieh Rafiee
Cc: dns-privacy@ietf.org
Subject: Re: [dns-privacy] invitation for review
Hosnieh,
Rather than rereading the whole document, could you tell us which sections
changed? Or submit
Are you interested on working on CGA-TSIGe and would you like to
devote some (10 minutes) of the meeting time in Dallas to a
presentation / discussion on CGA-TSIGe?
I'm not. Currently, it's really too confused for me, and backed by
dubious claims.
Same here, at least that was
:
with almost no clear change on DNS protocol.
Stop playing with words: if it requires a change in both client and
server, it
*is* a change in the protocol (even if the DNS part is unmodified, which
is, for
instance, the case with DNS-over-TLS-on-new-port). If it can be deployed
Hello,
I received this note from my domain registrar that ICANN is going to expose
the information of domain holder to whois requests.
https://www.respectourprivacy.com/
Any comment?
Best,
Hosnieh
___
dns-privacy mailing list
dns-privacy@ietf.org
But it is completely unrelated to this working group: whatever ICANN
decides on this matter, the DNS will leak information (and we are here
to limit this leak: let me remind you that qname minimisation is
currently in Working Group Last Call in dnsop).
+1. If you want to have a
Just correcting a part of the sentence that the meaning was different.
In other word, the privacy of DNS server and data that are stored in the
DNS server are also important but at the moment this group did not focus on
them. Especially when considering the NFV and a virtual DNS server, then...
that it is similar to the other draft related
to DTLS,
It appears that I have problem to differentiate your work from the already
existing drafts.
Best,
Hosnieh
From: zuop...@cnnic.cn [mailto:zuop...@cnnic.cn]
Sent: Thursday, July 16, 2015 10:59 AM
To: Hosnieh Rafiee
Cc: dns-privacy; yaojk
Hi All,
The part of your approach is really familiar to me...carrying public key in the
same message and adding it in the additional section, encrypting the DNS
message
Have you take a look on
https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig draft or aware of
this work (section
Follow up,
I think I missed a part that look a bit incorrect.
snip
a key agreement value encryption (the session key)
/snip
Moreover, the use of CA means that all recursive resolvers need to either pay
to a public CA to sign their values so that all clients' stub resolver can
verify the
23 matches
Mail list logo
