Hi,
I thinks it’s ok to do Experimental. If the authors care, that might be a
discussion point. My perspective is that there are many worse documents
that are unimplemented but that enjoy “Proposed Standard” status.
thanks,
Rob
On Mon, Jun 5, 2023 at 20:12 Brian Haberman
wrote:
> Tim & I check
On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott wrote:
> Measurement of CPU and memory use between Do53 and DoT or DoQ.
> Measurement of query response rates between Do53 and DoT or DoQ.
> Measurement of server authentication successes and failures.
> Measurement and descriptions of observed at
On Wed, Jun 7, 2023 at 2:05 PM Hollenbeck, Scott
wrote:
>
> On Jun 6, 2023, at 8:42 PM, Rob Sayre wrote
>
> On Tue, Jun 6, 2023 at 11:23 AM Hollenbeck, Scott 40verisign@dmarc.ietf.org> wrote:
>
> Measurement of CPU and memory use between Do53 and DoT or DoQ.
&g
On Fri, Jun 9, 2023 at 3:44 PM Hollenbeck, Scott
wrote:
> *[SAH] The IESG deliberately chartered this working group to “Investigate
> potential solutions for adding confidentiality to DNS exchanges involving
> authoritative servers” in an Experimental manner. As Brian noted, that’s a
> binding ag
On Wed, Jun 28, 2023 at 9:36 AM Hollenbeck, Scott wrote:
> > -Original Message-
> > participants may have other proposed metrics:
> > >
> > > A. Measurement of CPU and memory use between Do53 and DoT or DoQ.
> > > B. Measurement of query response rates between Do53 and DoT or DoQ.
On Sat, Jul 22, 2023 at 3:27 PM Christian Huitema
wrote:
>
> IF we were serious about the "informational only" status, then we would
> [...]
>
Disagree. Non-standards track RFCs can have these requirements. For
example, they may be documents never intended for the standards track (in
that they
On Thu, Sep 7, 2023 at 7:15 PM Paul Hoffman wrote:
> On Sep 7, 2023, at 6:58 PM, Bron Gondwana wrote:
> >> Are you proposing a shorter value for "damping", or a note saying "1
> day is just the suggested value, you might choose a shorter one if you
> want"? Or something else?
> >
> > I'm suggest
On Tue, Sep 12, 2023 at 5:26 PM Daniel Kahn Gillmor
wrote:
>
> Thanks for all this discussion. The main purpose of having any sort of
> damping in the draft is to encourage operators of authoritative servers
> that they will not find themselves in trouble even if they enable
> encrypted transpor
On Thu, Jul 18, 2019 at 10:42 PM Kevin Borgolte wrote:
> The list of websites is attached. It is extracted from the top 1,000 and
> 99,000 to 100,000 of a Tranco list.
>
Thanks for attaching the list. Having seen a fair a number of these, I
think it looks reasonable.
But, I think you should add
On Fri, Jul 19, 2019 at 3:10 AM Kevin Borgolte wrote:
>
> > But, I think you should add the list and the reason for the range choice
> to the paper. For example, I can't tell what range you actually used from
> your description (although that might just be due to a hurried reply).
>
> Section 3.2
> Would the following be a fair summary of the discussion?
> 1) There is some support for the idea it would be useful for APIs to allow
> an application to at least know, and perhaps influence, what DNS security
> features will be used if it makes a DNS request via the operating system.
> 2) The ge
On Tue, Aug 20, 2019 at 8:48 PM Mark Andrews wrote:
> It was defined by the IETF and taken up by POSIX.
>
OK. Can you expand on that? It looks like POSIX claims to define the API.
thanks,
Rob
___
dns-privacy mailing list
dns-privacy@ietf.org
https://w
On Wed, Aug 21, 2019 at 11:22 AM Hollenbeck, Scott wrote:
> > -Original Message-
> >
> > I now read through the whole document,
>
I read the whole thing too, and I am confused about three issues.
1) What is the scale of the entire system? As the document states, the
system makes heavy
On Wed, Aug 28, 2019 at 10:23 AM James Galvin wrote:
> I am not in favor of adoption of this document.
>
> This document asserts that there “operational considerations” and at
> the same time identifies technical deficiencies that suggest there is
> protocol development work that needs to be done
Hello,
Was the source code behind this study published?
It seems like it shouldn't be too much effort. After all, the study is
already published, so the code can't be changed.
thanks,
Rob
On Thu, Jul 18, 2019 at 10:42 PM Kevin Borgolte wrote:
>
> > This paper looks interesting. Is the softwa
On Wed, Sep 11, 2019 at 2:53 AM Timm Boettger
wrote:
> Hi all,
>
> Rob Sayre has pointed me to this thread. I am an author of the linked
> paper..
>
> He has pointed out some confusing and outdated information in the paper,
> that I would like to clarify...
>
Let me fu
Hello,
On https://trac.tools.ietf.org/bof/trac/ , I noticed a BoF for "Application
Behavior Considering DNS (ABCD)".
I noticed that the BoF proponents were listed as "ADD mailing list", while
the form requires 1-3 individuals:
"- BoF proponents: name , name (1-3 people - who are
requesting and
I won't be on the call, but I think one question might be good to add:
"Why are the requirements described in the draft better than
centralization?"
It seems good that resolver traffic patterns are being questioned, but I
had this thought in the back of my mind.
thanks,
Rob
On Mon, Oct 28, 201
On Tue, Oct 29, 2019 at 4:02 PM Eric Rescorla wrote:
> Document: draft-lmo-dprive-phase2-requirements-00.txt
>
> After reviewing this draft, it is not clear to me what architectural
> model people have in mind. At a high level, say that I attempt to
> dereference example.com and I have a cached N
On Wed, Dec 18, 2019 at 6:10 PM Eric Rescorla wrote:
>
>> “It has been pointed out that should the trend towards using large public
>> resolvers increase, an increased centralisation of DNS resolution services
>> will result.
>>
>
> Well, it's been pointed out, but it's not at all clear that it's
Hi,
I found two issues with draft-07. The document mentions unattributed
"concerns" in a few places. That doesn't seem like helpful content, but I
can't say that such "concerns" and rampant use of the passive voice are
uncommon in today's IETF.
Secondly, I found the entire section "3.5.1.5.2. Do
e
> thread relating to the appropriate draft?
>
> Thank you in advance.
>
> Best regards, also on behalf of Sara, Allison and Benno,
>
> Roland
>
> > On 19 Dec 2019, at 21:15, Rob Sayre wrote:
> >
> > I found two issues with draft-07. The document mentions u
Hi, here are comments I mistakenly sent to a thread about another dprive
last call. Summary: the section about "DoH Specific Considerations" is
highly questionable, and seems like advocacy rather than a representation
of IETF consensus.
Hi,
I found two issues with [this draft]. The document
On Sun, Dec 29, 2019 at 5:51 AM Mohit Sethi via Datatracker <
nore...@ietf.org> wrote:
> The document seems focused on TLS 1.2 (and does not talk about TLS 1.3).
>
That seems extremely odd.
TLS 1.2 is RFC 5246, from 2008. https://tools.ietf.org/html/rfc5246
TLS 1.3 is RFC 8446, from 2018. https
On Wed, Dec 18, 2019 at 7:07 AM Sara Dickinson wrote:
>
> Suggest the following text with the goal of getting consensus that the
> opinion exists and is held by many network operators, not that the opinion
> itself has consensus:
>
> OLD:
> “ In some cases, networks might block access to remote r
On Tue, Jan 7, 2020 at 10:35 AM Sara Dickinson wrote:
>
> >
> > Secondly, I found the entire section "3.5.1.5.2. DoH Specific
> Considerations" to be objectionable, and recommend removing it. It mentions
> many concerns that are better covered in RFC 8484 and/or HTTP RFCs, and
> contrasts DoH wi
On Tue, Jan 7, 2020 at 8:15 PM Martin Thomson wrote:
> But it is true that HTTP has grown a number (many) of similar features.
> You could - as this document strong implies - suggest that multitude of
> options makes it a risky proposition to use HTTP because of the surprising
> ways in which lin
On Wed, Jan 8, 2020 at 12:00 AM Christian Huitema
wrote:
>
> On 1/7/2020 12:08 PM, Rob Sayre wrote:
>
>
> The document contains the text:
>
> "DoT, for example, would normally contain no client identifiers above
>the TLS layer and a resolver would s
On Wed, Jan 8, 2020 at 7:11 AM Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:
>
> Il 08/01/2020 14:12 Rob Sayre ha scritto:
>
>
> I think the concept you're describing is covered by RFC8484, as I wrote.
>
> Is there something in this document
On Wed, Jan 8, 2020 at 6:06 PM Martin Thomson wrote:
> On Wed, Jan 8, 2020, at 23:51, Eric Rescorla wrote:
> > On Tue, Jan 7, 2020 at 8:28 PM Rob Sayre wrote:
> > > Couldn't servers give out unique URI templates?
> >
> > DoH doesn't specify how the c
On Thu, Jan 9, 2020 at 10:30 AM Eric Rescorla wrote:
>
> On Thu, Jan 9, 2020 at 10:02 AM Sara Dickinson wrote:
>
>>
>> It means a standards compliant DoT implementation will have no client
>> identifiers, a standards compliant DoH implementation is free to (and
>> likely) to include them.
>>
>
>
On Thu, Jan 16, 2020 at 4:22 AM Sara Dickinson wrote:
> Hi All,
>
> So the -04 update attempts to address as many of the comments as possible
> that arose during IETF LC along the lines Eric suggested.
>
Éric also suggested that another last call would be issued if the edits
were substantial. Is
Hi,
Here are my last-call comments on draft-ietf-dprive-rfc7626-bis.
#
# 1. Introduction
#
> It is one of the most important infrastructure components of the Internet
> and often ignored or misunderstood by Internet users (and even by many
> professionals).
This text is carried over from RFC
On Fri, Jan 24, 2020 at 6:43 AM Sara Dickinson wrote:
>
>
> On 22 Jan 2020, at 09:39, Rob Sayre wrote:
>
> Hi,
>
> Here are my last-call comments on draft-ietf-dprive-rfc7626-bis.
>
>
> Thank you for your detailed 45 point review of this document during the
> se
Hi,
While I don't want to obstruct progress on this draft, I do intend to write
a draft that addresses my points and aims to obsolete rfc7626-bis.
This topic can be contentious, so I don't have an eventual RFC as a goal
(but that would be ok).
thanks,
Rob
On Mon, Feb 3, 2020 at 11:44 PM Eric V
On Wed, Feb 5, 2020 at 9:04 PM Adam Roach via Datatracker
wrote:
> §5.1.4:
>
> > DNS Privacy Threats:
> >
> > o Users may be directed to bogus IP addresses for e.g. websites
> > where they might reveal personal information to attackers.
>
> You might want to consider a different example th
On Thu, Feb 6, 2020 at 12:09 PM Eric Rescorla wrote:
>
> Second, the text in question is about the effect of attacks on DNS on the
> Web "Users may be directed to bogus IP addresses for e.g. websites where
> they might reveal personal information to attackers."
>
I agree that the WebPKI can help
On Thu, Feb 6, 2020 at 5:14 PM Benjamin Kaduk wrote:
>
> TLS also punts the key-management story to be out of scope.
> We have a lot of worked examples of the Web PKI failing (and also have lots
> of people working really hard to get it to improve, which I greatly
> appreciate), but given that th
On Thu, Feb 6, 2020 at 9:39 PM Eric Rescorla wrote:
>
> The question at hand is not about whether it ought to recommend DNSSEC
> validation but rather whether the text around that, which implies that
> failure to do so has a high risk of sending your sensitive *web* traffic to
> the attacker, is
Hi,
Maybe DNSSEC should not appear in a consensus document until it is shown to
work. Here are some opinions about it that are negative:
https://twitter.com/colmmacc/status/979234954440617990
https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-intern
On Mon, Feb 10, 2020 at 3:33 PM Jeremy Harris wrote:
> On 10/02/2020 19:56, Eric Rescorla wrote:
> >
> >
> https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/
>
> How does this compare to OCSP stapling.
>
That is in the post and the linked paper.
Also, pleas
Thanks for the feedback.
thanks,
Rob
On Tue, Feb 11, 2020 at 1:37 AM Jeremy Harris wrote:
> On 10/02/2020 23:49, Rob Sayre wrote:
> > I've seen a few posts like this lately,
>
> Perhaps that should tell you something about how others feel.
>
On Thu, Mar 19, 2020 at 3:53 PM Christian Huitema
wrote:
> On 3/6/2020 7:30 AM, Paul Hoffman wrote:
>
> > Thank you for continuing this interesting work. However, a reader might
> not realize that many other folks would prefer DNS/HTTPS/QUIC until the get
> all the way to Section 3.4. Also, the t
On Fri, Mar 20, 2020 at 1:15 AM Ralf Weber wrote:
> Moin!
>
> On 20 Mar 2020, at 8:51, Christian Huitema wrote:
> > 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.
On Sun, Mar 22, 2020 at 2:46 AM Ralf Weber wrote:
> Moin!
>
> On 20 Mar 2020, at 19:39, Rob Sayre wrote:
> > Yes, at which point one can switch to user space networking if really
> > necessary.
> Which has been done for DNS, but usually with special cards that did
>
I oppose adoption of this document.
I don't see any advantage over DoH, as that standard will accrue QUIC
benefits as HTTP stacks shift to HTTP/3.
Maybe it's possible to block a port and use QUIC with this draft? That
might be useful, but perhaps needs a little more running code.
thanks,
Rob
O
On Tue, Apr 14, 2020 at 2:47 AM Stephen Farrell
wrote:
>
> I support adoption.
>
> I think someone bemoaned the possibility of another surplus
> DNS transport option, but I don't think the existence of
> RFC 8094 has caused any harm, so I consider that argument
> weak, in this case.
>
It doesn't
On Wed, May 13, 2020 at 4:58 PM Christian Huitema
wrote:
>
> On 5/13/2020 3:19 PM, Andrew Campling wrote:
>
> I also note that RFC 3552 (Guidelines for Writing RFC Text on Security
> Considerations) includes section 2.3 on systems security so does indeed
> look beyond the network. So, alongside
On Wed, May 13, 2020 at 12:03 PM Eric Vyncke (evyncke) wrote:
> Dear dprive WG members,
>
> As you have noticed, there are a lot of messages and discussions about
> this specific draft revision issued after the 2nd (!) IETF-wide Last Call.
> Discussions are always good (and I really appreciate th
On Fri, Aug 7, 2020 at 6:18 PM Puneet Sood wrote:
> I think this is worth doing.
>
I agree. The part that I worry about is the computational cost of
reestablishing links after an outage. Is there a way to model this?
(Perhaps this work has already been done)
thanks,
Rob
On Fri, Aug 7, 2020 at 6:28 PM Puneet Sood wrote:
> On Fri, Aug 7, 2020 at 9:22 PM Rob Sayre wrote:
> >
> > On Fri, Aug 7, 2020 at 6:18 PM Puneet Sood 40google@dmarc.ietf.org> wrote:
> >>
> >> I think this is worth doing.
> >
> >
On Fri, Aug 7, 2020 at 7:04 PM John Levine wrote:
> In article <
> cachr6swgjo889gkmk0ae-76ntsrp799jmm8rbqadrko+xvw...@mail.gmail.com> you
> write:
> >Assuming this traffic is encrypted, which I am in favor of, the CPU load
> on
> >the authoritative server will increase after an outage or network
On Thu, Sep 10, 2020 at 10:40 PM Konda, Tirumaleswar Reddy <
tirumaleswarreddy_ko...@mcafee.com> wrote:
>
>
> Yes lots of ISP-provided CPEs do caching. There is a draft in the ADD WG
> that describes this for at least 3 large ISPs in Europe.
>
>
>
> There are other reasons for wanting to do DoH in
Paul Hoffman wrote:
> Greetings again. A document on which I am a co-author refers to
> draft-ietf-dprive-rfc7626-bis. As I was updating references in that
> draft, I thought that maybe draft-ietf-dprive-rfc7626-bis was done.
> However, according to
https://datatracker.ietf.org/doc/draft-ietf-dpr
On Wed, Sep 23, 2020 at 5:20 AM Brian Haberman
wrote:
> >
> > Other recent submissions have changed their references to RFC 7626. What
> > changes in the 7626-bis document are important to you?
> >
>
> The changes made to the BCP document were driven by feedback from IESG
> members who rightly po
t; Il 21/09/2020 08:20 Rob Sayre ha scritto:
>
>
> Paul Hoffman wrote:
>
> > Greetings again. A document on which I am a co-author refers to
> > draft-ietf-dprive-rfc7626-bis. As I was updating references in that
> > draft, I thought that maybe draft-ietf-dprive-r
While it might be too late to debate this point, I would say the paragraph
that begins with "Users will only be aware of..." and the following
bullet points could be dropped. It seems to state that users can't change
settings if there are no settings three times (this seems obvious). One
bullet poi
On Tue, Oct 6, 2020 at 9:16 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> This text is essentially unchanged since RFC 7626; did we do much of a
> search for whether the past five years have brought about changes in the
> legal landscape?
>
Why would we do such a search?
thanks,
On Tue, Oct 6, 2020 at 10:23 PM Benjamin Kaduk wrote:
> Perhaps "search" was not the best word to use
>
I think that is correct. Maybe the document should include a summary of the
changes relative to RFC 7626. Let me apologize in advance if there is one,
and I've missed it.
thanks,
Rob
On Mon, Oct 5, 2020 at 2:42 PM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:
>
> My DISCUS is specifically around the"The Alleged Public Nature of DNS
> Data" /
> "It has long been claimed that "the data in the DNS is public" section --
> it
> seems to be unnecessarily creating and then
On Wed, Oct 7, 2020 at 5:17 PM Warren Kumari wrote:
>
> The document is in IESG eval -- there is no more "eventually".
>
It can always be obsoleted. This one probably will be.
thanks,
Rob
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.i
On Wed, Oct 7, 2020 at 9:16 PM Barry Leiba via Datatracker
wrote:
>
> On Alissa’s first point — why publish this update now, rather than waiting
> until more things shake out and settle down — I basically agree, though I’m
> torn between thinking that waiting is better... and, on the other hand,
On Tue, Jan 26, 2021 at 4:23 PM Paul Hoffman wrote:
> > In reading through the draft that there’s going to be unacceptable
> induced latency on resolver for TLDs and authoritative domains that are
> (would) not ADoT enabled.
>
> If a resolver decides that the increased latency is unacceptable, th
On Mon, Mar 1, 2021 at 5:51 PM Eric Rescorla wrote:
>
> On Mon, Mar 1, 2021 at 8:32 AM Paul Wouters wrote:
>
>> DNS is not the web. DNSSEC already "pins" via the DS record in a
>> hierarchical way with DNSKEYs. Adding another public key here is
>> not that different.
>>
>
> Given the low rate of
On Wed, Mar 17, 2021 at 6:46 AM Eric Rescorla wrote:
> I believe this document should be adopted with a target status of
> Experimental
>
Fully agree.
thanks,
Rob
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/
On Thu, Mar 18, 2021 at 6:04 PM Stephen Farrell
wrote:
>
> Publishing this via the ISE and running experiments, then
> bringing those results to the WG may be a good way to
> proceed
>
This approach sounds good as well, but I don't think it will make a
practical difference. It looks like this fe
On Fri, Mar 19, 2021 at 12:32 PM Wes Hardaker wrote:
>
> It seems silly to me to write up a document that is decoupled from the
> parallel O-HTTP work when it would be better off depending on the
> results of that work.
>
It seems like the authors of ODoH and O-HTTP could resolve this
discrepanc
On Tue, Mar 23, 2021 at 2:30 PM Paul Hoffman wrote:
> On Mar 23, 2021, at 2:16 PM, Ben Schwartz wrote:
> > In my view, if ...
>
> Proposal: we don't pretend to be contract lawyers here.
>
Heavy +1. It's always easy to fall into this mode, and it's a known IETF
antipattern.
thanks,
Rob
On Tue, Mar 23, 2021 at 3:49 PM Jim Reid wrote:
>
> This is all somewhat moot because I very much doubt any busy TLD will ever
> turn on DoT or DoH on their authoritative name servers.
>
That isn't clear to me. Is there a good measurement on traffic to these?
Last time I tried to look, the query
On Fri, Mar 26, 2021 at 7:02 PM Stephen Farrell
wrote:
>
> Hiya,
>
> Not asking anyone in particular but...
>
> On 27/03/2021 00:24, Eric Rescorla wrote:
> > WRT the operational risk (slide 3), it's likely true that it's
> > somewhat harder to run a DoX server than a Do53 server. However,
> > giv
On Tue, Mar 30, 2021 at 7:49 AM Hollenbeck, Scott wrote:
> This is worth reading:
>
> https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf
I am not sure I agree it is worth reading.
Why can't "The Root Server Operators" run QUIC etc as well as their
existing UDP methods?
thanks
On Tue, Mar 30, 2021 at 5:08 PM Erik Kline wrote:
> From my reading the answer, and the whole document, seems to be
> summarizable in this one excerpt:
>
> "Root Server Operators do not feel comfortable being the early
> adopters of authoritative DNS encryption and would like to first see
> i
On Tue, Mar 30, 2021 at 6:36 PM Stephen Farrell
wrote:
>
> Also fair. Requiring the parent to be involved is a big deal
> for any of the offered solutions here (regardless of whether
> or not DNSSEC is involved).
>
I don't think anyone expects any high-traffic piece of DNS infrastructure
to just
On Wed, Mar 31, 2021 at 2:13 AM Stephane Bortzmeyer
wrote:
> On Tue, Mar 30, 2021 at 05:00:29PM -0700,
> Rob Sayre wrote
> a message of 56 lines which said:
>
> > Why can't "The Root Server Operators" run QUIC etc as well as their
> > existing UDP meth
On Wed, Mar 31, 2021 at 1:29 PM Bill Woodcock wrote:
>
>
> > On Mar 31, 2021, at 9:55 PM, Rob Sayre wrote:
> > I still don't understand the resistance here. Some data on what the
> impact would be still seems like the most helpful thing to move the
> conversat
On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock wrote:
>
> …and it’s measuring latency rather than server-side load. I just checked
> with our engineers, and it sounds like the server load per-query is more
> like 3x-5x higher for the encrypted queries.
>
Plenty of folks have evaluated the costs
On Wed, Mar 31, 2021 at 2:34 PM Bill Woodcock wrote:
> So you’re saying that we all need to go spend some non-negative number,
> which, for us, is 3x-5x as much, in order that third parties should not
> know the relative volume of recursor cache-misses with respect to different
> TLDs?
>
> Why is
On Wed, Mar 31, 2021 at 2:44 PM Bill Woodcock wrote:
> > On Mar 31, 2021, at 11:39 PM, Rob Sayre wrote:
> >
> > I think it's fine if you don't want to implement any given IETF RFC.
>
> Then those RFCs should be worded carefully so that they don’t suggest tha
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 have seen (and done)
> demos of supporting 50,000 QUIC connections over a single UDP socket, which
> is de
On Thu, May 6, 2021 at 4:58 AM Sara Dickinson wrote:
> >
> > (3) It wasn't clear to me whether the text in the appendix is meant to be
> > normative or illustrative. It might be helpful to be clear which it is
> meant
> > to be.
>
> A good point - it is meant to be illustrative - I’ll add text
On Wed, May 12, 2021 at 5:16 AM Sara Dickinson wrote:
>
>
> On 5 May 2021, at 05:44, Benjamin Kaduk via Datatracker
> wrote:
>
>
> Because this topic relates to TLS usage, I have started an email thread
> with the TLS WG for it:
> https://mailarchive.ietf.org/arch/msg/tls/ZIPo1mF_wnOXkgS7Uv_wzIB
On Fri, Jan 21, 2022 at 1:15 PM Deen, Glenn wrote:
>
>1. Draft Agenda:
>
> https://datatracker.ietf.org/meeting/interim-2022-add-01/materials/agenda-interim-2022-add-01-add-01-04
>
>
Hi Glenn,
The agenda says:
- "DNSSEC is generally not used for the non-global names in Do53 Split DNS
en
clever people out there who like to some pretty
> wild hacks, hence the “generally not used”.
>
>
>
> -glenn
>
>
>
> On 1/21/22, 1:33 PM, "Rob Sayre" wrote:
>
>
>
> On Fri, Jan 21, 2022 at 1:15 PM Deen, Glenn 40comcast@dmarc.ietf.org> w
Hi, pardon the topquote.
I think you can find the answers you're looking for here:
https://www.rfc-editor.org/rfc/rfc9325
I believe this consensus is generally that TLS 1.3 is easier to configure
securely, but you can still get good security properties out of TLS 1.2 if
configured correctly (and
On Tue, Jul 8, 2025 at 3:17 PM Bill Woodcock wrote:
>
>
> > On Jul 9, 2025, at 00:13, Ben Schwartz
> wrote:
> >> On Jul 8, 2025, at 5:39 PM, Peter Thomassen 40desec...@dmarc.ietf.org> wrote:
> >> It may be more difficult to directly compare reachability of port 853
> from other vantage points,
85 matches
Mail list logo
