Hi Lorenzo,
I may have accidentally trimmed the lists from my previous reply, thanks
for reincluding them!
On Tue, 23 Jul 2024, Lorenzo Breda wrote:
Il giorno mar 23 lug 2024 alle ore 08:16 Scott Johnson
ha scritto:
Hi Lorenzo,
On Mon, 22 Jul 2024, Lorenzo Breda wrote:
> However, it doesn't make sense to include step 4. A DNSSEC validator will
> have taken care of step 4.
Partially. I believe the DNSSEC validation and following the CNAME-chain have
to be implemented in the same routine.
This is because to perform an authenticated denial of existence, you firs
It seems we have a terminology mismatch: segmented encryption that covers each
network hop but requires re-encryption at some relays, as proposed, is the
opposite of "end to end encryption".
Regardless, I do not think rewriting of domain names to append a supra-root
hierarchy within the domain
> And how is this different to migrating to IDKEY? The validator
> would need to support DS + IDDS + DNSKEY + IDKEY for a significant
> period. One can turn off support for algorithms without the new
> semantics. As for *SHA-1 many validators already treat those
> algorithms as unsupported.
I'm
> Partially. I believe the DNSSEC validation and following the
> CNAME-chain have to be implemented in the same routine. This is
> because to perform an authenticated denial of existence, you first
> need to know which name and rrtype you want to prove does not exist.
DNSSEC validation follows th
Yet another reason to validate on the stub... :)
On Wed, Jul 24, 2024 at 8:37 AM Philip Homburg
wrote:
> > Partially. I believe the DNSSEC validation and following the
> > CNAME-chain have to be implemented in the same routine. This is
> > because to perform an authenticated denial of existence
Hi,
On Wed, 2024-07-24 at 17:36 +0200, Philip Homburg wrote:
> > Partially. I believe the DNSSEC validation and following the
> > CNAME-chain have to be implemented in the same routine. This is
> > because to perform an authenticated denial of existence, you first
> > need to know which name and
On Tue, Jul 23, 2024 at 3:56 PM John R Levine wrote:
>
> > I don't think this is necessary. Some applications do this today, but
> > I suspect it is to make it easier to identify the application from the
> > sea of verification TXT records at the zone apex. Since the draft
> > recommends applicat
Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson <
sc...@spacelypackets.com> ha scritto:
> Hi Lorenzo,
>
> [omissis]
>
> Pardon the background tangent;
>
It was pretty interesting.
> I will now address your point regarding
> valid URIs in one network becoming invalid URIs in another, and
> Le 24 juill. 2024 à 11:42, Lorenzo Breda a écrit :
>
>
>
> Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson
> mailto:sc...@spacelypackets.com>> ha scritto:
>> Hi Lorenzo,
>>
>> [omissis]
>>
>> Pardon the background tangent;
>
> It was pretty interesting.
>
>> I will now address
On Wed, 24 Jul 2024, Shumon Huque wrote:
The issue is that a wildcard will match every possible owner name. If you
are confident that there is enough entropy in the tokens that no verifier
will ever be confused, OK. But since the token is supposed to be the only
thing at the _prefix name, how a
Hi Ben,
On Wed, 24 Jul 2024, Ben Schwartz wrote:
It seems we have a terminology mismatch: segmented encryption that
covers each network hop but requires re-encryption at some relays, as
proposed, is the opposite of "end to end encryption".
Right, but end to end confidentiality and integrity c
Hi Lorenzo,
On Wed, 24 Jul 2024, Lorenzo Breda wrote:
Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson
ha scritto:
Hi Lorenzo,
[omissis]
Pardon the background tangent;
It was pretty interesting.
Glad you enjoyed it.
I will now address your point regarding
va
Hi Marc,
On Wed, 24 Jul 2024, Marc Blanchet wrote:
Le 24 juill. 2024 à 11:42, Lorenzo Breda
a écrit :
Why are you against leaving the current TLDs implicitly on Earth
by default?
Right. One do not need a special TLD for space. We can use what we have
and it just works fine.
Il giorno mer 24 lug 2024 alle ore 22:24 Scott Johnson <
sc...@spacelypackets.com> ha scritto:
>
>
> > it would
> > be break signatures (eg on API payloads and on emails,
>
> Funny you should mention email, as I am in the process of constructing a
> working implementation in a dedicated multi-worl
> Le 24 juill. 2024 à 13:43, Scott Johnson a écrit :
>
> Hi Marc,
>
> On Wed, 24 Jul 2024, Marc Blanchet wrote:
>
>>
>> Le 24 juill. 2024 à 11:42, Lorenzo Breda
>> a écrit :
>> Why are you against leaving the current TLDs implicitly on Earth
>> by default?
>> Right. One do not need
Hi all,
Please see the below announcement of pqc-dns...@ietf.org, the creation of which
is a result of our Monday side meeting.
If you're interested in following or participating in this work, feel free to
sign up!
We'll reach out on this new list in a bit and gather work that folks are
inte
A new Request for Comments is now available in online RFC libraries.
RFC 9619
Title: In the DNS, QDCOUNT Is (Usually) One
Author: R. Bellis,
J. Abley
Status: Standards Track
Stream: IETF
Date: Jul
Hi Lorenzo,
On Wed, 24 Jul 2024, Lorenzo Breda wrote:
Il giorno mer 24 lug 2024 alle ore 22:24 Scott Johnson
ha scritto:
> it would
> be break signatures (eg on API payloads and on emails,
Funny you should mention email, as I am in the process of
constructing a
Il giorno gio 25 lug 2024 alle ore 00:13 Scott Johnson <
sc...@spacelypackets.com> ha scritto:
>
> > I'm mostly concerned about signatures for integrity check and sender
> > identity check. PGP and its derivatives, for example (here in Italy we
> > have the PEC system, a government standard to sen
Hi Marc,
Why are you against leaving the current TLDs implicitly on Earth
by default?
Right. One do not need a special TLD for space. We can use what we have and it
just works fine.
I do not disagree with this notion as respects my proposed
architecture. 3rd level domains mapped to off-worl
Hi Lorenzo,
OK. I will ruminate on this for a bit. I think it will be workable, but
I need to examine system-wide ramifications before I can confirm that.
Thanks,
ScottJ
On Thu, 25 Jul 2024, Lorenzo Breda wrote:
It interacts with other email system as a regular email (with some
signatur
Reviewer: Joe Clarke
Review result: Has Issues
I have been asked to review this draft on behalf of the OPS Directorate. This
draft describes to initialize a recursive DNS resolver when its cache is empty
(i.e., at initial start time). While I found the document well-written, it
left me with a fe
On Tuesday, July 23, 2024 1:56:50 PM PDT Ben Schwartz wrote:
> It seems like there's some confusion here. ECH is an extension to TLS that
> is still under development (and now nearly final). Use of ECH is optional
> in TLS 1.3. Any entity that can control the TLS version in use also has
> the ab
24 matches
Mail list logo
