In your previous mail you wrote:
> Two points that I request this WG to discuss are:
>
> 1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft)
=> I'd like to do this but it is not possible to change requirements
for existing implementations so easily. I added a SHOULD for
In your previous mail you wrote:
> The setting of the time fields on BADKEY is not well defined. We had implem
> entations setting the values to zero. Handling of BADKEY with a bad time is
> also not handled well. I would recommend always copying the time fields fro
> m the request to the
In your previous mail you wrote:
> After a reading, I felt that this document needs the following:
>
> * Editing for clarity of sentences
=> I agree until the text comes from original RFCs (i.e. you are
17 year too late) or can only be clarified at the margin.
> * Addressing insufficient p
Need a short slot (5 mn) about the revision of TSIG specs just
submitted as draft-dupont-dnsop-rfc2845bis-00.txt
Thanks
francis.dup...@fdupont.fr
PS: there are in fact only a few since IETF99: just the work is in
progress and should one day become a WG item. IMHO today the main
difference is the
In your previous mail you wrote:
> But, yes, you're correct -- diagnostic information included with a
> SERVFAIL is about as trustworthy as the AD bit, and in the absence of an
> authentication mechanism such as TSIG, clients should not rely on it or
> base policy on it.
=> TSIG can be in a
+1 (in favor)
francis.dup...@fdupont.fr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
In your previous mail you wrote:
> NSEC needs no keys, only their RRSIGs would which wouldn't exist in
> unsigned zones. In this case the unsigned NSEC would also not be part of
> the zone (it would have to be synthesized and maintained outside the
> zone).
=> but it is created by an authori
In your previous mail you wrote:
> There are still many popular unsigned zones, many of which don't look
> like they will be signed soon due to operational and other reasons.
>
> Will you give some thought and reply with your opinion on NSEC/NSEC3 for
> unsigned zones requiring the DNS COOK
As you should know now there are some security problems in different
TSIG implementations. IMHO the source of the problem is in TSIG RFCs
so it is likely we'll have to discuss about publishing one or two
Erratas. So even with a formal request for time in the agenda I believe
we should consider to k
In draft-wouters-sury-dnsop-algorithm-update-01.txt the RSASHA512
(code 10) DNSKEY/RRSIG algo got a SHOULD- for DNSSEC signing.
The argument is it is not currently heavily used but I am afraid
it is not a very good argument.
I have a question for cryptographers in the list: as far as I know
there i
Here is a short review of draft-ietf-dnsop-cookies-04.txt. Note I was
heavily involved into the "SIT" experiment (SIT was a scaled down
version of the DNS cookie idea provided by bind9 version 9.9) so
you should not surprise I like the DNS cookie.
I have two comments about the current text which a
I like your proposed text so if there is no objection I suggest to
simply adopt it (and to close this particular point).
Thanks
francis.dup...@fdupont.fr
PS: for people who want to match the text here are the first 2 lines:
we should allow servers to use whatever timeout they want -- but we
In your previous mail you wrote:
> > IMHO to not change the TCP requirement (which is today a MAY for
> > deployment on clients and servers) will be very irresponsible because
>
> DNS + TCP was *never* a MAY. RFC 1123 says SHOULD. People took
> liberties and treated it as a MAY.
=> ther
(other points, i.e., not TCP mandatory or timeouts)
In your previous mail you wrote:
> this means that while it's not ideal, it's not as broken as it could be.
> with changes to recommended initiator behaviour, we could make these
> existing servers more broken, or we could preserve their pre
In your previous mail you wrote:
> i believe that the last of the old-style initiators who treated
> premature closure by the responder as an urgent condition warranting a
> message to the console or the system log file have diminished to the
> level of noise, but that the change francis is a
In your previous mail you wrote:
> >> I believe 5966bis already addresses your first point quite clearly.
> >> (note: first point is to make TCP support mandatory)
> >>
> >> For example, it says:
> >>
> >> This document therefore updates the core DNS protocol specifications
> >>
I am splitting the thread in separate points.
francis.dup...@fdupont.fr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
In your previous mail you wrote:
> As mentioned in the wg yesterday an informational document with
> current behaviors may be helpful?
=> I am afraid it could only add confusion so IMHO it may not.
> > On Mar 25, 2015, at 9:52 AM, Paul Vixie wrote:
> >
> > initiators have historically been
In your previous mail you wrote:
> > => unfortunately this is a change in the protocol the document is
> > not supposed to do here even it both makes sense and follows the real
> > world situation.
>
> I disagree that this is a change.
>
> RFC 1035 allows the server to close the connecti
In your previous mail you wrote:
> >>This document therefore updates the core DNS protocol specifications
> >>such that support for TCP is henceforth a REQUIRED part of a full DNS
> >>protocol implementation.
>
> Sorry, I should have realized that RFC 5966 (August 2010) already
>
In your previous mail you wrote:
> I believe 5966bis already addresses your first point quite clearly.
>(note: first point is to make TCP support mandatory)
>
> For example, it says:
>
> This document therefore updates the core DNS protocol specifications
> such that support for TCP
In your previous mail you wrote:
> > So I propose:
> > - make clear that TCP support is mandatory.
> > - allow servers to use the timeout they like, even a zero timeout
> > (the last point should be discussed). Note a zero timeout doesn't
> > mean "send the response and close" but "send th
As we have more and more DNS over TCP (large responses, response
rate limitation, even TLS for privacy) I think we should fix the
way DNS over TCP is supposed to be handled by servers.
Quoting RFC 1035 4.2.2 "TCP usage":
- The server should assume that the client will initiate
connection c
In your previous mail you wrote:
> Defining a canonical form in no way is meant to imply that any other form
> is wrong. The objective is to put a name on a canonical form, and provide
> a reference, so that anyone who wants to see zone files meeting a strict
> format can say so succinctly.
In your previous mail you wrote:
> Okay, well, maybe something new. Like - should the master files be in
> ASCII or accommodate, say UTF-8? Just a teaser of what would be part of a
> definition. (I have seen some zone files put IDNA U-Labels in the owner
> field.)
=> at least one of the I
What about RFC 1035 (aka STD 13) section 5 "MASTER FILES"?
Thanks
francis.dup...@fdupont.fr
PS: the concept was introduced in RFC 1034, RFC 2308 added $TTL,
RFC 2540 (dead?) added $DATE, $GENERATE is a BIND extension
(Mark shall confirm but it is what the BIND 9 ARM says).
And I agree there is n
In your previous mail you wrote:
> If you want to make the connections full-duplex instead of
> half-duplex, you need to negotiate connection teardown at the DNS
> layer. Otherwise, the TCP connection teardown will result in loss of
> already-transmitted responses.
=> I don't understand: to
In your previous mail you wrote:
> Francis, while my own thinking goes further-- an initiator should
> not leave a persistent TCP session idle, even for a microsecond,
> unless the responder has signaled its approval of such strategy--
=> it is what RFC 1035 said so a bit difficult to change
In your previous mail you wrote:
> If you see a use case for the EDNS tcp-keepalive option as originally
> discussed, please say so, on the list, by February 4, 2015.
=> I have one (more later).
> If you want to pursue the connection-close draft, please say so, on the
> list, by February
In your previous mail you wrote:
> Currently a number of validators don't do ECC, because of the openssl
> library from the distribution they are using doesn't include support.
> This makes ECC an unsupported algorithm, and so it "fails open" (See
> RFC4035, Section 5.2, around "If the valida
I am working on the different aspects of the query pipeling (for DNS
over TCP or any stream / sequenced packet transport). I try a new tool
which sends multiple queries to check which authoritative nameserver
implementations support out-of-order responses with a funny result!
I never got a conclusi
Some comments:
- 4 page 5: "It (TCP)
SHOULD NOT be used only for zone transfers and as a fallback."
this SHOULD NOT is very hard to implement without dubious
interpretations (i.e., the idea is right but the current wording
could lead to unexpected/unwanted results).
- 5 page 4: "both c
In your previous mail you wrote:
> This starts a Call for Adoption for draft-dickinson-dnsop-5966-bis
=> I support the adoption (even there are many points I disagree,
BTW it is more a reason to adopt it :-). I'll review it, etc.
Regards
francis.dup...@fdupont.fr
In your previous mail you wrote:
> This starts a call for adoption for draft-eastlake-dnsext-cookies.
=> for adoption (and review/implementation/etc)
francis.dup...@fdupont.fr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listin
+1 for adoption (and at the occasion contribute, review, implement, etc).
francis.dup...@fdupont.fr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
In your previous mail you wrote:
> >> Does "several thousands of queries per second during normal
> >> operations" with TCP matter?
> >
> > => yes because it is at the limit current OSs can do on cheap stock
> > hardware...
>
> Are you saying real root servers are using cheap stock h
In your previous mail you wrote:
> Does "several thousands of queries per second during normal
> operations" with TCP matter?
=> yes because it is at the limit current OSs can do on cheap stock
hardware...
Regards
francis.dup...@fdupont.fr
PS: I wrote OS because the first reached perf limit
In your previous mail you wrote:
> The verification performance is bad, P256 takes 24x times longer to verify a
> signature than 2048 bit RSA key.
=> I got a different figure (6x) for my ECC paper, and:
- it was published the 3 may 2013 so one can expect ECC performance
has been improved s
In your previous mail you wrote:
> If we follow this line of reasoning, why do we deploy more security,
> then?
=> because we want (and as you noticed they don't want).
> With this argument, we would never have deployed HTTPS
> either.
=> have we? I am afraid most HTTPS are MITM'ed where S
This is an update of my previous messages.
The generic DNS confidentiality problem can be divided into 3 cases:
1- stubs <-> local resolver
2- stubs <-> remote open resolver
3- resolver <-> auth. servers
In the first case the local resolver is in the same security area
(I use "area" to avoi
Another note about builtin/inline encryption solutions: there is a
trade-off between encryption + authentication/integrity as recommended
by crypto design rules vs. performances and message sizes. Of course
this will be addressed during the crypto design, so when/after we
reach a consensus about w
In your previous mail you wrote:
> > I consider the first one to be already solved, cf. the Microsoft
> > deployed solution which puts clients, local networks, the resolver
> > (also the Microsoft Domain Server :-), in the same area and uses
> > IPsec to protect it.
>
> Which may be great
In your previous mail you wrote:
> > Or with other words you don't need confidentiality with 8.8.8.8
>
> Why don't we need confidentiality with open resolvers like google?
=> because the goal is not confidentiality at the level a Microsoft
environment needs (because Microsoft adopted and ex
In your previous mail you wrote:
> This is some good summarizing. With your solution, you don't mention
> UDP. I would consider the lack of UDP an issue with moving forward at
> least for wide deployment. Others seem to think otherwise.
=> I didn't add UDP in constraints but I made the "s
>From discussions with Stephane Bortzmeyer and Mark Andrews...
First I come back to the fact there are two different problems
(aka divide and conquer):
* stubs <-> resolver
* resolver <-> auth servers
I consider the first one to be already solved, cf. the Microsoft
deployed solution which puts
In your previous mail you wrote:
> And perhaps even start earlier and/or end a bit later than the
> allocated slot (0900-1130) if it's allowed and works for many?
=> to start earlier won't fit for people leaving London Friday
(checkout, etc). For me the other side (end later) could work.
Than
In your previous mail you wrote:
> If we created a new session in the thursday evening 18:40-20:40 slot
=> already booked in this slot. Sorry...
francis.dup...@fdupont.fr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dn
In your previous mail you wrote:
That might be draft-hoffman-dnssec-ecdsa.
=> IMHO we have a problem with ECDSA (and DSA too): verify is too slow,
in particular it is slower than signature. You can expect a crypto
accelerator for a master authoritative server, but not (yet?) for
a caching ser
In your previous mail you wrote:
But AFAIK, no dns implementation supports ECC yet.
=> *** flame war ON ***
In fact it is no true: GOST (in its second version which will be used
for DNSSEC) is based on ECC.
*** flame war OFF ***
francis.dup...@fdupont.fr
PS: there is no real technical
om: Simon Kelley
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Francis Dupont
Subject: Re: dnsmasq and DNSSEC
References: <200912210949.nbl9njhg084...@givry.fdupont.fr>
In-Reply-To: <200912210949.nbl9njhg084...@givry.fdupont.fr>
X-Enigmail-Version: 0.9
In your previous mail you wrote:
I've found another "culprit" in the program DNSMASQ - distributed
with FedoraCore 10 and later versions of RedHat.
=> I asked some days ago the author to change the defaut to 4096
and in his answer he wrote it will be fixed in the next release.
BTW as y
In your previous mail you wrote:
On May 5, 2009, at 10:11 PM, YAO Jiankang wrote:
> thanks for your information.
> so we can say that in the current practise, the (validating )
> resolvers are not run by local host or machine.
=> between the two solutions, not-validating securit
In your previous mail you wrote:
=> there are places where cryptography is required to be implemented
in hardware, and many business reasons or even regulations which
mandate HSMs.
But the risk for the key is not only people modifying it, it is simply
people *reading* it (a concern which a
In your previous mail you wrote:
There is no standard way to say "I don't want to receive email"
(unfortunately).
=> it is an old problem, RFC 1846 tried to mitigate it...
Regards
francis.dup...@fdupont.fr (as a co-author of 1846).
___
DNSOP
In your previous mail you wrote:
So they are aware that this is broken. Let's hope that this type of
service discovery through a fraction DNS root doesn't make its way
into the final standard.
=> I agree but what you propose to do? There will be a double session
of behave WG tomorrow a
In your previous mail you wrote:
> it seems T/TCP is dead because of some security issues.
Correct (RFC 4614, section 5) but, unfortunately, these issues were
apparently never properly documented (no "T/TCP deprecated" RFC) and
it is hard to find a reference to a description of th
In your previous mail you wrote:
The concern I see (that I had hoped would be avoided by DO being set
to 1 only when the caching server administrator had explicitly
configured DNSSEC awareness) is that folks who are blissfully unaware
of the root being signed would, through no f
In your previous mail you wrote:
Now, I'm saying, for these 10 years, that PKI is broken.
=> what is broken? Crypto, trust model, architecture (including
the RA/CA stuff), etc. There should be many ways to be broken (:-).
That signature generation mechanism is accessible on line does n
In your previous mail you wrote:
If a caching server is required to perform public key computation to
verify RRs before caching, it can't support much clients...
=> the common assumption that public key computation is slow or
expensive is *wrong*. According to 'openssl speed rsa', My old
2
In your previous mail you wrote:
nobody to complete or champion T/TCP
=> it seems T/TCP is dead because of some security issues.
In another thread about fragmentation (vs firewalls) someone proposed DCCP.
At least, it avoids RFC 1035 4.2.2 (:-)!
[EMAIL PROTECTED]
___
In your previous mail you wrote:
Yes. I've just been told by a fairly authoritative source that BIND
9.5.1 (at least) sets the DO bit on by default, regardless of whether
DNSSEC is configured. This would explain the high number of queries
coming in with DO set.
=> as you kn
In your previous mail you wrote:
So please consider other options before repeating the holy mantra 'DNSSEC is
the only solution'.
=> it is not a mantra but the reality:
- transaction protection is not enough if we want to keep caching
in the middle
(the argument is it has to be a
62 matches
Mail list logo
