This wording in RFC9250 was deliberate. It was discussed in details when
the RFC was written. The current text correctly reflects the result of
these discussions.
-- Christian Huitema
On 4/4/2024 6:38 PM, RFC Errata System wrote:
The following errata report has been submitted for RFC9250
anisms are described in Section 5.4 of [RFC9250].
How much to pad is out of scope of this document, but a reasonable
suggestion can be found in [RFC8467].
-- Christian Huitema
# Section 4.4
Unsure whether the last paragraph has any value... ` a recursive resolver
implementing these strat
he RFC editors. I trust them, but I
will verify that these issues are fixed.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
lient against spoofs.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
of filter based on the client's IP.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ssing [ these points ] improved
the quality of the documents." Thanks to the IESG members for all the
feedback.
-- Christian Huitema
On 3/15/2022 3:40 PM, Christian Huitema wrote:
Pull request https://github.com/huitema/dnsoquic/pull/159 addresses
the second comment from Francesc
e but uses more of the local resource.
-- Christian Huitema
On 3/15/2022 11:39 AM, Christian Huitema wrote:
I have entered issues in our repo for all the reviews by IESG members.
Ben Kaduk submitted an editorial PR, and it was accepted.
There is another PR being processed to address the cla
review.
I will start another PR addressing Francesca and Alvaro's point.
After that, we may need an editorial pass for the other comments.
The goal should be to have a draft ready when the publishing window reopens.
-- Christian Huitema
On 3/15/2022 8:59 AM, Eric Vyncke (evyncke) wrote:
Dear
any possible choices.
-- Christian Huitema
On 3/9/2022 5:46 PM, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-dprive-dnsoquic-10: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To
I support adoption of this draft by the WG.
-- Christian Huitema
On 2/13/2022 5:47 PM, Tim Wicinski wrote:
This starts a Call for Adoption for draft-dkgjsal-dprive-unilateral-probing
The draft is available here:
https://datatracker.ietf.org/doc/draft-dkgjsal-dprive-unilateral-probing/
Please
ired to be completed upon approval of this document.
Note: The actions requested in this document will not be completed until the
document has been approved for publication as an RFC. This message is meant
only to confirm the list of actions that will be performed.
Looks good. Thank you.
On 2/10/2022 12:34 PM, James Cloos wrote:
"CH" == Christian Huitema writes:
CH> and you get 40% of names served by a small number of servers. For that set,
CH> I would expect that the typical DoQ query will be a session resumption.
does quic session resumption correctly
raged more concentration.
-- Christian Huitema
On 2/10/2022 8:07 AM, libor.peltan wrote:
Anyway, do you think that the "typical" recursive-to-authoritative
query in DoQ era will be a session resumption, or a clean new
connection without any chance of 0-RTT or
counter-amplification-limit-toke
d in the paper are a good way to find out the
what deployed servers do: how many enforces Retry on the first
connection, how many support 0-RTT or Session Resumption, how many
enforce amplification limits despite a valid new token? It would be
great if the second version of this measurement pa
nnecessary. It would be
interesting to know why servers chose to do that for all connections.
Are they under constant DOS attacks?
So many questions...
-- Christian Huitema
On 2/8/2022 3:05 AM, James wrote:
Thanks for paper, and your results are very interesting.
One area that would be i
whether others might object.
-- Christian Huitema
On 1/24/2022 5:05 AM, Brian Trammell via Datatracker wrote:
Reviewer: Brian Trammell
Review result: Ready with Nits
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents
ection 10.2.1, which was already slated for removal. This
removes the confusing references to port number 784.
Would that address your concerns?
-- Christian Huitema
On 1/25/2022 9:36 AM, Sabrina Tanamal via RT wrote:
Hi Christian,
See [ST] below.
On Tue Jan 25 02:04:28 2022,huit...@huitema.
rent times to different servers in the farm. Opportunistic
strategies and probing strategies have to deal with that.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
"set right" if there is a way for the application to
somehow specify a QUIC padding policy. Otherwise, better be safe and use
EDNS padding.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
, the more it looks
like we should just do TLS. So in the absence of a really compelling argument
for supporting both, along with all of the future overhead it entails, my
current position is mutual TLS only.
Mutual TLS would work for DoH, DoT or DoQ, so that seems simpler to support.
-- Christi
nd long duration sessions have similar effects on client privacy, and
the text needs to reflect that.
DPRIVE members may want to discuss these issues on the mailing list.
-- Christian Huitema
On 10/14/2021 7:38 PM, Martin Thomson wrote:
I've reviewed this document (straight from GitHub in
Q over future versions of QUIC.
As the text says, no deployment of RFC8904 currently exists to our
knowledge. The reliance on section 17.2 of RFC 9000 is really an
assurance against a very unlikely eventuality, and I cannot see how it
would impact future versions o
suppose these could be delineated in the
guidance RFC.)
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
policy be for those resolvers? Would you let
them use TLS without client authentication, or would you want them to
fall back to clear text?
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns
, the client is probably fine.
And given the simplicity of getting PKI, I don't quite see the point of
an unauthenticated mode. It does not ease the deployment much, and it
paints a thick MITM target. I would rather fall back to Do53 than to
unauthenticated DoT or DoQ.
-- Christian Huitema
On 7/30/2021 5:33 PM, Benjamin Kaduk wrote:
On Fri, Jul 30, 2021 at 05:21:25PM -0700, Christian Huitema wrote:
On 7/30/2021 1:38 PM, Robert Evans wrote:
On Fri, Jul 30, 2021 at 4:02 PM Christian Huitema
wrote:
I think we have a reasonable guideline here. 0-RTT for QUIC is so
compelling
On 7/30/2021 1:38 PM, Robert Evans wrote:
On Fri, Jul 30, 2021 at 4:02 PM Christian Huitema
wrote:
I think we have a reasonable guideline here. 0-RTT for QUIC is so
compelling that clients and servers will still do it, even if we tell them
not to. So it is better to try provide usage
hakes or if ticket is old".
Some QUIC stack will disable 0-RTT if the ticket is older than 30
seconds, only allowing resumption. This is reasonably easy to implement.
-- Christian Huitema
On 7/30/2021 8:56 AM, Robert Evans wrote:
DoQ plus 0-RTT seems very compelling for achieving 1-RTT q
on the client, which
simply abstains to send some classes of requests over 0-RTT.
- Or, of course, allow servers to support 0-RTT without any kind of
filtering.
Any particular opinion in the working group?
-- Christian Huitema
___
dns-privacy mailing
> On Mar 31, 2021, at 10:51 PM, Rob Sayre wrote:
>
>
> On Wed, Mar 31, 2021 at 10:43 PM Christian Huitema
> wrote:
>> I think that's the big motivation behind DoQ. Because QUIC runs over UDP, it
>> makes some things easier than TCP. In particular, I hav
ather wait and see until the technology matures.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
[192.134.4.13]
SMTP error from remote mail server after RCPT TO::
550 5.7.1 : Recipient address rejected:
Please see
http://www.openspf.net/Why?s=mfrom;id=huitema%40huitema.net;ip=138.201.61.189;r=mx5.nic.fr
-- Christian Huitema
___
dns
of RFC 8890.
OTOH, if an implementation (like Chrome) is going to use a dedicated
connection for DoH (H2 or H3), then it probably could just as well use
DoT or DoQ. The only issue is firewalls that would filter based on the
DoT or DoQ ALPN, but ECH/ESNI would easily fix that. Hard to b
operating system resolvers would
normally not mix their queries with existing HTTP sessions, and thus
don't get any advantage from "integrating to the web" -- unless of
course firewall traversal is a big issue.
-- Christian Huitema
On 10/7/2020 8:31 AM, Tommy Pauly wrote:
> DoH is des
Jan,
Should we organize an interop session for the hackathon? I could set up
a page for that.
-- Christian Huitema
On 6/26/2020 11:09 AM, Jan Včelák wrote:
> Hello.
>
> This is just a quick note that I've refreshed the DNS-over-QUIC proxy
> and client code that we wrote at IETF 1
e used for requests to all
domains served by that authoritative server. That's better for both
performance and privacy.
-- Christian Huitema
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
nd
UDP/DoQ are supported. Have you thought about that?
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
mains. If the client really wants privacy, then maybe it should use
ToR or some other mixer to hide its IP address, in which case the debate
is moot.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
out of the rfc7626-bis draft, and start a
separate effort to describe centralization issues.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
of it, maybe just keeping
the very first and the very last paragraph. The text in between does not
add much to the specific topic of DNS privacy. Also, there is the ADD
working group dedicated to discovery and configuration of encrypted
servers. There is no point in anticipating their results.
-- Ch
+1. I too support adoption. I would much rather reference Alessandro's
draft than have to write a paraphrase of it in the DoQ draft.
-- Christian Huitema
On 4/13/2020 7:47 PM, Martin Thomson wrote:
> What Sean said. This is worth doing right.
>
> I've already reviewed Alessandr
sn’t need to
> have any code for checking state. QUIC BTW is based on UDP.
>
And common sense may or may not be right. For many implementations of Quic,
encryptions is not the bottleneck. You can run AES GCM at 20 Gbps or more on a
single CPU thread. The actual bottleneck is the cost of UDP s
fer, up to the Introduction. That would leave Section 3.4 just about the
> stated design goal.
Yes. I would like to end up with just a spec, and leave the discussion
about DoT vs DoQ vs DoH vs DoH3 to some other document...
-- Christian Huitema
___
dns-pr
On 3/6/2020 6:12 AM, Tony Finch wrote:
> Christian Huitema wrote:
>
>> We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
>> for the feedback!
> Looks promising! I have a few comments:
>
> Is the ALPN "dq" or "doq"? 4.1 and 4.
We just resubmitted the DNS over QUIC draft to DPRIVE. Thanks in advance
for the feedback!
-- Christian Huitema
Forwarded Message
Subject:New Version Notification for
draft-huitema-dprive-dnsoquic-00.txt
Date: Thu, 05 Mar 2020 20:46:29 -0800
From: internet-dra
8 networks mentioned as handling 53%
of traffic in Pawel and Oliver's study.
And yes, it is important to monitor these trends.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
the network.
It could also achieve the opposite, but there are risks on both sides of
this issue. I don't see how we can achieve consensus that one side of
the risk is more dangerous than the other.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
nt identifiers, but there is
indeed a difference in complexity between DoH and DoT. Yes you could
minimize it by using an absolutely minimal implementation of HTTP for
DoH, but the very idea of DoH is to reuse existing HTTP infrastructure
for DNS. In practice that means a m
se the same code for receiving DNS requests natively in QUIC
streams or through HTTP POST operations.
On the client side the code is markedly simpler without the HTTP overhead.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
se I would expect recursive
> resolvers to generally be operated by people who are able to establish
> their port 853 status.
Note that port 853 is a convention. Servers could trivially run multiple
services over port 443, and demux based on the ALPN. I suppose that if
we see a lot blockage of port
e in scope?
I would think so, yes.
I am also concerned with attackers "on the side". They too might try to
downgrade the connections from ADOT to clear text. But yes, that should
be the general concern: preventing both downgrade attacks and MITM attacks.
-- Christian Huitema
>
> -Ekr
&g
epend on PKI, because that
would introduce a circular dependency. Using DANE instead of PKI there
seems prudent.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
dea
of a progressive transition without disruption.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
quot;session resumption
ticket" acting as a super cookie, and allowing the server to link the
resumed session with the previous one, thus exposing more of the
client's "history".
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
umed, and with all the
sessions before that in a chain of resumptions. That means the server
can track the client. If the client does not want that, it will not use
session resumption. Hence, the requirement that "Clients should not be
required to use TLS session resumption&
On 3/13/2019 9:56 AM, Livingood, Jason wrote:
> On 3/12/19, 11:40 PM, "Doh on behalf of Christian Huitema"
> wrote:
>
>> Why do you think you can filter content? Who made you king?
> [JL] End users may have opted into / subscribed to such a parental control
>
On 3/12/2019 9:25 PM, Vittorio Bertola wrote:
>> Il 13 marzo 2019 alle 4.39 Christian Huitema ha
>> scritto:
>>
>> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
>>> The reaction I got from some policy people when I mentioned this kind of
>>> argumen
d middle-boxes and filtered
content because they could. They did not exactly try to get a mandate,
or obtain consensus that this was proper. Technologies like DoH force
the discussion in the open. Why do you think you can filter content? Who
made you king?
-- Christian Huitema
the user. You
are claiming that safety mandates giving the network operator full
control over name resolution. Both of these positions come from specific
visions about how the network should work. Neither is more a political
goal than the other.
-- Christian Huitema
_
tled to override the user choices and impose their own. Really?
As Stephane wrote, that may be legit in some circumstances, but much
more questionable in others, such as a hotel Wi-Fi attempting to decide
what sites I could or could not access. It really is a tussle.
-- C
tion.
Just like hotels cannot discriminate against some categories of
customers, I don't think that places providing public connectivity
should be able to discriminate against content accessed by their guests.
-- Christian Huitema
___
dns-privacy mailing list
to decide that
sort of things, in particular for various "shrink wrap" software
licenses. The results vary. Sometimes the courts let the fine print
stand, some times they treat it as an abuse of power and nullify it.
Which points exactly to Stephane's characterization: it is a tussle.
--
the
contractual power of the network is limited -- thinks like fair access,
network neutrality, etc. Just claiming an empire does not automatically
make you the emperor.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
e, there is just
one scenario for which the claim has some legitimacy: if the company
pays for my laptop and own the laptop, yes of course it has a legitimate
claim to control how I am using it. Otherwise, I, the user, get to
decide. If I like the application's setting better than the network's
de
mmediate adoption of DNSSEC and privacy enhancements, even when the
operating system or the local network does not support them. That genie
is not going back in the bottle any time soon.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
ht
t could very
well change day to day. It would be nice if whatever we do does not come
as yet another reason to concentrate all the services on a few big
platforms...
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On 11/20/2018 11:39 PM, Vittorio Bertola wrote:
>> Il 21 novembre 2018 alle 5.44 Christian Huitema ha
>> scritto:
>>
>> Maybe. Over time various entities have developed control techniques that
>> work by limiting which domains are resolved in a particular context
resolved in a particular context, and
how they are resolved. But at the same time, the DNS is a widely
distributed database accessible through thousands of servers. Given this
wide availability, do you really believe that these control techniques
are stable in the
On 9/25/2018 2:30 PM, Mukund Sivaraman wrote:
> Hi Christian
>
> On Tue, Sep 25, 2018 at 01:40:59PM -0700, Christian Huitema wrote:
>> On 9/25/2018 12:15 PM, Tony Finch wrote:
>>
>>> For DNS-over-QUIC I think that could drop to 2RTT, or maybe 1RTT? I d
On 9/26/2018 4:15 AM, Tony Finch wrote:
> Christian Huitema wrote:
>> The basic QUIC handshake will be 1-RTT before sending the first query,
>> with two exceptions:
> Thanks for those details!
>
>> Using 0-RTT is a trade-off between security and performance, b
ther UDP or TCP in all scenarios;
if it is not, QUIC still performs slightly better than TCP or TLS,
because it does not suffer from head of line blocking.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ersaries will have to gain cooperation
of a large number of servers, which may well be located in a variety of
jurisdictions. This could be much harder.
And because of that, I am quite interested in practical ways to encrypt
the traffic from clients to authoritative servers.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
place?
-- Christian Huitema
> On Apr 9, 2018, at 10:25 AM, Allison Mankin <allison.man...@gmail.com> wrote:
>
> Annie, Nick and Paul all plan to be at the Hackathon and the IETF in
> Montreal. This is work I'm also involved in, and we are working on an i-d
> for
Stubby" working.
>
> As I have this setup now, is there an working implementation that is
> missing and should also be in the list?
>
> DNS-over-QUIC?
> DNS-over-HTTP(S)?
You probably need to wait until at least October for realistic
implementations of DNS over QUIC.
--
Chri
yte string, corresponding to the ASCII value "PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n", which the server acknowledges by sending a
"SETTINGS" frame.
So maybe we could build on that, and let application register their
specific 24 bytes string, allowing for demux
ead of queue blocking, and better service than DTCP because it
does not limit the amount of data sent in queries and response. But of
course, the QUIC WG is just getting started, so it will probably take two
years before we can start deployment of something like DNS over QUIC.
-- Chris
DNS servers
are configured by untrusted processes. It would be nice if we had a
blow-by-blow example of how that's supposed to work.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
changes to DNS over DTLS when the DTLS spec
evolves.
-- Christian Huitema
From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of
Tirumaleswar Reddy (tireddy)
Sent: Thursday, August 18, 2016 7:18 AM
To: Bob Harold <rharo...@umich.edu>
Cc: dprive-cha...@tools.ietf.or
The system MUST alert by some
means that the DNS is not private during such bootstrap.
Seems that the case is covered.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
l and cuddly and easy to track. Or
big and robust and a target for hacks and threats. That's better than
nothing in the short term, but we should not stop there.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
data from authoritative resolvers. Or DNS over DTLS. Or a variation
of DNS over HTTPS. But are we standardizing that? Is this part of DPRIVE's
charter?
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/li
https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-
> 03
My bad. Yes, you are right, I somehow missed it when reading the draft.
And I agree with your proposed resolution of the other 2 issues.
-- Christian Huitema
___
dns-privacy mail
bjectives: get
the option code reserved, and make sure that the option can be used without
creating interop issues. We should be happy with that.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/lis
clever by half. But there are so many hypothetical things that such
hypothetical types could do wrong, you don't want to spend time enumerating
each and any of them.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://w
eep it simple. I am also reluctant to mandate
randomness because this can be a very deep rabbit hole, and is not needed if
the local TLS stack does not do compression.
What about SHOULD send zeroes, MAY send random, MUST NOT look at the
received padding?
-- Christian Huitema
_
t should be very clear in a standards track document.
Maybe we should have a unified draft, along the lines of "DTLS and fallback to
TLS."
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ponses. We needed some help to get the
encapsulation right. The draft defines the encapsulation format by a reference
to DNS over TCP, which is probably fine but confused us. Once the actual
encapsulation was explained, everything sailed smoothly.
-- Christian Huitema
_
Resolution latency is very crucial for DNS system and the latency of
DNS-over-DTLS is relatively low compared with DNS-over-TLS.
Do you have measurements showing that, or is it just an opinion?
-- Christian Huitema
___
dns-privacy mailing list
the
connection, drop the STARTTLS, and voila, MITM on 53. If we need a dirty
fallback, then it has to be port 443. The same dirty fallback that other
applications use.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https
the services use shared infrastructure like
CDN or server pools.
Real time passive monitoring enables automated spoofed response, which
are used to instantiate MITM attacks.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https
Also, suppliants are bound under oath to disclose all the prior art that they
know of. Arguably, after reading this thread, they have to forward it to the
patent office.
-Original Message-
From: Stephen Farrell stephen.farr...@cs.tcd.ie
Sent: 10/29/2014 12:48 PM
To: Don Blumenthal
be nice.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
93 matches
Mail list logo
