Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread Adrien de Croy
presuming that the client will have to look up the hostname of the destination at some stage, and presuming that a passive network attacker may see DNS requests as well as TCP connections, how does this help? Or does this require the use of DNS over TLS. And also there will be leakage of

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread Warren Kumari
On Tue, Feb 14, 2017 at 5:14 PM, John Levine wrote: > In article you write: >>This seems like a bandaid to TLS that I think just needs >>fixing in the TLS protocol. > > For once I agree with Paul. > > If you're going to change

Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2017-02-16

2017-02-14 Thread Paul Hoffman
On 3 Feb 2017, at 7:40, IESG Secretary wrote: Webex details will follow Hopefully before the meeting. Setting up WebEx can take at least two tries for any new meeting. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread John Levine
In article <20170214203924.5c4v6l5b3bjip...@mycre.ws> you write: > We could encode this information in a TXT record, but that would > violate the intended purpose of TXT records: to convey information to > human readers. > >I'm not sure if it's true that TXT records are intended only for

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread John Levine
In article you write: >This seems like a bandaid to TLS that I think just needs >fixing in the TLS protocol. For once I agree with Paul. If you're going to change the client anyway, why is this better than a modified handshake that sets up the

Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

2017-02-14 Thread Ralph Droms
We've extracted issues from the reviews of draft-ietf-dnsop-sutld-ps posted to the list so far, and entered them into the GitHub repo: https://github.com/Abhayakara/draft-tldr-sutld-ps We're tracking discussion and resolution for issues

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread Robert Edmonds
Hi, Ben: In your draft, the reason for not using TXT is given as: 2.1.3. Using TXT We could encode this information in a TXT record, but that would violate the intended purpose of TXT records: to convey information to human readers. I'm not sure if it's true that TXT records are

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread Wessels, Duane
> On Feb 14, 2017, at 10:02 AM, Ben Schwartz wrote: > > Hi dnsop, > > I've written a draft proposal to improve the privacy of TLS connections, by > letting servers use the DNS to tell clients what SNI to send. > Hi Ben, >_443._tcp.subdomain1.example.com. IN SNI

Re: [DNSOP] draft-ietf-dnsop-terminology-bis and "recursive resolver"

2017-02-14 Thread 神明達哉
At Thu, 19 Jan 2017 13:51:33 -0500, Ted Lemon wrote: > I'm updating a document for another working group, and Ralph Droms > in his last call comments on that document asked me to use > "recursive resolver" instead of "caching name server", referencing >

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread Paul Wouters
On Tue, 14 Feb 2017, Ben Schwartz wrote: I've written a draft proposal to improve the privacy of TLS connections, by letting servers use the DNS to tell clients what SNI to send. https://tools.ietf.org/html/draft-schwartz-dns-sni-01 I've incorporated some helpful feedback [1] from the TLS WG,

Re: [DNSOP] Proposal for a new record type: SNI

2017-02-14 Thread Robert Edmonds
Ben Schwartz wrote: > Hi dnsop, > > I've written a draft proposal to improve the privacy of TLS connections, by > letting servers use the DNS to tell clients what SNI to send. > > https://tools.ietf.org/html/draft-schwartz-dns-sni-01 > > I've incorporated some helpful feedback [1] from the TLS

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

2017-02-14 Thread Tony Finch
Brian Dickson wrote: > > Would it be feasible to limit the behavior of "refuse-any" returning > "partial" UDP responses, to situations where EDNS with DO=1 is used? No, this is a defence mechanism, so it needs to cope with uncooperative clients. > Older resolvers