Subject: [dns-privacy] Preliminary Minutes Posted

From: Tim WIcinski <[email-masked]>
Date: Sat, 25 Jul 2015 10:07:35 +0200

All,

I posted the preliminary minutes for the dprive meeting. They can be 
found here:

https://www.ietf.org/proceedings/93/minutes/minutes-93-dprive

Thanks to Stephane for note taking at the last minute, even with flaky 
wireless.

To summarize the chairs actions, the first ones were around the 
start-tls for DNS draft presented.

On the question of
	 "Do without a "start TLS"-like approach, just port-based"

      Hum for:
          Drop negotiation, only (new) port-based: strong signal
          Bad idea: silence
          I don't know, I don't have enough info
	(discussion on what data is necessary: we have none): strong signal

------

On the topic of the "Early Allocation of a port"
      Hum:
          early allocation of a port:
               yes: strong signal  <-------
               no: silence

-----

During the presentation on the evaluation document, it became obvious 
that many people had not read the draft.
The question was raised to see
	"Who finds this useful and should be adopted"

      Hum:
          useful and should be adopted: more than 5 :-)

	("May be they watched the movie and did not read the book")

------

The rough consensus in the room was to
	request an early port allocation request; and to
	start with a new port directly.

The chairs will need to go back on think on the evaluation document.

thanks

---

From: Paul Wouters <[email-masked]>
Date: Sat, 25 Jul 2015 06:37:23 -0400 (EDT)

> 	 start with a new port directly.

I thought that at least one of these had a third hum option that was not
insignificant (although not as strong as the actions listed here)

I am still very much concerned about both using a new port and concerned
using a starttls option - mostly focused on the stub to (external)
recursive.

For one, I really don't want us to hurt port 53's current freedom, and
fear if we open that up to basically an encrypted stream of unknown but
presumed DNS traffic that we will see an increase in port 53 manipulation
and filtering. (middleware boxes also basically killed IKE port 500,
and we had to switch to port 4500 for most of it to the point where we
could now almost obsolete port 500)

On the other side, I really want encryption to be part of the standard
so it becomes harder to filter out my queries just because these are
encrypted. Using a separate port could mean an instant death sentence
for such deployment.

That said, I guess I'm leaning towards a new port and not mucking with
the current port 53.

Paul