On 10. 08. 24 17:21, Michael StJohns wrote:
On 8/9/2024 5:09 PM, Paul Hoffman wrote:
On Aug 9, 2024, at 12:16, Michael StJohns wrote:
Two comments - one major and one very minor.
Major: I'm sorry for the late comment, but I didn't realize you were planning on
starting to provide prospective
Hi Mike,
On 8/10/24 17:21, Michael StJohns wrote:
Paul - this is related directly to the newly specified inclusion of the public
key material in this draft (sect 3.2 last para):
A KeyDigest element can contain both a Digest and a publickeyinfo
named pattern. If the Digest element wou
On 09. 08. 24 20:22, Paul Hoffman wrote:
To everyone who reviewed draft-ietf-dnsop-rfc7958bis in WG Last Call: please
carefully review the diff. Based on a very good IETF Last Call review from Petr
Špaček, we had to make a significant technical change to the XML format, and we
want to be sure
Hi Vint,
On 8/15/24 00:06, Vint Joseph wrote:
The core idea/synopsis
We plan to implement a system using elliptic curve cryptography. A preshared
key, referred to as the public key G^S, is distributed from the dns server to
the client.
How?
Best,
Peter
The server retains the private key S
Hello.
I think dprive fits the encryption topic better than dnsop? Anyway,
some quick thoughts below.
On 15/08/2024 00.06, Vint Joseph wrote:
using UDP and only one or two packets
I suspect that larger answers will be... a complication.
You could rely on UDP fragmentation, but in that case
Hi there!
On 15 Aug 2024, at 00:17, Vint Joseph wrote:
> The core idea/synopsis
> We plan to implement a system using elliptic curve cryptography. A preshared
> key, referred to as the public key G^S, is distributed from the dns server to
> the client.
"Preshared" is easy to type but more d
Hi Vint,
are you aware about [1]? With OSCORE [2] and EDHOC [3] it pretty much
aligns with your idea, as far as I can see, and would also provide you
with a key exchange mechanism for free.
Best
Martine
[1] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/
[2] https://www.rfc-e
Also see DJB's https://dnscurve.org/
CurveCP came before QUIC: https://curvecp.org/
Witold had prepared a draft some years ago of a method:
https://datatracker.ietf.org/doc/draft-krecicki-dprive-dnsenc/
There's https://dnscrypt.info/protocol/ that secures client->resolver
traffic.
There are man
Hi Peter - continues below.
On 8/15/2024 5:41 AM, Peter Thomassen wrote:
Hi Mike,
On 8/10/24 17:21, Michael StJohns wrote:
Paul - this is related directly to the newly specified inclusion of
the public key material in this draft (sect 3.2 last para):
A KeyDigest element can contain bot
Dear all,
Thanks for the responses I received. I got some useful feedback that
helped me improve the drafts.
As Peter Thomassen already mentioned earlier, I was talking about a
label type mainly for confined systems only. Except for some small
exceptions, a record will never leave the DNS se
Hi,
it was not declared if this is intended for client-to-resolver DNS or
resolver-to-authoritative DNS. If the latter, it looks like just another
method of DoE, and like any of those, can be solvable (only?) by DELEG.
I'd like to see the direct comparison against DoQ. I understand that
this
Sorry - 1-3 new issues and commentary on the previous issue.
Expanding:
Please Clarify: The document does not state if this set of TAs is
additive to a relying party's existing TA set or replaces them.
Please Clarify: What happens if you provide a TA with a
"validUntil" in the f
12 matches
Mail list logo
