Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

nt agencies can't agree who is going to be the ultimate source of trust among them. So you can be absolutely certain they are never going to agree to it being ICANN. ​ ​ On Fri, Mar 30, 2018 at 12:06 PM, Tony Finch <d...@dotat.at> wrote: > Phillip Hallam-Baker <ph...@hallambaker.com&g

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

t might well be that mmm:al...@example.com would be better. Right now, I just do not know.​ But what I do know is that nobody else should be allowed to register mmm: URIs. On 1 Mar 2016, at 09:55, Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > > > The _service._protocol appro

Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

It is a hard problem and it is possible that there is actually no solution. All these systems consist of a chain or a graph of signed assertions. There is no intrinsic ground truth in PKI. All that you can do is to define a particular key or set of keys as producing the ground truth for your

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf wrote: > > Should we refuse to document such things because they’re not in well-known > open source codebases, or have otherwise not passed tests of goodness? > > It’s not a rhetorical question. Given that people are

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 2:45 PM, Paul Vixie wrote: > > i'm in general agreement with each of the assertions made at each layer of > quoting above, but i have two quibbles. > > first, they aren't reference implementations. not even BIND, which for > many years i called a

[DNSOP] Request for guidance on SIN

Strong Internet Names is a concept that I have been developing for about 4 years now. It is an extension of concepts that Brian LaMachia and team applied to the design of dotNET security with great success and I think it has value applied at the network level. The current draft can be found in

[DNSOP] Fwd: Delivery Status Notification (Failure)

]>: Client host rejected: No thanks. Last-Attempt-Date: Thu, 29 Mar 2018 08:43:32 -0700 (PDT) -- Forwarded message ------ From: Phillip Hallam-Baker <ph...@hallambaker.com> To: Jim Reid <j...@rfc1035.com> Cc: dnsop WG <dnsop@ietf.org> Bcc: Date: Thu, 29 Mar 201

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

A bit of context here, this is probably a document you have seen before and it is one of those cleanup documents that tends to languish. The reason I asked Dave to restart work on this draft is that I was reviewing another draft (SMTPRPT) that clearly needs to register a new prefix and indeed

Re: [DNSOP] New WG for document/protocol cleanup?

On Wed, Mar 28, 2018 at 1:12 PM, ​​ Jim Reid <j...@rfc1035.com> wrote: > > > > On 28 Mar 2018, at 18:02, Phillip Hallam-Baker <ph...@hallambaker.com> > wrote: > > ... long rant snipped ... > > Well that is how I plan to go forward at any rate. > > Go

Re: [DNSOP] Error handling in CAA

On Tue, Nov 21, 2017 at 3:54 PM, Viktor Dukhovni wrote: > On Mon, Nov 20, 2017 at 01:10:43PM +, Tony Finch wrote: > >> Viktor's message has lots of sound advice, though I have one correction: >> >> > This language really should have been much more clear. In

Re: [DNSOP] new DNS classes

On Thu, Jul 6, 2017 at 11:15 AM, John C Klensin <john-i...@jck.com> wrote: > > > --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker > <ph...@hallambaker.com> wrote: > > > There are changes to the DNS that are practical and those that > > are not. F

Re: [DNSOP] new DNS classes

There are changes to the DNS that are practical and those that are not. For better or worse, I can't see any way that teaching DNS to use new classes makes any sense at this point. The only point at which it would have made sense was when internationalization happened. But the path chosen makes

Re: [DNSOP] Updated NSEC5 protocol spec and paper

Shhh. don't confuse with facts. On Fri, Mar 10, 2017 at 1:30 PM, Frederico A C Neves wrote: > On Fri, Mar 10, 2017 at 01:15:42PM -0500, Shumon Huque wrote: > ... > > > > Apparently there are many folks in the community who think so, otherwise > > NSEC3 would not have been

Re: [DNSOP] Updated NSEC5 protocol spec and paper

On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends <r...@dnss.ec> wrote: > > > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker <ph...@hallambaker.com> > wrote: > > > > I suggest we first deploy NSEC0 which simply nulls out the whole > NSEC/NXT issue entirely. >

Re: [DNSOP] Updated NSEC5 protocol spec and paper

On Thu, Mar 9, 2017 at 4:05 PM, Roy Arends <r...@dnss.ec> wrote: > > > On 9 Mar 2017, at 20:58, Phillip Hallam-Baker <ph...@hallambaker.com> > wrote: > > > > I suggest we first deploy NSEC0 which simply nulls out the whole > NSEC/NXT issue entirely. >

Re: [DNSOP] Updated NSEC5 protocol spec and paper

The perfect is the enemy of the good. I suggest we first deploy NSEC0 which simply nulls out the whole NSEC/NXT issue entirely. At this point anyone who is deploying DNSSEC is helping the cause. Do not set membership requirements that exclude them. Node insertion is a security concern for some

Re: [DNSOP] Updated NSEC5 protocol spec and paper

There are two reasons for splitting out the VRF 1) It is a useful building block 2) The intersection between the people who really understand the VRF math and really understand DNS is very small I think most DNSOps folk will want to treat VRF as a black box and let the crypto folk put what they

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

On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews wrote: > > > Zero if it is done right. We can easily extend the DNS to say > "Fetch the additional record for the SRV records before answering" > if you have this EDNS option present or just have the server do it > without the option.

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

On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz <bem...@google.com> wrote: > On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker < > ph...@hallambaker.com> wrote: > >> I really don't like the proposal at all. The idea of beginning the TLS >> handshake in DNS is

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

I really don't like the proposal at all. The idea of beginning the TLS handshake in DNS is sound. But it is a completely new handshake and authentication layer. Right now we have a bit of a mess with service discovery. We have a solid proposal that makes sense written up as a standard and we have

Re: [DNSOP] Looking for IANA registry for --xn

'assignments' that are not 'registrations' doesn't mean that is right or should continue. On Thu, Oct 6, 2016 at 9:56 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 6 Oct 2016, at 18:09, Phillip Hallam-Baker wrote: > > On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis <j...@n

Re: [DNSOP] Looking for IANA registry for --xn

On Thu, Oct 6, 2016 at 5:13 PM, Jaap Akkerhuis wrote: > Robert Edmonds writes: > > > Donald Eastlake wrote: > > > Sure, you can consider the root zone to be the registry for TLDs but > the > > > point is the xn-- labels are recommended to be interpreted specially > at the

Re: [DNSOP] Looking for IANA registry for --xn

​​ On Thu, Oct 6, 2016 at 1:24 PM, wrote: > > >I have been looking for the IANA registry in which the IDNA prefix xn-- > is allocated and have not been able to find it. I can see the following > possibilities > > >1) There isn't such a registry. The allocation

[DNSOP] Looking for IANA registry for --xn

I have been looking for the IANA registry in which the IDNA prefix xn-- is allocated and have not been able to find it. I can see the following possibilities 1) There isn't such a registry. The allocation is purely ad hoc 2) There is a registry but none of the IDNA RFCs bother to list it as a

Re: [DNSOP] moving forward on special use names

There is actually a fifth type of name, escaped names. Right now, the only names we have of this type are SRV protocol tags, (_http._tcp.example.com) and internationalized names (xn—wev.com) I want to add a third set of escaped names, one that has similar functionality to .onion but does not leak

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

In response to the discussion of where the use of TXT records is discussed, see: https://tools.ietf.org/html/rfc6764 This in turn cites: https://tools.ietf.org/html/rfc6763#section-6 Which seems like the way to do these things. ___ DNSOP mailing

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On Tue, Mar 1, 2016 at 1:13 PM, John Levine wrote: >>So while SRV and NAPTR and the TXT records are stuck using the two >>level approach, there is also a clear need for a meta-discovery record >>that only uses the service prefix. > > Maybe. > >>Using SRV discovery you might use:

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On Tue, Mar 1, 2016 at 11:59 AM, Ray Bellis wrote: > > > On 01/03/2016 16:56, John Levine wrote: > >> If you take a look at that registry, it's a stroll down memory lane. >> You'll find NVP-II from RFC 741 in 1977, PUP and XNS-IDP from Xerox in >> 1980, and other great hits

Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

On Mon, Feb 29, 2016 at 5:32 PM, Ray Bellis wrote: > > > On 29/02/2016 22:27, John R Levine wrote: > >> The existing port and service registry already has all of the _service >> names, and is updated as people invent new services. What's the benefit >> of duplicating it rather

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

If you want to do this... Why not just do Web Sockets and run plain old DNS over TCP. Its not going to be tremendously fast but it is the shortest distance between two points and there would be almost no new code needed. ___ DNSOP mailing list

Re: [DNSOP] [saag] code points for brainpool curves for DNSSEC

Objections so far * The approach is dated (not fast prime rigid) and the randomness isn't established to be rigid. * DNSSEC requires a single algorithm for interop * The code points are 8 bit and thus scarce * We should do Curdle first. I am opposed to Brainpool for all the above and in

Re: [DNSOP] Spartacus and new record types

Can we change the name, please? Spartacus Club was the name of the pedophile rapist organization at the center of the on ongoing UK criminal enquiry involving 8 MPs and three police forces. There is also an international dimension. There is a significant probability it is going to become a PR

Re: [DNSOP] Draft on censorship, and DNS

If you want to do anything useful in counter-censorship then you have to think of using steganography So don't call it DNS and don't put the parts of the plan designed for counter censorship prominently in the draft Port 443 is loaded with censorship issues. If you want to get your packets

Re: [DNSOP] Possible slower response with minimization

On Sat, Oct 25, 2014 at 2:08 PM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer bortzme...@nic.fr Saturday, October 25, 2014 9:05 AM On Tue, Oct 21, 2014 at 02:14:49PM +0900, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp mo...@necom830.hpcl.titech.ac.jp wrote a message of

Re: [DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-spartacus-system-00.txt

I understand what is being attempted here and I am a big fan of JSON. But I don't see the value in representing DNS information in an alternative syntax. If we are going to change the discovery interface I would want to go a step up in abstraction and present the type of interface the

Re: [DNSOP] [dns-privacy] Qname minimization IPR

The claims are broad, not specific to one field of use. But there isn't a patent yet and they may have been waiting to file after grant. It is possible for someone other than the IPR holder to file but best if its the IPR holder. The mere existence of a patent does not necessarily mean an

Re: [DNSOP] [dns-privacy] Qname minimization IPR

Paul, It is a VeriSign patent, its just being shown on the Google patent serach engine On Sat, Oct 25, 2014 at 1:53 PM, Paul Vixie p...@redbarn.org wrote: Stephane Bortzmeyer bortzme...@nic.fr Saturday, October 25, 2014 2:24 AM [Copy to dnsop since the qname minimisation draft is now a

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

On Tue, Oct 7, 2014 at 12:04 AM, Tim Wicinski tjw.i...@gmail.com wrote: Dear DNSOP WG, After discussions about the landing spot of this document, DNSOP vs the newer DNS Privacy WG, it was realized the updated DNSOP charter specifically had work like this in mind. This starts a Call for

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

as is suggested it will soon collapse of its own accord. I rather suspect however that the fears are unfounded. On Mon, Oct 20, 2014 at 2:32 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: On Tue, Oct 7, 2014 at 12:04 AM, Tim Wicinski tjw.i...@gmail.com wrote: Dear DNSOP WG, After

Re: [DNSOP] Possible slower response with minimization

If we are going there, I would want to know how common the configurations are. There is zero additional overhead for www.example.com Outside this list how common are hierarchies more than 4 levels deep in practice? This isn't a functionality issue, it's purely performance. So I suggest a 5%

Re: [DNSOP] [Int-area] various approaches to dns channel secrecy

On Mon, Jul 7, 2014 at 12:42 PM, Paul Vixie p...@redbarn.org wrote: there are two kinds of channel in dns queries. (i'm not going to account for updates or zone transfers here.) one channel is from the stub to the recursive. it's pointless to add secrecy to that unless a stub wants to use a

Re: [DNSOP] various approaches to dns channel secrecy

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

Re: [DNSOP] [perpass] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

On Fri, Jun 6, 2014 at 8:38 PM, Dan Wing dw...@cisco.com wrote: On Jun 3, 2014, at 10:26 AM, Phillip Hallam-Baker i...@hallambaker.com wrote: One of the biggest mistakes in TLS and DTLS is that they are built around the assumption that there is a public key handshake at the start of each

Re: [DNSOP] [perpass] draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

On Tue, May 20, 2014 at 12:06 AM, joel jaeggli joe...@bogus.com wrote: On 5/19/14, 1:09 PM, John Heidemann wrote: Folks, I believe consensus was that dnsop needs a problem statement about DNS privacy before we explore possible solutions. If I were to speculate on the basis of the dicussion

Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)

On Fri, Apr 25, 2014 at 10:46 AM, Ralf Weber d...@fl1ger.de wrote: Moin! On 25 Apr 2014, at 16:22, Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote: Any specific reason for the firewalls to permit TCP/53 other than for zone transfer ? Wat? Because it is defined in the RFC. RFC1035 may

Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)

On Thu, Apr 24, 2014 at 9:52 AM, Ralf Weber d...@fl1ger.de wrote: Moin! On 24.04.2014, at 15:28, Tirumaleswar Reddy (tireddy) tire...@cisco.com wrote: -Original Message- From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of Nicholas Weaver Sent: Thursday, April

Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)

On Thu, Apr 24, 2014 at 11:19 AM, Joe Abley jab...@hopcount.ca wrote: On 24 Apr 2014, at 10:53, Phillip Hallam-Baker hal...@gmail.com wrote: If you want to use TLS with DNS then use port 443. One of the effects of firewalls is that we now only have three ports for all protocols: Port 80/UDP

Re: [DNSOP] DNS over DTLS (DNSoD)

I agree that DTLS does not solve any problems for DNS. The basic problem is that DTLS is still based around the notion of a session where the server stores per connection state. So you might as well use TLS for this application. But TLS is not the only option available. Or rather using TLS to

Re: [DNSOP] [dns-privacy] DNS over DTLS (DNSoD)

On Wed, Apr 23, 2014 at 7:11 PM, Joe Abley jab...@hopcount.ca wrote: On 23 Apr 2014, at 18:32, Phillip Hallam-Baker hal...@gmail.com wrote: We can't run over port 53 (trust me, I tried). You have doubts about the approach described in draft-hzhwm-start-tls-for-dns-00? Those would

Re: [DNSOP] DNSng-ish (was Re: key lengths for DNSSEC)

On Wed, Apr 2, 2014 at 11:24 PM, Phillip Hallam-Baker hal...@gmail.comwrote: On Wed, Apr 2, 2014 at 10:48 PM, Andrew Sullivan a...@anvilwalrusden.comwrote: On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote: 1) Client - Resolver Changing 1 is the easiest and also

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tue, Apr 1, 2014 at 10:48 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson o...@ogud.com wrote: Why not go to a good ECC instead ? (not sure which one, but not P256 or P384) Why not P256 or P384? They are the most-studied curves. Some of the

Re: [DNSOP] key lengths for DNSSEC

On Wed, Apr 2, 2014 at 11:19 AM,  Roy Arends r...@dnss.ec wrote: On 02 Apr 2014, at 15:19, Jim Reid j...@rfc1035.com wrote: There's been a lot of noise and very little signal in the recent discussion. It would be helpful if there was real data on this topic. Is an RSA key of N bits too

Re: [DNSOP] DNSng-ish (was Re: key lengths for DNSSEC)

On Wed, Apr 2, 2014 at 10:48 PM, Andrew Sullivan a...@anvilwalrusden.comwrote: On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote: 1) Client - Resolver Changing 1 is the easiest and also the part that is most in need. From where I sit, that project appears to reduce

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Tue, Apr 1, 2014 at 9:05 AM, Nicholas Weaver nwea...@icsi.berkeley.eduwrote: On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson o...@ogud.com wrote: Doing these big jumps is the wrong thing to do, increasing the key size increases three things: time to generate signatures

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Fri, Mar 28, 2014 at 9:01 AM, Tony Finch d...@dotat.at wrote: Paul Wouters p...@nohats.ca wrote: On Thu, 27 Mar 2014, Nicholas Weaver wrote: For an attacker, the root ZSK is not 1 month validity, since an attacker who's in a position to take advantage of such a ZSK compromise is

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Fri, Mar 28, 2014 at 9:50 AM, Joe Abley jab...@hopcount.ca wrote: On 28 Mar 2014, at 9:06, Phillip Hallam-Baker hal...@gmail.com wrote: Therefore ICANN needs to sign the root zone with 2048 before we consider it signed. End of story. Small point of clarity: the only key that ICANN

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Fri, Mar 28, 2014 at 11:28 AM, Thierry Moreau thierry.mor...@connotech.com wrote: On 03/27/14 13:56, Nicholas Weaver wrote: So why the hell do the real operators of DNSSEC that matters, notably com and ., use 1024b RSA keys? And don't give me that key-roll BS: Give me an out of date

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Fri, Mar 28, 2014 at 2:29 PM, Joe Abley jab...@hopcount.ca wrote: On 28 Mar 2014, at 10:26, Phillip Hallam-Baker hal...@gmail.com wrote: VeriSign is acting on ICANN's instructions. I think actually that Verisign is acting on NTIA's instructions under the cooperative agreement. But my

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Thu, Mar 27, 2014 at 10:52 AM, Paul Hoffman paul.hoff...@vpnc.orgwrote: On Mar 27, 2014, at 6:56 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: and 1024B is estimated at only a thousand times harder. Does that estimate include a prediction that the method to factor RSA will

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

On Thu, Mar 27, 2014 at 11:05 AM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: Frankly speaking, since the root uses NSEC rather than NSEC3, IMO it should be 4096b for both the KSK and ZSK. But I'd be happy with 2048b. Using 1024b is a recipe to ensure that DNSSEC is not taken

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

Nope. ALL 1024 bit certs of every description are covered including end-entity. On Thu, Mar 27, 2014 at 3:35 PM, Paul Wouters p...@nohats.ca wrote: On Thu, 27 Mar 2014, Nicholas Weaver wrote: Because the browsers have already decided killing of 1024b CAs is a good idea, and they could

Re: [DNSOP] on the subject of dnse

On Fri, Mar 21, 2014 at 10:59 AM, Paul Vixie p...@redbarn.org wrote: Phillip Hallam-Baker wrote: This was the use case that originally drove the development of OmniBroker. If we do DNS Encryption right it is going to be very easy for end users to chose their DNS provider and very hard

Re: [DNSOP] on the subject of dnse

This was the use case that originally drove the development of OmniBroker. If we do DNS Encryption right it is going to be very easy for end users to chose their DNS provider and very hard for the authorities to block them. Security is a balance. Going through 8.8.8.8 rather than direct means

Re: [DNSOP] An approach to DNS privacy

On Tue, Mar 11, 2014 at 11:26 AM, Stephane Bortzmeyer bortzme...@nic.frwrote: On Sun, Mar 09, 2014 at 11:28:18AM +0100, Florian Weimer f...@deneb.enyo.de wrote a message of 20 lines which said: In most jurisdictions, home networks use recursive resolvers whose operators are required by

Re: [DNSOP] my dnse vision

On Mon, Mar 10, 2014 at 1:11 PM, Tony Finch d...@dotat.at wrote: Stephane Bortzmeyer bortzme...@nic.fr wrote: The only place where server authentication could be useful is between a stub and the first resolver. I don't think it is as simple as that. There are good reasons for using a

Re: [DNSOP] my dnse vision

On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch d...@dotat.at wrote: Phillip Hallam-Baker hal...@gmail.com wrote: First off it means that if the recursive is being used in discovery-only mode it can simply pass data from the authoritative to the stub without checking the DNSSEC chain

Re: [DNSOP] An approach to DNS privacy

On Sun, Mar 9, 2014 at 6:28 AM, Florian Weimer f...@deneb.enyo.de wrote: * Phillip Hallam-Baker: For a heavily trafficked resolver, the resolver-authoritative interaction can be addressed with caching and by pre-fetching the bulk of the requests. But this approach does not work so well

Re: [DNSOP] An approach to DNS privacy

On Sun, Mar 9, 2014 at 10:26 AM, Florian Weimer f...@deneb.enyo.de wrote: * Phillip Hallam-Baker: But first, cite actual legal authority because I don't believe your interpretation of the law is remotely correct. § 8 Abs. 3 TKÜV: | Wenn der Verpflichtete die ihm zur Übermittlung

[DNSOP] DNS Privacy Use Cases, Requirements and Constraints.

I think we need some use cases to ground discussion. These are the use cases I have been considering: A) Alice, surfing the Web from her own machine at home does not want her Web browsing history to be revealed to other parties. A1) Note here that Alice might also use the same machine to access

[DNSOP] An approach to DNS privacy

In my view we need to consider different privacy issues in the stub-resolver and resolver-authoritative interactions. In the stub-resolver interaction the primary objective is to encrypt requests and responses without impacting latency. For a heavily trafficked resolver, the

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

On Thu, Sep 12, 2013 at 1:21 PM, Theodore Ts'o ty...@mit.edu wrote: On Thu, Sep 12, 2013 at 04:46:01PM +, Ted Lemon wrote: The model for this sort of validation is really not on a per-client basis, but rather depends on routine cross-validation by various DNSSEC operators throughout

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

On Thu, Sep 12, 2013 at 2:07 PM, Ted Lemon ted.le...@nominum.com wrote: On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com wrote: In order to subvert or redirect a delegation, the TLD operator (or registrar) would need to change the DNS server name/IP, and replace the DS

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

On Wed, Sep 11, 2013 at 12:08 PM, Paul Wouters p...@nohats.ca wrote: On Wed, 11 Sep 2013, Joe Abley wrote: 1. We only need to know the current time to an accuracy of 1 hour. [RRSIG expiration times are specified with a granularity of a second, right? I appreciate that most people are

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

On Wed, Sep 11, 2013 at 12:26 PM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote: On Sep 11, 2013, at 9:18 AM, Phillip Hallam-Baker hal...@gmail.com wrote: The DNS is the naming infrastructure of the Internet. While it is in theory possible to use the DNS to advertise very rapid changes

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

OK lets consider the trust requirements here. 1. We only need to know the current time to an accuracy of 1 hour. 2. The current time is a matter of convention rather than a natural property. It is therefore impossible to determine the time without reference to at least one trusted party. 2a) A

Re: [DNSOP] [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00)

On Tue, Feb 1, 2011 at 2:30 AM, Paul Wouters p...@xelerance.com wrote: On Tue, 1 Feb 2011, Brian Dickson wrote: This may be good enough for DNSSEC purposes. At least to then do ntp and and see that it matches our rough expectation. Though in all, if the attacker is your controlling

Re: [DNSOP] [dnsext] bootstrapping using a quorum of witnesses

-old validator to successfully and securely bootstrap. Think of a fifteen-year-old root hints file, which still after all that time contains eight valid root server IP addresses: enough to bootstrap. Phillip Hallam-Baker and John Bashinski have recently hinted at something like this, though I

Re: [DNSOP] [dnsext] draft-jabley-dnsop-validator-bootstrap-00

On Mon, Jan 31, 2011 at 5:14 PM, Joe Abley jab...@hopcount.ca wrote: Either way, it's a local trust anchor... and I don't see why X.509 keys are any less compromisable than DNS keys... The difference is that X.509 keys, as deployed by CAs, have expected lifetimes measured in decades.

Re: [DNSOP] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

David, When I originally looked at this scheme I thought that it was intended to reduce the attack surface in the manner you describe. Clearly if you have two controls, A and B and BOTH must be compromised, the system is less likely to be compromised than either A or B. But the design approach

Re: [DNSOP] Cert Enumeration and Key Assurance With DNSSEC

-archive/web/keyassure/ 2. https://www.ietf.org/mailman/listinfo/keyassure On 1.10.2010 17:29, Phillip Hallam-Baker wrote: For the past month I have been participating in the KEYASSURE discussions. One aspect of those discussions that was not made clear in the original notice sent out

Re: [DNSOP] [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Lots of statements concerning how CAs work For the past five years, CA certificates have been divided into Domain Validated and Extended Validated. As some of you know, I instigated the process that led to the creation of EV certs because I was very worried about the low quality of many DV

[DNSOP] Cert Enumeration and Key Assurance With DNSSEC

For the past month I have been participating in the KEYASSURE discussions. One aspect of those discussions that was not made clear in the original notice sent out is that the group is not only considering key assurance, the proposals made are also intended to have security policy semantics. This

Re: [DNSOP] [pkix] Cert Enumeration and Key Assurance With DNSSEC

On Fri, Oct 1, 2010 at 6:05 PM, Matt McCutchen m...@mattmccutchen.netwrote: On Fri, 2010-10-01 at 11:29 -0400, Phillip Hallam-Baker wrote: In particular I am very concerned about the particular approach being taken to security policy. What the proposers are attempting to do is to create

Re: [DNSOP] [TLS] [78attendees] [dnsext] Re: t...@dnssec bar BoF

If so, any chance of turning on the audio (apols for not making it in person, but I only started work for my new employer (Comodo Inc.) 4 hours ago). On Mon, Jul 26, 2010 at 12:58 PM, Sean Turner turn...@ieca.com wrote: Ondřej Surý wrote: On 26.7.2010 17:46, Paul Hoffman wrote: At 4:25 PM