Hi David,
On 7/20/15 6:06 AM, David Cake wrote:
> As someone with moderate experience in both DNS and web server
> configuration, FWIW I found the meaning relatively obvious. The notion
> that HTTP Host headers might be used to change web server response
> independent of name resolution (e.g. that
Hi,
I think Mark has done a good job in responding, so I don't really have
much to add.
If you can conveniently do configuration at the client and server,
then you can get strong authentication with TSIG. If you can't, the
weak authentication provided by Cookies is about the best you can do.
See
David,
On Jul 20, 2015, at 5:53 AM, David Cake wrote:
> Of course, ICANN has already determined that .corp does pose a security issue
> of sufficient significance that .corp will not be delegated.
For clarity, I believe ICANN has placed the delegation of .CORP on hold
indefinitely. I do not b
Hello,
having been encouraged to do reviews with my newcomer's eyes, here are some
comments:
On 4.7.2015 17:06, Tim Wicinski wrote:
>> A further change is the removal of the usage of the option over UDP
>> since the semantics of whether a UDP message can say anything about a
>> subsequent TCP mes
On 20/07/2015 10:49, Petr Spacek wrote:
> 3.3.2. Sending Responses
> Current text seems to allow servers to send tcp-keepalive option even if the
> client did not explicitly request it. Is it intended? If it is the case it
> would be nice to say it explicitly. Right now I do not if it is just om
On 6.7.2015 19:04, internet-dra...@ietf.org wrote:
> Title : DNS Transport over TCP - Implementation Requirements
> Authors : John Dickinson
> Sara Dickinson
> Ray Bellis
> Allison Mankin
On 20 Jul 2015, at 10:22, David Conrad wrote:
> On Jul 20, 2015, at 5:53 AM, David Cake wrote:
>
>> Of course, ICANN has already determined that .corp does pose a security
>> issue of sufficient significance that .corp will not be delegated.
>
> For clarity, I believe ICANN has placed the deleg
>
> Yes, there is an HTTP Host header. Yes, responses vary by the *value* but
> not by the *structure*. As far as Apache is concerned, for instance, I would
> imagine it's doing a string compare without counting or considering dots. By
> discussing an arbitrary number of components, that par
Moin!
On 20 Jul 2015, at 4:39, Mark Andrews wrote:
> No. The server takes the fake_client_cookie + IP client (victim) +
> server secret + maybe parts of server cookie itself. Computes a
> server cookie and compares that with what was received. If and
> only if that matches (1 in 2^64) does the f
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
In message <3c8b970b-4588-4f31-ab35-436b7cbb5...@fl1ger.de>, "Ralf Weber" write
s:
> Moin!
>
> On 20 Jul 2015, at 4:39, Mark Andrews wrote:
> > No. The server takes the fake_client_cookie + IP client (victim) +
> > server secret + maybe parts of server cookie itself. Computes a
> > server cookie
So... Alec and I did a bit of wordsmithing and what I propose is a
slight clarification on the existing text, based on this exchange, and
here it is:
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain components. Only the first first label to the
lef
>For clarity, I believe ICANN has placed the delegation of .CORP on hold
>indefinitely.
>I do not believe ICANN has stated that .CORP "will not be delegated." Part of
>the
>reason for this discussion is due to this fact.
Since the new gTLD program still has five active applications for
.CORP, ea
sfarrell> - section 2: "immediately restores" - well that depends on the
sfarrell> screw-up doesn't it? Or are you saying (where?) that an NTA
sfarrell> must only be put in place when the screw-up is specifically
sfarrell> and only about and because of DNSSEC and where ignoring DNSSEC
sfarrell> wi
Thanks for the comments and input.
bcampbell> Can an operator be reasonably expected to be able to confirm
bcampbell> that a domain is being operated by its rightful owner?
A fair amount of the time, yes. I run the DNS team for Comcast and we've
had pretty good luck getting to zone owners. Bette
On 07/20/2015 10:34 AM, Eliot Lear wrote:
> So... Alec and I did a bit of wordsmithing and what I propose is a
> slight clarification on the existing text, based on this exchange, and
> here it is:
>
>
>Like Top-Level Domain Names, .onion addresses can have an arbitrary
>number of subdoma
> > This is not highlighted in the draft which makes it confusing for the
> > reader which causes to raise such question regarding NAT.
>
> Because it is irrelevent has to how the attacker chooses the address to
attack.
> What is relevent is the impact the attack is happening and how a server
can
Hi Donald,
I think all the things you mentioned already addressed in other messages.
So, I would only go to the part that is not already answered
>
> It seems to me that presenting the defenses before the attacks means that
> while you are reading the defenses they are un-motivated. I think the
I'm actually somewhat opposed to adopting Joe's trustanchor draft- I
don't think the cost/benefit analysis works.
We already have a set of formats for trust anchors - DNS master file DS
and DNSKEY records. What the document adds is a signature mechanism
over those items (now formatted as eit
I think I have to agree with you regarding the level of effort to make a go of
this… that said, Joe was/is a member of the ICANN root key rollover team and
is likely the spokesmodel
for the plan they have come up with. To the extent that this may be true, I
believe ICANN is wiling to pay the c
At the end of the meeting I was the last person at the microphone, and what I
said was confusing. Let me explain...
First of all, I mentioned I was chair of SSAC. That was not the slightest a way
of convincing you to listen more to me than others. It was a disclosure. My
apologies if people did
I've taken a brief look at Warren's as yet unpublished draft (attached
to the meeting agenda) and had a few comments.
My major objection to this type of approach is that it doesn't pass the
"cui bono" test. Basically, the major benefit from this is not to the
clients who have to implement the
a long lived mechanism is in-band, not using labels in the DNS or query
payload.
bits in the EDNS space, indicating yes-no and where more than bits are
needed, explicit field:value definitions will get us further.
because they demand code change they can only inform us of the future.
warrens mec
Hi Ralf,
On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber wrote:
> Moin!
>
> On 20 Jul 2015, at 4:39, Mark Andrews wrote:
>> No. The server takes the fake_client_cookie + IP client (victim) +
>> server secret + maybe parts of server cookie itself. Computes a
>> server cookie and compares that with wh
On Mon, Jul 20, 2015 at 9:34 AM, Eliot Lear wrote:
> So... Alec and I did a bit of wordsmithing and what I propose is a slight
> clarification on the existing text, based on this exchange, and here it is:
>
>
>Like Top-Level Domain Names, .onion addresses can have an arbitrary
>number of
Mike,
On Jul 20, 2015, at 6:02 PM, Michael StJohns wrote:
> Basically, the major benefit from this is not to the clients who have to
> implement the "query occasionally so the root knows what I know", but to the
> root operators (or not even them maybe).
Presumably, the clients who have not ye
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Donald Eastlake
>
> Hi Ralf,
>
> On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber wrote:
> > Moin!
> >
>
> While the protocol is designed so that no state needs to be maintained at
the
> server, I don't think th
On 07/19/2015 01:11 PM, Tom Ritter wrote:
> On 18 July 2015 at 04:25, Joel M. Halpern wrote:
>> Major issues: It seems to this reviewer that at least the definition of how
>> to use these names, reference tor-rendezvous, needs to be a normative
>> reference. It appears likely that tor-address als
In message <024401d0c2fc$2cc85ce0$865916a0$@rozanak.com>, "Hosnieh Rafiee" writ
es:
> > > This is not highlighted in the draft which makes it confusing for the
> > > reader which causes to raise such question regarding NAT.
> >
> > Because it is irrelevent has to how the attacker chooses the addr
Hosnieh, below is a real life use of cookies showing how they are used.
Establish a cookie pair. Dig chooses a random value for the client
cookie. The server returns the client cookie along with the server
cookie. The client cookie is checked and as it matched "good" is
displayed.
; <<>> DiG
30 matches
Mail list logo
