Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[David Conrad]

Joe,

On Sep 19, 2023, at 2:45 PM, Joe Abley  wrote:
>>> Domain names existed before the DNS
>> Well, hostnames did.  Not sure domain names did, at least using that term.
> All hostnames are domain names, right?

Well yes, in the sense that domain names were a scalability extension of 
hostnames. However, in reviewing the ancient tomes (specifically, 
https://datatracker.ietf.org/doc/html/rfc805), I was wrong: it looks like 
domain names did, in fact, precede the specification/implementation of the DNS 
protocol, at least in concept. Mea culpa.

>>> I am not convinced that the term "domain name space" has any real currency,
>> Not sure what you mean by this.
> The word "namespace" is used in a general sense all the time. The phrase 
> "domain name" is used all the time. I don't remember hearing anybody use the 
> phrase "domain name space" ever, never mind recently, so I wonder whether it 
> is a term that is really in common usage. That's what I meant by "has real 
> currency".

Googling ‘domain “name space”’ resulted in 318,000 results, ‘domain namespace’ 
resulted in 33,100,000. YMMV.

>>> or that there's a useful distinction between that and "domain names”.
>> The distinction is that names resolvable via the DNS is a subset of all 
>> possible names within the domain namespace.
> I can see how it could mean that, it we decided to define it to mean 
> something.

My (likely faulty) recollection was that the term “domain namespace” was used 
during the discussions of SUDNs, i.e., SUDNs were names within the domain 
namespace that were NOT resolvable via the DNS protocol.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Joe Abley]

Op 19 sep 2023 om 18:24 heeft David Conrad  het volgende 
geschreven:

> Joe,

Hello!

>> Domain names existed before the DNS
> 
> Well, hostnames did.  Not sure domain names did, at least using that term.

All hostnames are domain names, right?

>> I am not convinced that the term "domain name space" has any real currency,
> 
> Not sure what you mean by this.

The word "namespace" is used in a general sense all the time. The phrase 
"domain name" is used all the time. I don't remember hearing anybody use the 
phrase "domain name space" ever, never mind recently, so I wonder whether it is 
a term that is really in common usage. That's what I meant by "has real 
currency".

>> or that there's a useful distinction between that and "domain names”.
> 
> The distinction is that names resolvable via the DNS is a subset of all 
> possible names within the domain namespace.

I can see how it could mean that, it we decided to define it to mean something. 


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Paul Wouters' Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 6, 2023, at 8:56 PM, Paul Wouters via Datatracker  
> wrote:
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for this document and my apologies for being involved/related to two
> of the five outages you described :-)

Ha! :-)

> 
> 
>Consistent with [RFC2308], resolution failures MUST NOT be cached
>for longer than 5 minutes.
> 
> If an expired RRSIG has a TTL of 3600, what should happen? The resolution
> failed because the signature is no longer valid but the individual
> components of this validation failure are all successful lookups of RRs that
> are now in the cache.  Wouldn't this result in a resolution failure of
> 3600? How would an implementation limit this to 5 minutes? By deleting
> the RRSIG from its cache within 5 minutes, overriding its TTL?
> 
> If so, is there value stating this in the document?

Section 4.7 of RFC 4035 talks about the “BAD cache” where an implementation can
cache data with invalid signatures.  It says:

   o Since RRsets that fail to validate do not have trustworthy TTLs,
 the implementation MUST assign a TTL. This TTL SHOULD be small,
 in order to mitigate the effect of caching the results of an
 attack.

I would expect an implementation to treat an expired signature the same
as described here, and not cache it for the full 3600 seconds in your
example, but rather the TTLs we talk about in this draft, from 1-300 seconds
(ideally with backoff).

> 
> 
>also known as 'lame'
> 
> I thought the WG agreed the definition of 'lame' was not agreed upon and
> the term is no longer being favoured for use. Why not just remove this part?

In this text where lame appears we are simply quoting RFC 4697.  Given the
can of worms that was the lame delegation discussion, we are somewhat
reluctant to write more about it in this document.  Although we could make
a reference to the new terminology document if you think that would be helpful.


> 
>To prevent such unnecessary DNS traffic, security-aware resolvers
>MUST cache DNSSEC validation failures, with some restrictions.
> 
> What are these "some restrictions" ?
> 

Here our intention is to update this statement from RFC 4035 so that MAY
becomes MUST and "invalid signatures" becomes "validation failures while
leaving the "some restrictions" in place.  AFAICT the restrictions that 4035
talks about are using short TTLs (as above) and (I think) to have some
query threshold for caching validation failures.  i.e., retry before
caching.

DW




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping

[Tim Wicinski]

This starts a Working Group Last Call for
draft-ietf-dnsop-dnssec-bootstrapping

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/


The Current Intended Status of this document is: Standards Track

This Document will update  7344 and 8078 if approved.

The Document updates brings up something I wanted to raise.
Peter and I chatted about some simple nits (remove references from the
abstract),
but I wasn't sure if the sections updating older documents was formal
enough.
DNSOP has produced a few documents recently that update previous work
(8767, 8020 and 9077 come to mind), and we are advice on that.
(I may very well be overthinking this, which is what I told Peter)


Please review the draft and offer relevant comments.
If this does not seem appropriate please speak out.
If someone feels the document is *not* ready for publication, please speak
out with your reasons.

This starts a two week Working Group Last Call process, and ends on:
October 3, 2023


thanks
tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 7, 2023, at 4:08 AM, Éric Vyncke via Datatracker  
> wrote:
> 
> 
> 
> --
> COMMENT:
> --
> 
> 
> # Éric Vyncke, INT AD, comments for
> draft-ietf-dnsop-caching-resolution-failures-07
> 
> […]
> 
> # COMMENTS
> 
> ## Abstract
> 
> `RFC 2308 specifies requirements for DNS negative caching` should this
> statement only apply to (2) responses and not (1) responses (as this would be
> positive caching) ?

Yes indeed!  Glad you caught that.

> 
> ## Section 2.2 (and other places)
> 
> Is there a reason why EXAMPLE.COM is in uppercase in the text ? This is really
> unusual.

Fixed.

> 
> Please follow RFC 5952 and write IPv6 address is lower case (BTW thanks for
> using modern addressing)
> 

Fixed.  (Erik Kline beat you to it)

DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Zaheduzzaman Sarker's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 7, 2023, at 2:32 AM, Zaheduzzaman Sarker via Datatracker 
>  wrote:
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for working on this specification. My review does yield any TSV related
> issues.
> 
> I have following minor comments that I believe will improve the document
> quality when addressed -
> 
>  # While this specification updates RFC2308, RFC4038 and RFC4697, the
>  Introduction section only mentions RFC2308. Would be good to give emphasis on
>  all the updates.

Good catch, this has been updated.

> 
>  # Regarding Motivation section, I like the motivation section up front and
>  understanding of the problem to solve before going into solution description.
>  So I would like to keep this section where it is.

Thank you.

> 
>  # Section 2 says -
> 
>If any one of the available servers provides a useful response, then it
>is not considered a resolution failure.
> 
>with that I am not sure why responses in section 2.1 and 2.2 are qualified
>as useful responses. Please add some clarification texts in those sections.


The types of responses described in 2.1 (SERVFAIL) and 2.2 (REFUSED) should not 
be
considered “useful”.  Rather they are NOT useful because they neither provide 
the
requested data, a referral, nor indicate that the requested data does not exist.

Since the meaning of useful might not be as clear as it could be, we would 
propose to
add this to the opening paragraph of section 2:

A response is considered
useful when it provides either the requested data, a delegation a 
descendant zone,
or an indication that no data exists at the given name.

Does that clear up the confusion?

DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation

[Tim Wicinski]

(forgive my missing subject previously)


All

After pulling this back (Thanks Peter again), we went back to the authors
and

In the case of the DF bit, the wording is changed from
"UDP responders are RECOMMENDED"  to "UDP responders MAY"

They also added some additional text in the security section.

The authors relabeled the suggestions using "R1" -> "R12", which
actually was better than my idea.

The diffs can be found here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-avoid-fragmentation-14=draft-ietf-dnsop-avoid-fragmentation-15=--html


This will be a one week working group followup last call.
We want to make sure the implementers etc are happy with these changes.

This Working Group Last Call will end on September 20, 2023

thanks

tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] (no subject)

[Tim Wicinski]

Followup One Week Working Group Last Call for
draft-ietf-dnsop-avoid-fragmentation

All

After pulling this back (Thanks Peter again), we went back to the authors
and

In the case of the DF bit, the wording is changed from
"UDP responders are RECOMMENDED"  to "UDP responders MAY"

They also added some additional text in the security section.

The authors relabeled the suggestions using "R1" -> "R12", which
actually was better than my idea.

The diffs can be found here:

https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-avoid-fragmentation-14=draft-ietf-dnsop-avoid-fragmentation-15=--html


This will be a one week working group followup last call.
We want to make sure the implementers etc are happy with these changes.

This Working Group Last Call will end on September 20, 2023

thanks

tim
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Shumon Huque]

On Tue, Sep 19, 2023 at 11:33 AM Joe Abley  wrote:

> (I have trimmed the cc list a bit to avoid bothering the other 20,000
> people who would otherwise also receive this.)
>
> Op 19 sep 2023 om 17:19 heeft Shumon Huque  het
> volgende geschreven:
>
> > I think we need to clearly separate the definition of a domain name with
> > the 'domain name space'. A domain name is just a sequence of labels,
> > and is a concept that exists independent of the tree structured namespace
> > of the global DNS (or any private DNS namespace for that matter).
>
> Domain names existed before the DNS and are also used by other name
> resolution protocols than the DNS.
>

> I am not convinced that the term "domain name space" has any real
> currency, or that there's a useful distinction between that and "domain
> names".
>

If "domain name space" means the universe of all possible domain names,
then perhaps. My definition of "domain name space" is the name space of all
existing domain names, so there is a significant difference there. These
terms are not rigorously defined for the most part, so are sadly subject to
interpretation.

A query for a domain name that elicits NXDOMAIN means that the domain name
did not exist in the relevant domain name space. But the queried name
nevertheless still was a domain name.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Murray Kucherawy's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 6, 2023, at 11:46 PM, Murray Kucherawy via Datatracker 
>  wrote:
> 
> 
> --
> COMMENT:
> --
> 
> Thanks to Barry Leiba for his ARTART review.
> 
> I think the SHOULD in Section 3.2, paragraph 2, is not appropriate use of
> SHOULD as it doesn't address interoperability or operations or security
> recommendations.  A regular "should" is fine.

Thanks for the suggestion.  We’ve made that change.


DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Robert Wilton's Yes on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)

[Wessels, Duane]

> On Sep 5, 2023, at 3:52 AM, Robert Wilton via Datatracker  
> wrote:
> 
> --
> COMMENT:
> --
> 
> Hi,
> 
> Thanks for working on this document - I'm not a DNS expert but it looks like 
> good advice.
> 
> A couple of minor comments for your consideration:
> 
> (1) p 2, sec 1.  Introduction
> 
>   This document updates [RFC2308] to require negative caching of DNS
>   resolution failures and provides additional examples of resolution
>   failures.
> 
> Perhaps "caching of all DNS resolution failures"?

Agreed.

> 
> 
> (2) p 2, sec 1.1.  Motivation
> 
>   RFC Editor: We'd like your thoughts on moving the Motivation and
>   Related Work sections to appendices.  Is that a preferred style?
> 
> Not the RFC editor, but I would keep the motivation here, as a subsection of 
> the introduction.

Excellent, thanks for the feedback.

DW

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[David Conrad]

Joe,

On Sep 19, 2023, at 8:32 AM, Joe Abley  wrote:
>> I think we need to clearly separate the definition of a domain name with
>> the 'domain name space'. A domain name is just a sequence of labels,
>> and is a concept that exists independent of the tree structured namespace
>> of the global DNS (or any private DNS namespace for that matter).
> 
> Domain names existed before the DNS

Well, hostnames did.  Not sure domain names did, at least using that term.

> and are also used by other name resolution protocols than the DNS.

Yes.

> I am not convinced that the term "domain name space" has any real currency,

Not sure what you mean by this.

> or that there's a useful distinction between that and "domain names”.

The distinction is that names resolvable via the DNS is a subset of all 
possible names within the domain namespace.

> Some domain names are resolvable using the DNS protocol. Others are not. I'm 
> not sure it needs to be more complicated than that.

I agree that there’s no need to make it overly complicated, but it seems clear 
(e.g., the existence of the SUDN registry) that the distinction is both useful 
and necessary.

> I agree that a definition of a domain name as an ordered sequence of labels 
> is probably better than references to graph theory, which I think most people 
> (including me) think they know more about than they actually do.

+1.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-hollenbeck-regext-epp-delete-bcp-01.txt

[Hollenbeck, Scott]

> -Original Message-
> From: I-D-Announce  On Behalf Of
> internet-dra...@ietf.org
> Sent: Tuesday, September 19, 2023 12:02 PM
> To: i-d-annou...@ietf.org
> Subject: [EXTERNAL] I-D Action: draft-hollenbeck-regext-epp-delete-bcp-
> 01.txt
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Internet-Draft draft-hollenbeck-regext-epp-delete-bcp-01.txt is now
> available.
>
>Title:   Best Practices for Deletion of Domain and Host Objects in the
> Extensible Provisioning Protocol (EPP)
>Authors: Scott Hollenbeck
> William Carroll
> Gautam Akiwate
>Name:draft-hollenbeck-regext-epp-delete-bcp-01.txt
>Pages:   16
>Dates:   2023-09-19
>
> Abstract:
>
>The Extensible Provisioning Protocol (EPP) includes commands for
>clients to delete domain and host objects, both of which are used to
>publish information in the Domain Name System (DNS).  EPP includes
>guidance concerning those deletions that is intended to avoid DNS
>resolution disruptions and maintain data consistency.  However,
>operational relationships between objects can make that guidance
>difficult to implement.  Some EPP clients have developed operational
>practices to delete those objects that have unintended impacts on DNS
>resolution and security.  This document describes best practices to
>delete domain and host objects that reduce the risk of DNS resolution
>failure and maintain client-server data consistency.

[SAH] [snip]

https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/

This draft has been updated to address the feedback we received, and 
reorganized to describe current known and suggested possible management 
practices. We've added Gautam as a co-author based on his contributions. 
What's "best" is to be determined.

We're still very interested in feedback. Please, take a look and let us know 
what you think. Which of the known practices should be considered "best"? Did 
we miss any options?

Scott

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Paul Vixie]

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Joe Abley]

(I have trimmed the cc list a bit to avoid bothering the other 20,000 people 
who would otherwise also receive this.)

Op 19 sep 2023 om 17:19 heeft Shumon Huque  het volgende 
geschreven:

> I think we need to clearly separate the definition of a domain name with
> the 'domain name space'. A domain name is just a sequence of labels,
> and is a concept that exists independent of the tree structured namespace
> of the global DNS (or any private DNS namespace for that matter).

Domain names existed before the DNS and are also used by other name resolution 
protocols than the DNS. 

I am not convinced that the term "domain name space" has any real currency, or 
that there's a useful distinction between that and "domain names".

Some domain names are resolvable using the DNS protocol. Others are not. I'm 
not sure it needs to be more complicated than that. 

I agree that a definition of a domain name as an ordered sequence of labels is 
probably better than references to graph theory, which I think most people 
(including me) think they know more about than they actually do. 


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Shumon Huque]

On Mon, Sep 18, 2023 at 8:48 PM Michael Richardson 
wrote:

>
> Michael Richardson  wrote:
> > definition which was objected to by multiple IESG members.
> >
> https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ballot/
> > (in RFC-editor Q, on missref)
>
> > So, if you didn't like that definition before, then probably you
> should
> > object to RFC8499bis keeping it.
>
> Ted's original review that lead to this:
>
> https://mailarchive.ietf.org/arch/msg/dnsdir/Ev83RjCbQcC64paenZXJawKxu9k/


Thanks for the pointer.

If I'm understanding Ted's critique correctly, he is objecting to
conflating the
definition of a domain name with the tree structured DNS namespace, and
using graph theoretic language to make it harder for readers to understand.
(Ted please correct my interpretation if needed).

I agree with that.

I think we need to clearly separate the definition of a domain name with
the 'domain name space'. A domain name is just a sequence of labels,
and is a concept that exists independent of the tree structured namespace
of the global DNS (or any private DNS namespace for that matter). For
example query names may not actually correspond to anything existing
in the DNS namespace, yet they are still valid domain names; owners of
TSIG records are domain names that just identify a TSIG key agreed upon
by their users, and typically have nothing to do with the actual domain name
space. Other examples can be cited.

rfc8499bis-09 has the basic definition correct:

   Domain name: An ordered list of one or more labels.

It then seems to muddy the waters a bit in the sub paragraph by describing
the domain name space, and relating domain names to it. It would be better
to have a separate definition in the document for "Domain Name Space", quote
the relevant text from 1034, and make it clear that although nodes in the
domain name space tree correspond to domain names, domain names can
also exist independent of the namespace.

Shumon.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Gen-art] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

[Vijay Gurbani]

On Mon, Sep 18, 2023 at 8:34 AM Paul Wouters  wrote:

> On Sun, 17 Sep 2023, Salz, Rich wrote:
>
> [ speaking as individual only ] [...]
> I would say that if the WG didn't think it was important at the time by
> forgetting it, it probably is not an "important term", and I can see
> this not being fixed in an IETF LC anymore as an acceptable outcome.
>

Dear Paul: That may be a selective interpretation.  It could just as well
be that no one remembered to bring this term up during the life of the I-D.

Now, if a simple question to the WG on whether the document should include
this term elicits a "no", then of course, the case is closed.  On the other
hand, if the WG returns a "yes", then it seems that the term should be
included in the current revision at the expense of a couple of weeks of
delay.

Thanks,

- vijay
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question regarding RFC 7793

[Benno Overeinder]

Dear Von,

As others have noted, your questions and comments are not relevant to 
the IETF DNSOP WG mailing list.


I would ask that you refrain from follow-up emails on off-topic DNSOP 
topics that may be more appropriate for other IETF WGs, or IRTF Reserach 
Groups discussing cryptography (CFRG) and quantum internet (QIRG).


Kind regards,

Benno Overeinder
DNSOP WG co-chair


On 19/09/2023 10:21, Von Johnson wrote:
Protect current Chrome TLS traffic against future quantum cryptanalysis 
by deploying the Kyber768 quantum-resistant key agreement algorithm.


This is a hybrid X25519 + Kyber768 key agreement based on an IETF 
standard. This specification and launch is outside the scope of W3C. 
This key agreement will be launched as a TLS cipher, and should be 
transparent to users.


https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html 

Motivation
In order to protect today’s network traffic against future quantum 
cryptanalytic attacks, we need to begin migrating network security 
protocols, like TLS, to use quantum-resistant cryptography.
TLS will need to update to quantum-resistant cryptography in three 
separate areas:

- Establishing, or agreeing upon a symmetric session key
- Authenticating the server’s identity (e.g. X.509 certificate validation)
- Authenticating the connection was established by the holder of the 
server’s private key



Why does my public IP address have me showing in new York city?

On Mon, Sep 18, 2023, 11:04 PM Paul Wouters > wrote:


On Mon, 18 Sep 2023, Von Johnson wrote:

 > Hello. Any updates?

There will be no updates from this list. This mailing list is about
designing protocols. Other people and vendors implement these. So
if you have a device problem with any application, please contact
the device vendor or application vendor. We just write lots of pages
of RFC text.

Paul

 > On Fri, Sep 15, 2023, 8:36 PM Mark Andrews mailto:ma...@isc.org>> wrote:
 >       Again please make an understandable request. You do not
describe your problem.  Screen shots are not descriptions.
 >
 >       -- Mark Andrews
 >
 >       On 16 Sep 2023, at 10:20, Von Johnson mailto:voni...@gmail.com>> wrote:
 >
 >       Please help me fix. The x25519 exchange is 
 >
 > On Fri, Sep 15, 2023, 7:58 PM Mark Andrews mailto:ma...@isc.org>> wrote:
 >       Please make a understandable request.
 >       --
 >       Mark Andrews
 >
 >       > On 16 Sep 2023, at 05:24, Von Johnson mailto:voni...@gmail.com>> wrote:
 >       >
 >       >
 >       > Please help me return this to normal
 >       > ___
 >       > DNSOP mailing list
 >       > DNSOP@ietf.org 
 >       > https://www.ietf.org/mailman/listinfo/dnsop

 >
 > Screenshot_20230915-201854.png
 >
 >
 >


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Robert Wilton's Yes on draft-ietf-dnsop-rfc8499bis-09: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-dnsop-rfc8499bis-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8499bis/



--
COMMENT:
--

Thanks for spending the time to keep this up to date.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question regarding RFC 7793

[Von Johnson]

Protect current Chrome TLS traffic against future quantum cryptanalysis by
deploying the Kyber768 quantum-resistant key agreement algorithm.

This is a hybrid X25519 + Kyber768 key agreement based on an IETF standard.
This specification and launch is outside the scope of W3C. This key
agreement will be launched as a TLS cipher, and should be transparent to
users.

https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
Motivation
In order to protect today’s network traffic against future quantum
cryptanalytic attacks, we need to begin migrating network security
protocols, like TLS, to use quantum-resistant cryptography.
TLS will need to update to quantum-resistant cryptography in three separate
areas:
- Establishing, or agreeing upon a symmetric session key
- Authenticating the server’s identity (e.g. X.509 certificate validation)
- Authenticating the connection was established by the holder of the
server’s private key


Why does my public IP address have me showing in new York city?

On Mon, Sep 18, 2023, 11:04 PM Paul Wouters  wrote:

> On Mon, 18 Sep 2023, Von Johnson wrote:
>
> > Hello. Any updates?
>
> There will be no updates from this list. This mailing list is about
> designing protocols. Other people and vendors implement these. So
> if you have a device problem with any application, please contact
> the device vendor or application vendor. We just write lots of pages
> of RFC text.
>
> Paul
>
> > On Fri, Sep 15, 2023, 8:36 PM Mark Andrews  wrote:
> >   Again please make an understandable request. You do not describe
> your problem.  Screen shots are not descriptions.
> >
> >   -- Mark Andrews
> >
> >   On 16 Sep 2023, at 10:20, Von Johnson  wrote:
> >
> >   Please help me fix. The x25519 exchange is 
> >
> > On Fri, Sep 15, 2023, 7:58 PM Mark Andrews  wrote:
> >   Please make a understandable request.
> >   --
> >   Mark Andrews
> >
> >   > On 16 Sep 2023, at 05:24, Von Johnson  wrote:
> >   >
> >   >
> >   > Please help me return this to normal
> >   > ___
> >   > DNSOP mailing list
> >   > DNSOP@ietf.org
> >   > https://www.ietf.org/mailman/listinfo/dnsop
> >
> > Screenshot_20230915-201854.png
> >
> >
> >
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop