ith issues in a timely manner so that the WG can keep
focus and we can move that document on the IETF review. This still gives the
ADD WG more than the 45 minutes of drafts discussion for their group in their
current agenda.
--Paul Hoffman
smime.p7s
Description
(we're in a slot with the ADD WG, and
they have three draft that about to go to IESG ballot), but it would be great
if we can spend it working on issues instead of the typical slideware
presentation just listing the issues.
--Paul Hoffman
smime.p7s
Description:
Belated thanks for your proposed changes! It has taken this time for the three
document authors to be around at the same time.
On Aug 30, 2022, at 2:09 PM, Puneet Sood wrote:
> Suggest DoET or DoQTH as abbreviations for encrypted transports. Using
> DoET in my comments below for conciseness.
W
they
review and hopefully implement the document.
--Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
27;s a good catch! We will fix that in the new draft that should
be coming out in a day or so.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Mar 2, 2023, at 10:11 AM, Hollenbeck, Scott
wrote:
>
>> -Original Message-
>> From: Paul Hoffman
>> Sent: Wednesday, March 1, 2023 2:51 PM
>> To: Hollenbeck, Scott
>> Cc: dpr...@ietf.org
>> Subject: [EXTERNAL] Re: [Ext] [dns-privacy] Inte
course we're happy to
revise it during or after WG Last Call if issues are raised.
--Paul Hoffman (also for dkg and Joey)
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Arrrgh, I turned in the wrong version. Please hold for -05.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
lks at the Hackathon
have time to write up their comments.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
over
> TCP - Implementation Requirements) and 9210 (DNS Transport over TCP
> - Operational Requirements).
The document is talking about both. The mechanics have to be in the
implementation, but they have to be turned on in configuration by the operator
deploying the implementation.
--Paul Hoff
final document
be more useful.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
with all of the WG Last Call issues raised, except
one. We didn't understand "## E" in Yorgos' message from April 7. Yorgos: could
you reformulate that concern based on the -06 draft?
> Thanks to everyone who has provided feedback to date!
Indeed! The draft feels much
ersion. This is a known problem with the RFC series today.
>
> 4.6.11 “a encrypted” -> “an encrypted”
Fixed, and in a few other places.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
We have turned in -07, which covers Yorgos' issues (thanks!) and the int-dir
review (thanks!). We believe it is ready to move to IETF Review.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinf
progress when there are others who have already implemented it.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
are no criteria that say "this
experiment succeeded" or "this experiment failed".
It will take much less IETF effort to fix the charter now than it will to move
the already-deployed protocol to standards track. We might as well bit the
bureaucratic bullet now and just f
ture are minimized.
How would you put that (legitimate!) concern into a criterion for the
experiment?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
the responses.
> Maybe we should first experiment, and then create an updated document that
> becomes a standard.
Yep, that's what we are discussing. What criteria would you use to determine
the success of the experiment?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
tion. Case in point:
> "PGM Reliable Transport Protocol Specification" (RFC 3208)"
Earlier in that same document, it says what is an expriemental protocol, and
this draft doesn't match that description at all.
> So I think it best to no longer delay this draft, publish it as experimental
> and gain experience in how this actually works.
Without more detail about what you want to observe or measure in this
experiment that wouldn't be observed or measured for any normal standard, it's
hard to agree with that assessment.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
resolver on 853. Should we
> | explicitely ban this practice?
Thanks for the specifics! We do explicitly ban this practice, but it is
definitely also worth noting in the document that this could happen. It is
definitely one of the operational considerations.
mple of this?
I was; now I'm not.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
, add some operational
observations, and move it to standards track".
I'll issue a new draft with the new status, and add text about recursive
resolvers doing DoT and/or DoQ for stub resolvers, as well as being
authoritative servers on the same addr
Here is my first cut of wording for a new operational considerations section to
deal with systems that are both recursive and authoritative on port 853.
Comments are welcome.
As recursive resolvers implement this protocol, authoritative servers will see
more probing on port 853 of IP addresses
ack
> to port 53.
The feeling that I got from the other messages is that the server on 853 is not
lame: it is being authoritative for some names and recursive for all others. If
so, it's not lame at all.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Jun 12, 2023, at 1:46 AM, Florian Obser wrote:
>
> On 2023-06-10 22:48 UTC, Paul Hoffman wrote:
>> On Jun 10, 2023, at 1:38 PM, Philip Homburg
>> wrote:
>>>
>>>> In such a case, resolvers following
>>>> this protocol will look for aut
n 6.5 of [RFC9250] ("Connection Handling")
>
> should be
>
> | Section 5.5 of [RFC9250] ("Connection Handling")
Fixed.
>
> * 4.6.11. Maintaining Connections
> | Some recursive resolvers looking to amortize connection costs, and to
> | minimize latency MAY choose to synthesize queries to a particular
> | resolver to keep an encrypted transport session active.
>
> s/particular resolver/particular authoritative server/
Fixed.
>
> * 5. IANA Considerations
> odd boiler plate
There is no standard for NXIANA boiler plate. IANA always double-checks the
section when documents move to IETF Last Call.
Thanks again for the thorough review!
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Belated thanks for this review. I've accepted many of the nits without note,
but some notes below.
--Paul Hoffman
On Jun 9, 2023, at 1:20 PM, Rich Salz via Datatracker wrote:
>
> Reviewer: Rich Salz
> Review result: Has Nits
>
> Sec 2.2 Is the main point of the first p
On Jun 14, 2023, at 10:08 AM, Florian Obser wrote:
>
> On 2023-06-12 19:48 UTC, Paul Hoffman wrote:
>> On Jun 12, 2023, at 1:46 AM, Florian Obser wrote:
>>>
>>> On 2023-06-10 22:48 UTC, Paul Hoffman wrote:
>>>> On Jun 10, 2023, at 1:38 PM, Philip Hom
tack of editorial comments already in the repo, and can
put out a new draft with all the current text, then one final one with the
results of the steps above.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ot server identifiers), a social media site, some DNS software
developers, and others
=
Can everyone who contributed to this list earlier please verify that their
entry is (entries are) still correct?
Are there other early implementations that we should add?
--Pau
urement and descriptions of observed attack traffic, if any.
>
Are there additional key metrics we should add to the document?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
at changing that to the following would fix the problem you
describe:
But if `R` is unsuccessful (RCODE other than 0, timeout, connection closed):
Does that fix your case and not break other cases?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Jul 3, 2023, at 11:19 AM, Peter van Dijk wrote:
>
> On Mon, 2023-07-03 at 10:50 +0200, Peter van Dijk wrote:
>> On Fri, 2023-06-30 at 16:32 +, Paul Hoffman via dnsdir wrote:
>>> The current wording at the end of 4.6.9 is:
>>>But if `R` is unsuccessf
t doesn't mention probing at all, and the root zone that
>> does no probing.
>>
>> I think this section should be removed before publication.
I'd like to follow RFC 7942 (which is also BCP 202) so we don't get in trouble
during the IESG review.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
to the IESG for publication.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
that I didn't know of any IPR on the draft. I make no
assertion whether or not the Verisign IPR even applies to the draft.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
> Only one prioritization scheme in this section while there were two in
> section 3.4
Section 3 is about authoritative servers, Section 4 is about resolvers. In
general, no one gets too concerned about resource exhaustion in resolvers.
After the deployment experiemt, maybe that will
Please see the -10 that was just submitted. Let us know if we need to make more
changes before you want to move this on to IETF Last Call.
--Paul Hoffman (for dkg and Joey as well)
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org
er to parse though.
Sure, I'll make a run at that for -10 as well.
> # Section 4.2
>
> Is there any chance to also use an IPv6 example ?
>
> EV> Obviously, there was no chance ;-)
We chose to keep the examples consistent with each other.
I'll prep a -10, and we'll submit it next week.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
first will
It is that uncommon for a name server to have one A record and one record?
I'd rather not go all-IPv6 because some readers might think that the discussion
is for v6-only systems. If possible, I'd rather just say "(with one A record
and one record)".
--P
- Section 3, you expand DoT and DoQ here but, they have already been used
> without expansion in 2.2
Fixed.
>
> - Section 4, s/in failed resolutions or significant delay/in failed
> resolutions
> or significant delays/
Fixed.
Again, thanks!
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
value" to
indicate why one would want to do the modeling. If you think we need to say
more, we can do so in the next draft.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ive client who
> associates state with the NS name and reaches 2001:db8::7 first will
>
> Same in 4.5:
Yep, agree, and that should keep our AD happy as well. We will make this change
in -13.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ple nameservers, and that it is
likely that if one server has a failure such as a timeout, the resolver will
try the other nameservers (which may or may not be encrypting).
Are you proposing a shorter value for "damping", or a note saying "1 day is
just the suggested value, you mi
(or not)? - It would be nice if the examples in Section 4.5 that
> don’t list both IPv4 and IPv6 example addresses chose IPv6 as the primary
> example.
>
Yeah, that section got sidetracked. Can fix.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Sep 7, 2023, at 6:58 PM, Bron Gondwana wrote:
>
> On Fri, Sep 8, 2023, at 02:18, Paul Hoffman wrote:
>> Thanks for the review!
>>
>> On Sep 7, 2023, at 7:16 AM, Bron Gondwana via Datatracker
>> wrote:
>>
>> > My only concern is that it d
't defined". It could be added to Section 8, but given my
lack of expertise in captive portals, I would want the specific wording to come
from someone who knows much more. If we can copy the wording from some other
RFC that has the same issue, that would be best.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
can be
> rejected.
Yes, exactly. Even if you can't stop your library from verifying, you must be
able to ignore the verification failures.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
> On Sep 20, 2023, at 2:32 PM, Paul Wouters wrote:
>
> On Tue, 19 Sep 2023, Paul Hoffman wrote:
>
>> We don't know. It was pointed out in the WG discussion that some PKIX
>> libraries do different types of verification regardless of what you want
>> them
g the Recursion Desired (RD)
> flag and the query ID) ?
Yes; fixed.
> I don't think this is an operational consideration
> for unilateral probing.
True, but it didn't exist in any other RFC we could find to reference, so it
seemed reasonable to state it here rather than ignore i
Please accept with a status of "hold for update".
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
NS
Opcode would be 15, which is undefined)."
Has anyone run any tests against currently deployed recursive resolvers and
authoritative servers to see what they do when sent the initial DTLS packet?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Apr 23, 2014, at 8:42 AM, Dan Wing wrote:
> On Apr 23, 2014, at 7:26 AM, Paul Hoffman wrote:
>
>> On Apr 23, 2014, at 6:47 AM, Dan Wing wrote:
>>
>>> For discussion.
>>>
>>> DNS queries and responses are visible to network elements on the p
On Apr 23, 2014, at 11:11 PM, Stephane Bortzmeyer wrote:
> On Wed, Apr 23, 2014 at 09:16:29AM -0700,
> Paul Hoffman wrote
> a message of 39 lines which said:
>
>> Sure. What were the results of your testing?
>
> I quickly tested with .FR authoritative name servers
ically, the DNS Opcode is invalid).
>
>
Sorry, you are right, and I had misread that.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Greetings. I created a new proposal on a simple way to do DNS over TLS between
stubs and resolvers. Comments are appreciated.
--Paul Hoffman
> A new version of I-D, draft-hoffman-dns-tls-stub-00.txt
> has been successfully submitted by Paul Hoffman and posted to the
> IETF repository.
y this first riski step.
>
> Sorry for my long email,
It is not the length that bothers me: it is the attitude of "because I have
this policy for my own traffic, the rest of you cannot have better privacy
because I don't want the protocol to allow it".
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Aug 19, 2014, at 11:12 AM, 神明達哉 wrote:
> At Mon, 18 Aug 2014 10:59:22 -0700,
> Paul Hoffman wrote:
>
>> Greetings. I created a new proposal on a simple way to do DNS over
>> TLS between stubs and resolvers. Comments are appreciated.
>
> I have one few small c
r that blocks TLS
> traffic - is there a way for the resolver to somehow learn in-band on
> port 53 that this attack is happening?
Probably, but you still haven't said what value there is in knowing that. A
stub resolver has no log and no way of alerting anyone that it discovered
somethin
[[ Combined PaulW's and Jacob's responses ]]
On Aug 19, 2014, at 2:01 PM, Paul Wouters wrote:
> On Tue, 19 Aug 2014, Paul Hoffman wrote:
>
>>> I wonder this 'MUST' may be too strong (or I don't fully understand
>>> the sense of this MUST). Sin
On Aug 20, 2014, at 6:30 AM, Jacob Appelbaum wrote:
> On 8/19/14, Paul Hoffman wrote:
>> [[ Combined PaulW's and Jacob's responses ]]
>>
>> On Aug 19, 2014, at 2:01 PM, Paul Wouters wrote:
>>
>>> On Tue, 19 Aug 2014, Paul Hoffman wrote:
>>&
oyment, us knowing what the actual protocol is
would be useful.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
fit here, no?
No, not yet. There is even less DNSSEC coverage in the reverse tree than there
is for normal names.
Updated draft with recent suggestions coming out soon.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Thanks for the comments so far, clearly there is more to come. Even if this
group doesn't go for this design, I think the discussion will be useful to most
of the designs we have seen so far.
--Paul Hoffman
A new version of I-D, draft-hoffman-dns-tls-stub-01.txt
has been successfully subm
gg problem of secure bootstrapping
> from one protocol to the next. It's like one egg that keeps changing
> chickens.
Please look at the draft again; I don't think it is as bad as you are saying.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Aug 29, 2014, at 5:30 AM, Wes Hardaker wrote:
> Paul Hoffman writes:
>
>> On Aug 27, 2014, at 12:46 PM, Wes Hardaker wrote:
>>
>>> But what's the solution? How do we authenticate that resolver? PKIX
>>> won't help us, as there is no name.
advantages. I'm interested to hear what
people think, hopefully after they have read the draft.
--Paul Hoffman
Begin forwarded message:
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-hoffman-dns-tls-stub-02.txt
> Date: August 30, 2014 at 5:44:42
of the operational problems with adding encryption
between iterative (recursive) resolvers and authoritative servers that keep
being brought up are DoS-by-crypto and establishment of trust. And opt-in,
always-oppurtunistic approach could work, although we would then probably have
the "you shou
On Oct 6, 2014, at 8:52 AM, Stephane Bortzmeyer wrote:
> On Mon, Oct 06, 2014 at 08:03:56AM -0700,
> Paul Hoffman wrote
> a message of 93 lines which said:
>
>> Two of the operational problems with adding encryption between
>> iterative (recursive) resolvers and au
can maybe discuss it on
this list. Having two parallel discussion would probably be a bad thing.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
r common use cases.
This sounds like a good addition. We already have at least three proposals that
look similar but have slightly different privacy properties. Having a document
that catalogs these (which is different than what is in the problem statement)
would be useful for both the WG and th
On Oct 12, 2014, at 4:04 PM, Mankin, Allison wrote:
> I would like to request a 5 minute slot to introduce the idea of a draft on
> methods of evaluating DNS privacy.
5 minutes is not enough; it should be more.
--Paul Hoffman
___
dns-privacy m
rger cons:
* The nameserver has to do a Diffie-Hellman key agreement with every relying
party, hugely increasing the CPU load.
* The private key must be online all the time.
* The private key must be shared by all the nameservers.
Remember: DNSSEC is sign-once-and-serve; DNScurve is
serv
On Oct 13, 2014, at 8:20 AM, Paul Wouters wrote:
> On Mon, 13 Oct 2014, Paul Hoffman wrote:
>
>> Ummm, aren't we forgetting what is for many the much larger cons:
>>
>> * The nameserver has to do a Diffie-Hellman key agreement with every relying
>> pa
I support the adoption of this document as a WG item and will review it
actively.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Oct 17, 2014, at 11:59 AM, Phillip Hallam-Baker wrote:
> Won't we need to move to the dpr...@ietf.org list to start the WG discussion?
No, the announcement of the WG being formed said that this list is the WG's
list.
--Paul Hoffman
__
On Oct 18, 2014, at 8:58 AM, Warren Kumari wrote:
> On Fri, Oct 17, 2014 at 5:10 PM, Paul Hoffman wrote:
>> On Oct 17, 2014, at 11:59 AM, Phillip Hallam-Baker
>> wrote:
>>
>>> Won't we need to move to the dpr...@ietf.org list to start the WG
>>>
he stub-to-resolver
> link has already been done. It is called DNScrypt
> <http://dnscrypt.org/>. It is actually deployed
> <http://www.opendns.com/about/innovations/dnscrypt/>
And, after many attempts by people here, it is still undocumented. The is a bit
of a protocol desc
> On Oct 21, 2014, at 2:18 AM, Stephane Bortzmeyer wrote:
>
> On Mon, Oct 20, 2014 at 07:02:01AM -0700,
> Paul Hoffman wrote
> a message of 23 lines which said:
>
>> And, after many attempts by people here, it is still
>> undocumented. The is a bit of a p
aks things like passive DNS collection.
Passive DNS collection is done at recursive and authoritative servers. How
would encryption between the stub and its upstream recursive affect the ability
to collect passive DNS data?
--Paul Hoffman
___
dns-privacy m
rative Resolvers and Authoritative Servers, or provide
end-to-end confidentiality of DNS transactions.
It sounds like you may be concerned about what the WG might do *later*, but
brought it up in a way that seemed to be about what we are doing now.
--Paul Hoffman
__
thwhile problems.
Or: because we don't have the same threat model that you are proposing, and we
want something deployable. Nothing in the current proposals prevents you from
proposing your still-academic PIR proposals for a longer-term solution that
applies to people who agree with your thr
hink?
It is a distraction for this WG and should not be considered.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Oct 27, 2014, at 7:36 AM, Hosnieh Rafiee wrote:
> 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.
--Paul Hoffman
___
dns-priv
On Oct 28, 2014, at 4:48 AM, Brian Haberman wrote:
> https://datatracker.ietf.org/ipr/2469/
Being picky about something that is important: that is a disclosure of a
*patent application*, not a *patent*.
--Paul Hoffman
___
dns-privacy mailing list
e IP addresses, having:
>
> CONSIDERATION NNN: "exposing source IP addresses of DNS queries raises
> privacy risks"
>
> Advice?
My preference is not to have three categories, but just one: problems. Problems
are issues, and problems have considerations, but what the WG need
I moved the discussion to the dnsop mailing list because it is that WG, not
this one, which is discussing the draft-ietf-dnsop-qname-minimisation draft.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman
ength at the beginning of each message, as described in Section
4.2.2 of RFC 1035.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
done before the
first web page request), the speed of the request is the same for an open TCP
connection as it is for a new UDP "connection".
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/li
shows that doesn't work"?
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
personally, I think both are less likely
to succeed than hzhwm-dprive-start-tls-for-dns.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
for it: RFC 4357 has normative references to documents only
in Russian.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Feb 25, 2015, at 4:11 PM, Warren Kumari wrote:
> 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?
No.
___
dns-privacy mailing lis
thanks for the text. Any advice from the WG? (I don't want
> to make important changes in the middle of a WGLC if there is no
> consensus.)
Yep, looks a good addition.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
to typical readers. I'm happy to read the
Introduction section of further revisions and, if one eventually is clear, to
comment then.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
en the stub resolver *would* know
and could make choices based on that.
>From the stub resolver's point of view, TCPINC is no different than running
>over an IPsec tunnel.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
to conceal aspects of ourselves from others. Doing something
> offensive or shameful are good reasons to do so.
+1 on removing "illegal", since that changes with location. Maybe change the
sentence to "...is the domain name of a controversial organization that...".
--Paul H
tly the picture. WG
> advice?
Please make Matthijs' change so that it is clear from the very beginning that
things in the cache are not affected by this work.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
been developed for secure web servers comes to
secure DNS servers for free.
--Paul Hoffman
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On Mar 19, 2015, at 8:49 AM, W.C.A. Wijngaards wrote:
> On 14/03/15 01:19, Paul Hoffman wrote:
> > Greetings again. I mentioned this to Wouters a while ago, before
> > the DPRIVE WG started, but it is worth bringing up here if the WG
> > is considering this for
1 - 100 of 311 matches
Mail list logo
