Personally I would use a new opcode and fall back to query on NOTIMP.
The payload of the new OPCODE does not have to be decodable by
existing servers. This is also how EDNS should have been done.
Since it is next to impossible to hide that you are talking to a
server use unencrypted DNS w/ DNSSE
On Jul 7, 2014, at 9:52 AM, Paul Vixie wrote:
> i wish it noted that i am responding to the general post-snowden call for
> channel secrecy, and that i don't myself see much need for it in the case of
> DNS, but that the proposals i've seen come out of the security community for
> how to add c
Matthäus Wander wrote:
> ...
>
> I didn't mean to imply that a DTLS solution can be universally deployed.
because the dns is a map to the territory known as the internet, and
because most internet packet flows begin with a dns transaction, i'm
dismissing out of hand anything that will almost uni
* Paul Vixie [2014-07-06 19:29]:
> Matthäus Wander wrote:
>> * Paul Vixie [7/5/2014 7:47 PM]:
>>> Matthäus Wander wrote:
DTLS works on top of UDP (among others) and thus can pass CPE devices.
>>> no, it cannot. DTLS does not look something that the CPE was programmed
>>> to accept; thus in man
Nicholas Weaver wrote:
> ...
>
> One important observation: ONLY the path between the client and the
> recursive resolver in the classic model substantially benefits from channel
> security.
if i were proposing a secrecy scheme that was easy to do on
stub-to-recursive but hard to do on recurs
On Jul 7, 2014, at 8:24 AM, John Kristoff wrote:
>> by implication, then, the remainder of possible problem statement
>> material is "hide question from on-wire surveillance", there being no
>> way to hide the questioner or the time. to further narrow this, the
>> prospective on-wire surveillance
On Fri, 04 Jul 2014 20:04:02 -0700
Paul Vixie wrote:
> first, dns data itself is public -- the data is there for anybody to
> query for it, if you know what to query for. only the question,
> questioner, and time can be kept secret. answers are only worth
> keeping secret because they identify th
Matthäus Wander wrote:
> * Paul Vixie [7/5/2014 7:47 PM]:
>> Matthäus Wander wrote:
>>> DTLS works on top of UDP (among others) and thus can pass CPE devices.
>> no, it cannot. DTLS does not look something that the CPE was programmed
>> to accept; thus in many cases it is silently dropped.
>>
>
>
This is really a design question.
As far as I am concerned, DNS is and always will be a first class Internet
protocol. It is the foundation for everything else. The syntax etc can
change but it is a building block other stuff should build on, not
something that can leverage other facilities.
So t
* Paul Vixie [7/5/2014 7:47 PM]:
> Matthäus Wander wrote:
>> DTLS works on top of UDP (among others) and thus can pass CPE devices.
>
> no, it cannot. DTLS does not look something that the CPE was programmed
> to accept; thus in many cases it is silently dropped.
>
DTLS can be used on top of UDP
Matthäus Wander wrote:
> * Paul Vixie [7/5/2014 5:04 AM]:
>> datagram level channel secrecy (for example, DTLS or IPSEC) offers a
>> solution which matches the existing datagram level UDP transport used
>> primarily by DNS. however, the all-pervasive middleboxes (small plastic
>> CPE devices inst
* Paul Vixie [7/5/2014 5:04 AM]:
> datagram level channel secrecy (for example, DTLS or IPSEC) offers a
> solution which matches the existing datagram level UDP transport used
> primarily by DNS. however, the all-pervasive middleboxes (small plastic
> CPE devices installed by the hundreds of millio
i've now seen a number of proposals reaction to "the snowden
disclosures", seeking channel encryption for dns transactions. i have
some thoughts on the matter which are not in response to any specific
proposal, but rather, to the problem statement and the context of any
solution.
first, dns data i
13 matches
Mail list logo
