sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] status page


From: Arnold
Subject: Re: [Sks-devel] status page
Date: Sat, 19 Apr 2014 16:52:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0

Hi list,

Trying to be a bit more on-topic again...

On 04/18/2014 10:42 PM, Simon Lange wrote:
> Am 18.04.2014 22:10, schrieb Martin Papik:
>> Answering ALL host names just makes you willing to participate in any
>> pool by default, without extra maintenance. But again, AFAIK this
>> isn't a requirement. Am I misinformed?
> 
> https://twitter.com/krifisk/status/456717051340791808
> "With a HTTP Host header not belonging to the specific hostname? Note
> the -H 'Host.....' , 11371 should allow ALL traffic through"

I figured this is because of the following.

HTTP is a unique protocol in that it allows the client to provide the hostname 
of
the host it is communicating to (basically it is a selection parameter a client 
can
provide, regardless of the hostname it resolved, for servers hosting several
websites). Other protocols, like SMTP, NTP, etc. just listen at a given IP/port
that the client 'somehow' manages to obtain. THAT is how most of the internet 
works.

I have not looked into it but I am not even sure HTTP requires the 'HOST' header
field to be present in requests. AFAIK it was not sent in the early days.

The key exchange protocol HKP is not an RFC standard. AFAIK it is best 
specified in
http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00
It does not mention the 'HOST' field, so I guess openGPG implementations using 
HKP
are not required to provide a (valid) HOST. Note that HKP is a protocol by 
itself
(P in HKP), just reusing some of HTTP.

People implementing HKP for small devices (Android, iOS, embedded systems, etc.)
may omit sending the HOST, although they may be using our pool domain.

Therefore, we (people in the pool) can make no assumptions on the value of the
'HOST' parameter. Therefore, it is good practice (if being part of the pool) to
respond to all clients connecting to port 11371.
And therefore, I don't provide the HKP-service at port 80 over IPv4. My choice 
:-)


>> How would bad people benefit from your key-server responding to
>> http://very.bad.com:11731/ anyway?
> 
> "bad ppl" could pretend offering a public service using my machines they
> dont own nor they administre nor they run. my machines would support
> that passivly. think this is easy to understand. and also has some legal
> implications.

No, although it might give you trouble explaining to legal people how DNS and 
the
internet works... It is just not in your hands what IP's other people put in 
their
DNS. People who associate you with the owners of 'unwanted domain' simply don't
understand the internet.

I understand there might be situations that can make you feel uncomfortable,
especially when serving a website. However, among the millions of keys we 
serve, I
am sure there are keys of people that I don't want to be associated with.
Therefore, I try to be associated with 'undiscriminating' key server 
administrators
and hope this outweighs possible negative associations :-)

To me, it is even better if Mr(s) Bad points his/her own domain/DNS to my key
server to get his/her key, than prominently being listed with my own domain 
name on
the website of Mr(s) Bad. That would even result in a google-association...


Off-topic
As a side note: curious how easily some discussions on this list go into 
extremes,
followed by getting personal and people getting hurt. Usually that kind of 
emotions
is a sign of dedication to the subject, making it even more painful...

As I am open to every client connecting (though rate limited), I am also open 
for
peering with every SKS operator. Just send me your info off-list and I'll send 
you
mine.

Just my € 0,02

Arnold



reply via email to

[Prev in Thread] Current Thread [Next in Thread]