> On 15 Dec 2018, at 11:37 am, Daniel Kahn Gillmor
> wrote:
>
> On Fri 2018-12-14 22:58:09 +, Stephen Farrell wrote:
>
>> I'm probably exposing my lack of DNS-clue, but I wonder if it
>> is/isn't possible to embed a "like/want/offer privacy" signal
>> in the DNS protocol, rather than in
Hiya,
On 15/12/2018 00:37, Daniel Kahn Gillmor wrote:
> i think you're suggesting some sort of "starttls"-like mechanism --
> start a DNS connection to an authoritative server, and then the server
> lets you know "hey you might also want to try me in the future via
> private channels"
>
> is
On Fri 2018-12-14 22:58:09 +, Stephen Farrell wrote:
> I'm probably exposing my lack of DNS-clue, but I wonder if it
> is/isn't possible to embed a "like/want/offer privacy" signal
> in the DNS protocol, rather than in the data carried by the
> protocol? (Regardless of whether the latter
On Fri 2018-12-14 17:43:44 -0500, Paul Wouters wrote:
> We fixed that with tls-dnssec-chain :P
>
> I'll leave it up to others to wonder why and how this did not move
> forward, and is now going via ISE.
>
> Sorry for the side-track of this discussion.
This isn't sidetrack at all, it was one of
Hiya,
I'm probably exposing my lack of DNS-clue, but I wonder if it
is/isn't possible to embed a "like/want/offer privacy" signal
in the DNS protocol, rather than in the data carried by the
protocol? (Regardless of whether the latter might be done via
funny names or new/additional RRs.).
The
On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote:
> Am 11.12.18 um 06:38 schrieb Mukund Sivaraman:
>> There was some discussion in last night's meeting about encoding keys in
>> the DNS name of a nameserver, similar to DNSCurve. There are at least
>> some issues with it:
>> 1...4
>
> 5. Encoding
On Fri, 14 Dec 2018, Warren Kumari wrote:
One of the stated reasons for browsers not doing DANE / TLSA was having to wait
for the TLSA record to come
back before you can connect.
"Ah! Fine..", says I, "Just do these in parallel -- you will get back the TLSA
record at about the same
time as
On Fri, Dec 14, 2018 at 4:38 PM Jon Reed wrote:
>
>
> On Fri, 14 Dec 2018, Warren Kumari wrote:
>
> >
> >
> >
> > On the call, someone (Wes?) proposed an alternative such as
> records in the reverse zones. That would be a huge win for
> > us, since we have a small finite set of
On Fri, 14 Dec 2018, Warren Kumari wrote:
On the call, someone (Wes?) proposed an alternative such as records in
the reverse zones. That would be a huge win for
us, since we have a small finite set of nameserver IPs, and easily
control our reverse zones (as, I would
On Fri, Dec 14, 2018 at 12:43 PM Reed, Jon wrote:
> I'd like to start a thread about alternatives to encoding fingerprints in
> NS names. As I noted in the meeting (unless I'm significantly
> misunderstanding the proposal), this is a non-starter for large operators
> like us. It's not
On Dec 14, 2018, 12:29 PM -0800, Daniel Kahn Gillmor ,
wrote:
> On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote:
> > On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote:
> > > [And, no, we shouldn't go down the road of "privacy requires you disable
> > > the cache"]
> >
> > Would you
On Fri 2018-12-14 11:47:58 -0800, Christopher Wood wrote:
> On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote:
>> [And, no, we shouldn't go down the road of "privacy requires you disable
>> the cache"]
>
> Would you mind elaborating on this comment? As you observe, caches are
> harmful to
On Dec 14, 2018, 10:47 AM -0800, Wes Hardaker , wrote:
> Daniel Kahn Gillmor writes:
>
> > I have *not* done any analysis of the larger, less-corner-y cases to
> > see whether there's a strong argument for or against treating data
> > that came in under confidential cover differently once it's in
Daniel Kahn Gillmor writes:
> I have *not* done any analysis of the larger, less-corner-y cases to
> see whether there's a strong argument for or against treating data
> that came in under confidential cover differently once it's in the
> cache.
Technically, it's near impossible to completely
On Dec 14, 2018, at 10:12 AM, A. Schulze wrote:
>
> Am 11.12.18 um 06:38 schrieb Mukund Sivaraman:
>> There was some discussion in last night's meeting about encoding keys in
>> the DNS name of a nameserver, similar to DNSCurve. There are at least
>> some issues with it:
>> 1...4
>
> 5.
Hello,
Am 11.12.18 um 06:38 schrieb Mukund Sivaraman:
> There was some discussion in last night's meeting about encoding keys in
> the DNS name of a nameserver, similar to DNSCurve. There are at least
> some issues with it:
> 1...4
5. Encoding a key as DNS name of a nameserver makes key rotation
Hi,
I have just moved the DPRIVE WG phase 2 document from trac.ietf.org to
github. At the end of the virtual meeting, participants indicated that
a document on github with revisions (tracking) works very well in a
collaborative environment.
The document is in the github repo:
I'd like to start a thread about alternatives to encoding fingerprints in NS
names. As I noted in the meeting (unless I'm significantly misunderstanding
the proposal), this is a non-starter for large operators like us. It's not
feasible to get our customers to change every NS record in their
18 matches
Mail list logo
