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:
e offending node 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 add
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 Francesca's
ly enable the service for a fraction of their clients, maybe
using some kind 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
ycles but
protects the client against spoofs.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
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
or DoQ, padding mechanisms 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
impl
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
hetical side effect. So, if really care about hiding
requests, then maybe we should consider an onion network of DNS resolvers,
of course connected by ecrypted links. Or maybe use DNS over HTTPS over Tor.
-- Christian Huitema
___
dns-privacy mailing li
te renewal.
But, yes, solving the "secure provisioning" issue would be nice.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
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"
Sent: 10/29/2014 12:48 PM
To: "Don Blumenthal" ; "Rubens Kuhl" ;
"Flo
s when 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-pr
of the server."
What kind of privacy would we gain?
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
you wrote, "at the extreme, any client connecting to 8.8.8.8 is doing DNS..."
And I would rather not assume that the data comes from the DNS as in (2),
before seeing actual designs...
-- Christian Huitema
___
dns-privacy mailing list
On Friday, April 17, 2015, at 11:48 AM, Warren Kumari wrote:
> A reminder that this is underway -- we'd like lots of responses, so
> don't be shy...
I support adoption of draft-hzhwm-dprive-start-tls-for-dns.
-- Christian Huitema
___
fic to "pin" the port mappings, something that is not needed
nearly as much with TCP.
Bottom line, DNS/DTLS/UDP does not have much of an advantage over DNS/TLS/TCP.
It looks more like gratuitous complexity.
-- Christian Huitema
___
dns-privacy
ver time.
I assume that the client could learn a "temporary key" that is understood by
all servers in the pool, and use that to encrypt the messages. But then that
requires a fair bit of coordination between the servers in the anycast pool.
-- Christian Huitema
__
;s true, then we should just pick UDP/TLS/TCP
and be done with it.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
are that it will also mess with port 53. NAT 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
___
> 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 mailin
ding will be available at best with TLS 1.3, so we may have to wait some
time. And then, there is the general argument that when the application can do
padding, this is more efficient than a generic TLS solution. So, yes, that
draft is useful.
-- Christian Huitema
_
sponses. 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
rement 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
s futile. Let's keep 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
with lazy developers. But then, if they are really
lazy, they will just call memzero and meet the requirement. Knowing that other
developers may legitimately send something else than zero will also give teeth
to the "must ignore" requirement.
-- Christian Huitema
_
o
are too 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@iet
its objectives: 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/mailma
e this kind of deployment considerations for the DTLS
draft, and moves them to a common document for TLS and DTLS.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
ed in
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
, there is the question of how often clients should
be updated, regardless of the age of the pins. But since it is pretty obvious
that key-pinning could also be used by DNS-over-DTLS, the fine details on how
to manage pinning and provision clients probably belong in a common document,
and th
e for work" domains. Encrypted
connections to a DNS server could traverse these firewalls, and bypass these
policy controls. The issue is documented in CERT Alert (TA15-240A),
"Controlling Outbound DNS Access,"
https://www.us-cert.gov/ncas/alerts/TA15-240A. We should address it.
o get 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/
ll 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
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
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
Cc: dprive-cha...@tools.ietf.org; dns-privacy@ietf.org
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
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
TCP when the message exceeds a
certain size, and that's a big advantage over DTLS.
-- Christian Huitema
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
FYI: Just published this draft describing transport of DNS over a
dedicated QUIC connection.
-- Christian Huitema
Forwarded Message
Subject:New Version Notification for draft-huitema-quic-dnsoquic-00.txt
Date: Mon, 10 Apr 2017 09:45:37 -0700
From: internet-dra
on would be to instruct the transport to perform a
particular padding strategy, similar to the padding strategies developed
for DNS. This would cover many applications, not just DNS. Failing that,
padding at the DNS layer has the advantage of being easy to implement.
-- Christian Huitema
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
ation messages are interleaved, traffic analysis
becomes significantly harder. That the approach proposed in
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-existing-http2/,
or in
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/.
We are really seeing many flowers
tubby" 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.
--
first place?
-- Christian Huitema
> On Apr 9, 2018, at 10:25 AM, Allison Mankin 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 DPRIVE, to come soon.
>
>
On 4/9/2018 11:00 AM, Warren Kumari wrote:
> On Mon, Apr 9, 2018 at 1:53 PM Christian Huitema <mailto:huit...@huitema.net>> wrote:
>
> At first sight, it seems that this moves the logging hole from the
> DNS recursive to the ODNS recursive, and that's a meh
nt approach, the adversaries 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
better than either 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
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, beca
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 don't
>
ch domains are 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
ar
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
s on a given day, and that 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
r space allows for
immediate 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
f those, 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 t
many cases in which 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 been called 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
des public accommodation.
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
___
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
trolled by 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
___
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
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
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
>
s being resumed, 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 sess
with the "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
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
ty of ADOT did not depend 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
gree should be 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 Huitem
ause 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
plan to use 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
ut client 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
back end of 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
r than the 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
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
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.
p 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
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
+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 Ales
tion 6.1.1.2, I would scratch most 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
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
domains. 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
DP/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
r and an authoritative server can be 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
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 I
cause 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:
>
f 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
ic.fr [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
__
but rather 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
> 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 h
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
handshakes 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-
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
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 that
, 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.
-- Christi
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
ppose 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
irements for DoQ 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
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 GitHu
he 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
"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
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
1 - 100 of 111 matches
Mail list logo
