Hi Ondrej,
On Mon, 22 Jul 2024, Ondřej Surý wrote:
Hi Scott,
FTR .arpa is not "reverse DNS", only the in-addr.arpa and ipv6.arpa is.
.arpa now stands for Address and Routing Parameter Area, and there are
more subdomains than just these two mentioned above.
Ack. Thanks for clarification.
S
Hi Ben,
Welcome to DNSOP! :-)
Your proposal reads like you'd like to add relative names to the DNS protocol.
Reading this thread, however, I realize that you'd simply like to use the 0x40
label type *within the confines of your system*, and are asking to this added
to the DNS Label Types regi
Thanks Ben and Erik for the comments!
Erik, yes I agree, I think we had TLS 1.3 in mind when writing the draft and
when evaluating alternatives for this encrypted DNS scenario. I think we can
make an edit to specify TLS 1.3 or at least post-handshake client
authentication with TLS 1.2. It sound
Dear all,
Today, I released a new version of the draft:
https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-01.
I tried to clarify things a little bit more, added some examples and
fixed some references.
Ben
Ben van Hartingsveldt schreef op 2024-07-21 18:50:
Dear all,
In
Hi Peter,
It is a little bit of both, I think. Yes, I use relative labels already
in my own system internally (now as 0xFF, but I'm planning to move to
0x40). It works and it works very well. However, I'm planning to add DNS
UPDATE to my DNS services, so that my customers can use it in their
In enterprise networks, DNS services typically enforce policies at the
organization and user-group levels, rather than at the individual user
level. DNS filtering is generally not imposed based on individual user
identities. It would be interesting to evaluate other possible solutions
that could e
Hello everyone,
a while ago I asked for guidance concerning a vulnerability I found in a DNS
library.
Unfortunately I cannot find the message right now, so please excuse the new
thread.
The vulnerability now has a CVE and a GitHub Advisory published here:
https://github.com/dnsjava/dnsjava/secu
> The vulnerability now has a CVE and a GitHub Advisory published
> here:
> https://github.com/dnsjava/dnsjava/security/advisories/GHSA-cfxw-4h78-h7fw
>
> I suspect this might be useful feedback to some of you designing
> DNSSEC validation routines, especially for validating stub resolvers.
> I ha
Il giorno mar 23 lug 2024 alle ore 08:16 Scott Johnson <
sc...@spacelypackets.com> ha scritto:
> Hi Lorenzo,
>
> On Mon, 22 Jul 2024, Lorenzo Breda wrote:
>
> > I don't like the way this system permits the same name to refer to
> > different resources on different planets.
>
> It is not one of my
Two questions I didn't see addressed:
Why would a zone need to be signed with multiple private algorithms?
Why isn't it sufficient to treat all private algorithms as a single algorithm
for DS purposes, and distinguish by the Key Tag and/or trial hashing?
--Ben Schwartz
_
At the moment you can only have one private algorithm per key type world wide. This is all to do with how you prove a zone is to be treated as insecure. If example.com is using private.example.com and example.net is using private.example.net how done validator that knows about private.example.co
Remember that a DNSKEY RRset doesn’t have to match all DS records. It only has
to match one. Multi-signer depends on this.
> On 23 Jul 2024, at 09:28, Mark Andrews wrote:
>
> At the moment you can only have one private algorithm per key type world
> wide.
>
> This is all to do with how you
The ANRW talk "Protocol Fixes for KeyTrap Vulnerabilities” this afternoon by
Elias Heftrig, Haya Schulmann, Niklas Vogel, Michael Waidner is proposing that
there is a type roll for DS and DNSKEY. I don’t think this is needed. The
only change actually need is to add a new requirement that says
OK, thanks for the explanation. That helps me understand the scenario where
this would be needed, but it seems like simpler solutions are possible. For
example, the resolver could be configured to restrict the use of PRIVATEDNS
keys to specific subtrees where their usage is known.
This draft
> On 23 Jul 2024, at 10:41, Ben Schwartz wrote:
>
> OK, thanks for the explanation. That helps me understand the scenario where
> this would be needed, but it seems like simpler solutions are possible. For
> example, the resolver could be configured to restrict the use of PRIVATEDNS
> keys
On Monday, July 22, 2024 5:11:23 PM PDT Jessica Krynitsky wrote:
> Thanks Ben and Erik for the comments!
>
> Erik, yes I agree, I think we had TLS 1.3 in mind when writing the draft and
> when evaluating alternatives for this encrypted DNS scenario. I think we
> can make an edit to specify TLS 1.3
> The ANRW talk "Protocol Fixes for KeyTrap Vulnerabilities this
> afternoon by Elias Heftrig, Haya Schulmann, Niklas Vogel, Michael
> Waidner is proposing that there is a type roll for DS and DNSKEY.
> I dont think this is needed. The only change actually need is to
> add a new requirement that s
On Jul 23, 2024, at 12:09, Paul Vixie wrote:
>
>
> Making TLS 1.2 available as a fallback is vital. Many secure private edge
> networks will never allow TLS 1.3 because of ECH.
You can do TLS 1.3 without ECH ?
Making a weaker version of TLS mandatory would be unwise, unless it’s to give
mor
--
P Vixie
On Tuesday, July 23, 2024 12:52:28 PM PDT Paul Wouters wrote:
> On Jul 23, 2024, at 12:09, Paul Vixie
wrote:
> > Making TLS 1.2 available as a fallback is vital. Many secure private edge
> > networks will never allow TLS 1.3 because of ECH.
>
> You can do TLS 1.3 without ECH ?
if
> On 23 Jul 2024, at 12:51, Philip Homburg wrote:
>
>> The ANRW talk "Protocol Fixes for KeyTrap Vulnerabilities this
>> afternoon by Elias Heftrig, Haya Schulmann, Niklas Vogel, Michael
>> Waidner is proposing that there is a type roll for DS and DNSKEY.
>> I dont think this is needed. The on
Hi Tiru,
I agree, and the need to be able to enforce an organizational hierarchy was one
of our early requirements as well. Our thinking was that with mTLS, the
organization could naturally use PKI to represent this structure (although I
will not pretend that OAuth cannot do this too). With cli
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 ability
to disable ECH, so allowing TLS 1.3 does not require an admi
On Tue, Jul 9, 2024 at 2:25 PM John Levine wrote:
> It appears that Tim Wicinski said:
> >This is one of those DNSOP documents that may not be relevant to those who
> >implement DNS, or those who operate DNS infrastructure. It is relevant to
> >Applications that use the DNS, and those who focus
On Tue, Jul 9, 2024 at 2:54 PM Wessels, Duane wrote:
> I read through draft-ietf-dnsop-domain-verification-techniques-05 and have
> a few minor comments / suggestions.
>
Thanks Duane!
> > this may result in IP fragmentation, which often does not work
>
> While it’s true we have come to agree t
On Jul 16, 2024, at 00:06, Di Ma via Datatracker wrote:
>
> Reviewer: Di Ma
> Review result: Ready with Issues
>
> This version adds more discussions about DNSSEC to priming exchange, which I
> think need clearer statements.
>
> In this document, the authors say “With such resolvers, an attacke
On Tue, 23 Jul 2024, Shumon Huque wrote:
The simplest thing to do would be to follow the precedent of SPF,
DKIM, etc TXT using protocols and state that multiple TXT strings
(if present) need to be concatenated before use. We can state
this.
That should be fine.
Wildcards can cause some annoyi
On Tue, 23 Jul, 2024, 02:50 Scott Johnson, wrote:
> Hi Ben,
>
> On Mon, 22 Jul 2024, Ben Schwartz wrote:
>
> > This document seems to propose that "https" URLs will route through
>
> "route through" is exactly what is not happening here. https will be
> secure to the edge of the IP network, whic
On Wed, 24 Jul, 2024, 11:07 Sivasubramanian M, <6.inter...@gmail.com> wrote:
>
>
> On Tue, 23 Jul, 2024, 02:50 Scott Johnson,
> wrote:
>
>> Hi Ben,
>>
>> On Mon, 22 Jul 2024, Ben Schwartz wrote:
>>
>> > This document seems to propose that "https" URLs will route through
>>
>> "route through" is e
28 matches
Mail list logo
