On Sun, Jun 12, 2016 at 2:32 AM, Hugo Maxwell Connery
wrote:
> Hi,
>
> Please excuse my potentially uniformed comment, but
> I think that DANE and DNSSEC try to solve the autheniticity
> problem (i.e I am talking to a valid auth NS).
>
> The privacy discussion is about not
Shane Kerr wrote:
> I'm basically thinking that the next step is encrypting the
> resolver-to-authority session, right? Steps beyond that to increase
> privacy are much tricker, since they involve defeating traffic
> analysis, but it seems like encrypting resolver-to-authority is
> more-or-less
On Fri, Jun 10, 2016 at 12:57 PM, Robert Edmonds wrote:
> Paul Wouters wrote:
> > Publishing a TLSA record pinning just the public key seems more in line
> > for authoritative servers, for which you will always have a name, eg:
> >
> > _53._tcp.ns0.nohats.ca. IN TLSA 3 0 1
>
Paul Wouters wrote:
> Publishing a TLSA record pinning just the public key seems more in line
> for authoritative servers, for which you will always have a name, eg:
>
> _53._tcp.ns0.nohats.ca. IN TLSA 3 0 1
> 323e3584ba6f986cf09f27cf260cac42f5e5bd5e81df705fd33ac59717110389
_53 or _853 ?
--
On Mon, Jun 06, 2016 at 07:19:31AM -0400,
Tim Wicinski wrote
a message of 79 lines which said:
> We started the discussion a few meetings back that we are planning
> on recharting to address the resolver-to-authority session. We
> (warren and myself) wanted to wait until
Tim,
The standards work of securing the stub to resolver is done enough that
the focus on that has shifted to experimental implementations and
operational issues. Is it time to think about a re-charter to
explicitly list other work?
(Alternately this group could be shut down and one or more new