Moin!
On 5 Apr 2019, at 10:50, Peter van Dijk wrote:
Adding records at child side of cut has its own issues, namely that
retroactive authentication can be annoying to implement, and it is
more difficult to make the thing work without full DNSSEC chain
(glue records, if parent supports that?).
On Fri, Apr 05, 2019 at 10:50:35AM +0200, Peter van Dijk wrote:
> On 31 Mar 2019, at 16:22, Ilari Liusvaara wrote:
>
> > DS is signed, and has algorithm field. Supposedly unknown algorithms
> > are ignored, but there are buggy nameservers out there that break if
> > all DS entries have unknown
On 31 Mar 2019, at 16:22, Ilari Liusvaara wrote:
DS is signed, and has algorithm field. Supposedly unknown algorithms
are ignored, but there are buggy nameservers out there that break if
all DS entries have unknown algorithm. And turns out abusing DS
records also runs into issues with "cloud"
Ilari Liusvaara wrote:
>
> Adding another RRtype with needed magic properties would take Standards
> Action (as expert review requires RRtype not to be magic) and then
> updating parent nameservers to be able to deal with the RRtype (since
> it can not be generically handled).
Don't forget the
> On 01/04/2019 07:19, Alexander Mayrhofer wrote:
> > I have some experience in creating drafts for "funny" EDNS0-options
> > (RFC7830), so I'd volunteer :-P
> Actually, that maybe raises a point. If use of DoT to secure recursive to
> authoritative traffic also requires padding (and I can't see
On 01/04/2019 07:19, Alexander Mayrhofer wrote:
> I have some experience in creating drafts for "funny" EDNS0-options
> (RFC7830), so I'd volunteer :-P
Actually, that maybe raises a point. If use of DoT to secure
recursive to authoritative traffic also requires padding (and
I can't see why
All,
> Dear all,
> Please rip these ideas to shreds:
> 1) An extra bit in a response for "you could have asked over TLS"
> 2) An extra field when looking up the nameserver for "you can ask that
> server over TLS"
> 3) An extra field/bit/convention for "this nameserver supports tls"
> (like
On Sun, 31 Mar 2019, Watson Ladd wrote:
Please rip these ideas to shreds:
1) An extra bit in a response for "you could have asked over TLS"
Too late, you already lost your privacy.
2) An extra field when looking up the nameserver for "you can ask
that server over TLS"
Where would this
On Sun, Mar 31, 2019 at 7:15 AM Ralf Weber wrote:
>
> Moin!
>
> > On 31. Mar 2019, at 14:48, Watson Ladd wrote:
> >
> > Dear all,
> > Please rip these ideas to shreds:
> I assume with this sentence you mean that the following ideas are bad ideas.
> Is this correct? If so why not say so, as
On Sun, Mar 31, 2019 at 05:48:21AM -0700, Watson Ladd wrote:
> Dear all,
> Please rip these ideas to shreds:
> 1) An extra bit in a response for "you could have asked over TLS"
Seems vulernable to downgrade attacks. And seemignly leaves obtaining
the authentication data as open problem.
> 2) An
Moin!
> On 31. Mar 2019, at 14:48, Watson Ladd wrote:
>
> Dear all,
> Please rip these ideas to shreds:
I assume with this sentence you mean that the following ideas are bad ideas. Is
this correct? If so why not say so, as there are a lot of people in here
including myself who are not native
Dear all,
Please rip these ideas to shreds:
1) An extra bit in a response for "you could have asked over TLS"
2) An extra field when looking up the nameserver for "you can ask
that server over TLS"
3) An extra field/bit/convention for "this nameserver supports tls"
(like tls-ns vs ns)
Sincerely,
12 matches
Mail list logo
