On Thu, Aug 06, 2020 at 11:04:39PM -0400, Paul Wouters wrote:
> > Opportunistic encryption is defined in RFC 7535.
Minor correction, for the record, 7435.
> The "opportunistic" part really means, "we will try encryption, but if
> for whatever reason it does not work, we will fallback to
>
Paul Wouters wrote:
>
> At the IETF, we have done a REALLY bad job at keeping secure DNS as an
> optional feature. The more we treat it that way, the more others will
> treat it that way. We should really do the opposite. DNS without DNSSEC
> is legacy. It's irresponsible. It's vulnerable. It's
On Fri, 2020-08-07 at 19:12 -0700, Rob Sayre wrote:
> The issue is that connection establishment will be expensive, which is
> something separate from getting a bunch of queries. As others have pointed
> out, this cost will be amortized to almost nothing most of the time. After an
> outage,
On Thu, 2020-08-06 at 23:04 -0400, Paul Wouters wrote:
>
> In the case of encrypted DNS to authoritative servers, those servers
> obviously can have an cryptographic ID based on FQDN.
This is not obvious. It would be great if it was; but it isn't.
Kind regards,
--
Peter van Dijk
PowerDNS.COM
> On Aug 8, 2020, at 11:57 AM, Brian Haberman wrote:
>
> Does anyone have numbers on how many authoritative servers use anycast
> for load balancing?
I don’t have data (and haven’t looked into it recently), but I think it’s a
very safe assumption that
- most of the authoritative servers
Does anyone have numbers on how many authoritative servers use anycast
for load balancing?
Brian
On 8/6/20 10:59 AM, Paul Hoffman wrote:
> Greetings again. The following is a short text-based version of my slides
> from last week's WG meeting. I'd like to find out if this is one of the use
>
On Thu, 6 Aug 2020, Ben Schwartz wrote:
I think opportunistic or unauthenticated encryption is worth pursuing.
In general, yes. but ...
On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman wrote:
Use case: Opportunistic encryption for recursive to
authoritative
In this use
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
In article
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 problem.
>
>Is this already factored in?
How is that diffferent from now? If a DNS server is offline and comes
back online, it
Yes. I think it is worth doing.
Manu
On Thu, Aug 6, 2020 at 7:59 AM Paul Hoffman wrote:
> Greetings again. The following is a short text-based version of my slides
> from last week's WG meeting. I'd like to find out if this is one of the use
> cases that the WG would be interested in dealing
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.
> >
> >
> > I agree. The part that I worry about is the
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
I think this is worth doing.
-Puneet
On Thu, Aug 6, 2020 at 10:59 AM Paul Hoffman wrote:
>
> Greetings again. The following is a short text-based version of my slides
> from last week's WG meeting. I'd like to find out if this is one of the use
> cases that the WG would be interested in
(speaking not as a chair)
I think this is worth doing.
tim
On Thu, Aug 6, 2020 at 3:45 PM John R. Levine wrote:
> Yes, this is worth doing. Agree with comments that it has to be
> compatible with non-opportunistic encryption.
>
> R's,
> John
>
> PS: RFC 7435.
>
> > Greetings again. The
Yes, this is worth doing. Agree with comments that it has to be
compatible with non-opportunistic encryption.
R's,
John
PS: RFC 7435.
Greetings again. The following is a short text-based version of my slides from
last week's WG meeting. I'd like to find out if this is one of the use cases
I think opportunistic or unauthenticated encryption is worth pursuing.
However, your quote also says "use authentication when possible", and I
agree. I would like to avoid selecting an opportunistic encryption design
that doesn't match well with our authenticated encryption design, so I
think
Greetings again. The following is a short text-based version of my slides from
last week's WG meeting. I'd like to find out if this is one of the use cases
that the WG would be interested in dealing with.
Use case: Opportunistic encryption for recursive to authoritative
In this use case, a
17 matches
Mail list logo
