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
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
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
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
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
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
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
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 connection at any
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:
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 is
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 the response,
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
says
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
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
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
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 4,
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 validator
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
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
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
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
+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 hardware?
=
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 is
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
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 avoid to
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 SSH
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
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.
Thanks
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:
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
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 if you
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
:27 +
Message-ID: 4b2fb743.5040...@thekelleys.org.uk
Date: Mon, 21 Dec 2009 17:58:27 +
From: Simon Kelley si...@thekelleys.org.uk
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Francis Dupont francis.dup...@fdupont.fr
Subject: Re: dnsmasq and DNSSEC
References
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
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
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
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
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
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]
45 matches
Mail list logo
