On Tue, Mar 22, 2022 at 7:12 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Paul Wouters wrote:
>
> >> Wrong. DNSSEC as PKI is not cryptographically secure subject to
> >> MitM attacks on CA chains, which is not more difficult than
> >> MitM attacks on ISP chains.
> >
> > I think
A new Request for Comments is now available in online RFC libraries.
BCP 235
RFC 9210
Title: DNS Transport over TCP -
Operational Requirements
Author: J. Kristoff,
D. Wessels
Status: Best
If this space is not extensible from non-IETF RFCs, we’ll have missed the mark.
The space is designed to be large (65K) to allow new work to easily use this
extensibility. We don’t need to be too conservative with this space.
I disagree that there wouldn’t be good experts — we have authors of
> On 23 Mar 2022, at 01:45, Ralf Weber wrote:
>
> Moin!
>
> On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
>> On 14:02 22/03, Ralf Weber wrote:
>>> However missing data might make it impossible for a name server to answer
>>> with the correct (referral) glue data.
>>>
>>> And maybe add some
I agree with Tommy.
Selecting an expert who is able to recognize when wider review might help is a
far lower bar than the one Ray suggests might be necessary.
On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote:
> If this space is not extensible from non-IETF RFCs, we’ll have missed
> the mark.
Masataka Ohta writes:
> Plain DNS with long enough message ID is secure enough.
Hello!
Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?
I must admit I'm a bit lost wrt precisely what that alternative is since
you haven't given a
Bjorn Mork wrote:
Plain DNS with long enough message ID is secure enough.
Hello!
Can you please point me to the set of RFCs (or draft) which describes
this "secure enough" alternative to DNSSEC?
As I wrote "rely on DNS cookie or something like that",
an example is in rfc7873.
Masataka Ohta writes:
> Bjorn Mork wrote:
>
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which
>> describes
>> this "secure enough" alternative to DNSSEC?
>
> As I wrote "rely on DNS cookie or something like that",
Brian Dickson wrote:
If a resolver correctly knows an IP address of a nameserver of a
parent zone
The statement is not more demanding for resolvers to be configured
with correct certificates.
I'm presuming you mean "DNSSEC ICANN/IANA Root Trust Anchor", which is a
public key, not a
There was some internal discussion about using 17 vs 253, with the main
argument for 253 being that this is the intended use case for 253 and
the main argument for 17 being that worry that some resolver
implementations could have special treatment for private algorithm
numbers. As we are
On 21. 03. 22 10:37, Jim Reid wrote:
On 21 Mar 2022, at 09:19, Ben Schwartz
wrote:
Personally, I favor #3. What do you think?
Ben, I think 2 (Expert Review) is the right approach. This would hopefully ensure any specifications are complete/valid and raise the threshold to discourage
Tim Wicinski writes:
> draft-ietf-dnsop-nsec3-guidance-06
>
> Authors are revising in accordance with WG advice– main result has been
> slowly driving the iteration number down.
FYI, there are no outstanding changes to be made to this document based
on the last round of changes. In
Attached. I thought that the mix of in-person mic and MeetEcho went very well!
--Paul
DNSOP WG
IETF 113, Vienna
2022-03-22
Minutes by Paul Hoffman
Text on slides is not reproduced here
~125 people in MeetEcho
Administrivia
Sent longer note top the mailing list with full status
On Mar 22, 2022, at 10:06, Masataka Ohta
wrote:
> Bjorn Mork wrote:
>
>>> Plain DNS with long enough message ID is secure enough.
>> Hello!
>> Can you please point me to the set of RFCs (or draft) which describes
>> this "secure enough" alternative to DNSSEC?
>
> As I wrote "rely on DNS
BIND currently treats 253 as unknown
> On 22 Mar 2022, at 19:56, Nils Wisiol wrote:
>
> There was some internal discussion about using 17 vs 253, with the main
> argument for 253 being that this is the intended use case for 253 and
> the main argument for 17 being that worry that some resolver
Bjorn Mork wrote:
Sorry for being slow, but you'll have to explain a lot more than that if
you want to convince me that DNS cookies and DNSSEC are equivalent
alternatives.
In a sense, they are equivalent, because both plain DNS with
long enough message IDs and DNSSEC are subject to MitM
On Tue, 22 Mar 2022, Masataka Ohta wrote:
Partially yes, because DNSSEC is not cryptographically secure.
Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.
I think at this point we have
Joe Abley wrote:
As I wrote "rely on DNS cookie or something like that", an example
is in rfc7873.
Could I perhaps summarise what you're saying as follows?
1. The cost of DNSSEC signing is high, e.g. due to increased
complexity, brittleness of the DNS, perhaps as shown by relatively
low
On 08. 03. 22 15:51, Willem Toorop wrote:
Dear dnsop,
This draft describes a mechanism for automatic provisioning of zones
among authoritative name servers by way of distributing a catalog of
those zones encoded in a regular DNS zone.
This version's focus was getting ready for WGLC.
Moin!
So to follow up on my comment in the working group on registries not having
anything to do with it. I understand that this drafts is for authoritative name
server implementers, however I think that we should make clear that an
authoritative name server not answering correct by this draft
On 22. 03. 22 14:02, Ralf Weber wrote:
Moin!
So to follow up on my comment in the working group on registries not having
anything to do with it. I understand that this drafts is for authoritative name
server implementers, however I think that we should make clear that an
authoritative name
On 14:02 22/03, Ralf Weber wrote:
> Moin!
>
> So to follow up on my comment in the working group on registries not having
> anything to do with it. I understand that this drafts is for authoritative
> name server implementers, however I think that we should make clear that an
> authoritative
Paul Wouters wrote:
Wrong. DNSSEC as PKI is not cryptographically secure subject to
MitM attacks on CA chains, which is not more difficult than
MitM attacks on ISP chains.
I think at this point we have reached a point where your repeated
claims lack any merit
So, you ignore diginotar to
On Tue, Mar 22, 2022 at 8:48 AM Martin Thomson wrote:
> On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> > On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz
> > wrote:
> >> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
>
On 22/03/2022 16:01, Murray S. Kucherawy wrote:
As to the options proposed, I agree that Expert Review can introduce
delay, but given the above, so too can Specification Required (maybe
worse, in aggregate). So I recommend Expert Review.
I am concerned that the set of Expert Reviewers
On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote:
> I am concerned that the set of Expert Reviewers necessary to handle SVCB
> needs to have both expert DNS experience *and* detailed knowledge of the
> SVCB model for this to work.
>
> I am not sure there's anybody who fits that criteria.
>
My reading of this thread is that one person thinks that there is a better way
to achieve what DNSSEC is designed to achieve, and no one else agrees with him.
Thus, I'll leave the text in the document alone unless I see more support for
that lone opinion.
--Paul Hoffman
smime.p7s
Description:
On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz wrote:
> [...] any individual I-D is considered a qualified specification as
> soon as it is uploaded to the Datatracker.
>
Do you have a reference that asserts this? An I-D that isn't published
will expire, which would appear to contradict
Moin!
On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
> On 14:02 22/03, Ralf Weber wrote:
>> However missing data might make it impossible for a name server to answer
>> with the correct (referral) glue data.
>>
>> And maybe add some encouragement or referral ;-) to work that has to be done
>>
On 15:45 22/03, Ralf Weber wrote:
> Moin!
>
> On 22 Mar 2022, at 14:43, Hugo Salgado wrote:
> > On 14:02 22/03, Ralf Weber wrote:
> >> However missing data might make it impossible for a name server to answer
> >> with the correct (referral) glue data.
> >>
> >> And maybe add some encouragement
On Wed, Mar 23, 2022, at 02:45, Murray S. Kucherawy wrote:
> On Mon, Mar 21, 2022 at 2:20 AM Ben Schwartz
> wrote:
>> [...] any individual I-D is considered a qualified specification as soon as
>> it is uploaded to the Datatracker.
>
> Do you have a reference that asserts this? An I-D that
31 matches
Mail list logo
