* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dprive Status Pages

DNS PRIVate Exchange (Active WG)
Int Area: Éric Vyncke, Erik Kline | 2014-Oct-17 —  

IETF-111 dprive minutes


minutes-111-dprive-00 minute

          # DNS Privacy Exchange (DPRIVE) WG
          ## IETF111
          * Date: 29 July 2021
          * Time: 1200-1300/1330-1430 PDT (1900-2000/2030-2130 UTC)
          * MeetEcho:
          * Minutes: https://codimd.ietf.org/notes-ietf-111-dprive
          * Jabber:  dprive@jabber.ietf.org
          ### DataTracker
          * https://datatracker.ietf.org/group/dprive/documents/
          ### Chairs
          * Tim Wicinski
          * Brian Haberman
          ### Responsible Area Director
          * Eric Vyncke
          ## Agenda
          ### Administrivia
          * Agenda Updates, etc,  10 min
          * NOTE WELL : https://www.ietf.org/about/note-well.html
          Minutes: Shane Kerr (apologies for inaccuracies)
          Minutes: Ginny Spicer
          Alexander Mayrhofer mentions that the revised requirement draft will
          be dropped.
          Chairs: Do presentations in reverse order.
          ### Current Working Group Business
          *   [Specification of DNS over Dedicated QUIC
              - Requester: Dickinson
              - Time Requested:  20m
              - Chairs Action: Ping working group to ask for review of the state
              of the document.
          Martin Thomson (MT): Is a single ALPN used?
          Sara Dickinson (SD): Yes.
          Alex Mayrhofer (AM): Like change to general purpose
          protocol. Server-initiated transaction out of scope; might need a
          clarification that DNS NOTIFY is not a server-initiated transaction. Was
          a source of confusion.
          SD: We can add text for that.
          Brian Haberman (BH): What do you think the status of the doc is?
          SD: We're pretty with how the doc. looks, and have some other feedback. We
          want an initial round of review, and if mostly minor would be look to
          move to WGLC at that time.
          Shane Kerr (SK): XoQ transfers in this draft. It seems different enough
          to potentially merit its own draft.
          SD: 50/50. Is there anything that would be ambiguous to an implementer
          that would cause problems? This will take more looking at.
          Paul Hoffman (PH): Making the XFR part of the draft into its own document
          may do more harm than good.
          *   [Recursive to Authoritative DNS with Unauthenticated
              - Requester: Hoffman
              - Time Requested:  30m
              - Chairs Action: Kick off a discussion to try and resolve these
          SD: Would be nice to generalize this to all encrypted transport, with
          the level of interest in DoQ.
          PH: Agree.
          Brian Dickson (BD): Will find more cycles on this and related things
          for parental side.
          PH: Have removed all discussion of parental side in -03 document. Had
          mentioned it in -02 side, but because of questions that will come up
          later in the meeting we removed it.
          Geoff Huston (GH): Put in a request to say this document should be
          completed without waiting on the full work (authentication). Ship it. Now.
          Paul Wouters (PW): I will say the exact reverse. Authentication is
          relatively straightforward these days. Should be able to figure out
          what to use. Skip this part, so you don't have to worry about being
          opportunistic or failing completely.
          PH: It's clear that you're wrong about "it will be easy to do". Look at
          the mailing list for the past 6 months.
          Watson Ladd (WL): I'm a little confused because of lack of knowledge of
          DNS. Signal is entirely dependent on resolving name server's name. What
          is unauthenticated here? We're not using web PKI? Or...
          PH: I think that question is for the next group of people, not this
          one. We're saying, "go through TLS, if the authentication fails, keep
          going". Does that make sense?
          WL: Why _not_ require X.509 authentication? You've got an identity for
          the record that you expect to connect to? Web PKI, or GAIN (?)... you
          have a DNS name which both of these are based on.
          PH: It would be hard to answer the question without repeating things
          that have been said on the list. Two use cases: 1) never want to fail,
          but do want encryption, OR 2) you really want really good privacy.
          Benjamin Schwartz (BS): Draft changed since last looked at it. Think
          we should have a draft for opportunistic, but now I don't think so. I
          think the design for authenticated is incompatible with this draft. ADoX
          implementation will fail connecting to this draft.
          PH: That is on the assumption that we are using web PKI instead of DANE?
          BS: No.
          PH: We would have to change the use case. Might be a 3rd use case or an
          unauthenticated use case.
          Puneet Sood (PS): Google Public DNS is reviewing what we can do in terms
          of opportunistic name servers. For high-volume connections, being able to
          do some amount of unauthenticated encryption prevents passive snooping
          on queries. Looking for servers to test this out. Doing test with other
          providers, including Facebook.
          Eric Rescorla (Ekr): (speaking at 2.5 ekr...) You can stand up an
          authoritative with no valid credentials, but no way to prevent a
          man-in-the-middle attack. What ADoX says, is once you get authenticated
          then you can use that. At least one other point, where we don't describe
          how authentication is discovered, but if you don't have authentication
          then you... fall back? If signal is via SVCB then the semantics have to
          be the same (between both drafts).
          PH: You said that a resolver goes to an authoritative server, get
          through TLS, and try to authenticate and it fails. And you said,
          "and maybe they start over". That was a "maybe". What would you say is
          the correct thing? We're saying, move forward anyway. Are you saying,
          "be like TLS and stop"?
          ekr: There are a couple of options. How do you discover this case? It's
          not clear to me why it makes sense to have an SVCB that says "do TLS"
          but we have an invalid cert. That would be forward compatible with SVCB
          in the parent. À la SSH, TOFU into something compatible, would still
          allow you to have some probing case. (accelerating to 4 ekr...) I'm not
          saying this is great but ...
          PH: Almost think that for the unauthenticated use case, don't look for
          SVCB, just probe.
          erk: Would allow bootstrap up.
          Robert Evans (RE): Start in a system where parents cannot convey the
          authentication signal securely.
          PH: Sounds good thanks.
          Viktor Dukhovni (VD): Back in [RFC
          7435](https://datatracker.ietf.org/doc/html/rfc7435) opportunistic with
          downgrade resistance. In SMTP specs for opportunistic DANE, if parameters
          are unsupported but TLS record found, use TLS but unauthenticated. Can
          repeat here... deliberately unusuable parameters (selector 3 for example,
          which is undefined). Can't use TLSA for authentication, but use TLS.
          PH: 10's of millions of servers doing DANE via SMTP, so this is not a
          new experiment. Widely used today (2.6 million).
          BD: Weak signal that should be trusted is, "is the name of the name server
          in a signed zone?". If it is, then expect or look for a TLSA record. If
          not, do opportunistic. If so, use TLS and hard fail if it doesn't work.
          PH: I think that' s quite a strong signal, and a good idea.
          BD: If there is a need for TLS, the TLSA supports a requirement for web
          PKI. Scalable and validatable.
          PH: Please write that up and send it to the list.
          BD: Sure.
          Daniel Gillmor (dkg): We've been around this merry-go-round before,
          not just in DNS, but also in things like SMTP. We have to think about
          two cases. Respective of the recursive resolver, and the deployer of
          the authoritative name servers. Deploy at risk of getting zone locked
          out if you screw up? Always a risk of screwing up, for a range of
          reasons. With SMTP (with the MTA-STS mechanism), we said, "an operator
          wants to be able to ask for reports on failure, not automatically take
          the zone out". That's the kind of thing we need for deployment and
          for authoritative operators to take this up. Also have to consider the
          in-bailiwick question. At some point there's a loop, unless _somebody_
          has an in-bailiwick server. So we need to be thinking about that for
          the signaling part as well.
          Christian Huitema (CH): I am look at this from an implementor PoV, I'm
          going to use a stack, and those stacks require in practice that I use a
          server name, and that the server name matches the certificate. I'd like
          to be clear about what server name do I use, and how do I find it?
          PH: We have talked about this but can make it clearer in the draft. If
          using a stack that will fail when authentication does, then that's
          your choice.
          BH: Action will be taken and we will consider new use cases and additions
          to current use case.
          ### New Working Group Business
          *   [Signaling Authoritative DNS
              - Requester: Rescorla
              - Time Requested: 20m
              - Chairs Action:
          PH: What is the problem?
          EKR: problem to be solved is signalling authentication. Want to go to
          example.com, .com tells me stuff that says example will be encrypted
          Paul Wouters (PW): Clarification: Do you think if SCVB in the parent
          wouldn't work is the rest still useful?
          EKR: I don't think matter of simply in-bailwick, but also protecting
          it. Absent DNSSEC parent doesn't say encrypt get forced down, Even out
          of baliwick no privacy. Universal DNSSEC yes, otherwise need parent.
          PW: I think you're wrong, if I have resolved ns1.dreamhost.com for one
          thing, and then resolve another child of it I can still connect securely?
          EKR: How?
          PW: assume already fetched ns1.dreamhost.com earlier. Leaked when looking
          for dreamhost.com, who cares.
          EKR: if client cold won't happpen. Less value than parental
          BD: The in-bailwick case, where zone is being served in the zone itself,
          that will never have privacy modulo some serious upgrades that will
          take decades. If we ignore that case, then the real issue is that when
          you're looking in .com for a name server for example.com, and it gives
          you a name server in ns1.example.net, how do you validate the glue
          data for ns1.example.net? Currently that is not possible. These are not
          signed. Will be tackled once solved making query to ns1.example.net for
          something DNSSEC-signed whether TLSA or else to query ns1.example.net
          for example.com is the piece with TLS, solvable without parent
          EKR: I think this is what Paul and I are saying , you are assuming that
          ns1.example.net is signed, and I am not.
          BD: We can make that a requirement. If we don't do that then we need
          SVCB at the parent, and I don't think that's viable.
          VD: Skeptical of parent-signed signaling. We have not discussed putting
          signaling not in forward name space, but in the unavoidably leaked .arpa
          zone. This does not leak even in the in-bailiwick case.
          EKR: If a number of people feel that way then adopting this draft is
          Peter van Dijk (PvD): Paul Wouters said that you can reuse cached
          information, but an attacker on path could change information because
          it is not DNSSEC authenticated. Victor's recommendation has the same
          problem, glue data is unauthenticated.
          EKR: I assume connection to parent is encrypted.
          PvD: If connection to parent is encrypted, then yes. But I have been
          assuming that .COM will not go along for a while.
          EKR: The security model is not to usurp TLS design. Any unencrypted links
          break down. TLDs will have to be encrypted or this won't work (but root
          does not have to be, because the clients can memorize this somehow).
          PvD: root is uninteresting, but expecting TLDs to encrypt is a big ask.
          PH: Scott Hollenbeck talked at last IETF, saying Verisign will be very
          conservative and take a long time. If you look at random NS records,
          the vast majority end in .COM or .NET. Victor's suggestion about
          reverse... deployment of DNSSEC sucks in forward tree, and is even worse
          in reverse tree.
          EKR: I was unclear about that. I have heard a number of times that they
          don't think TLDs won't do this, but if that's true then we should abandon
          this entire project, because protecting ns.example.com vs. foo.example.com
          then the benefits are _very_ marginal.
          dkg: I agree that if none of them are willing to do it we should abandon
          it, but even if _one_ adopts it in the relatively short term then it's
          worth doing, because it becomes a differentiator.
          Name servers can have different names, and we can't inflict if one of
          the name servers fail then all of them fail.
          *   [New record types in the parent
              - Requester: Wouters
              - Time Requested: 30m
              - Chairs Action: Facilitate WG consensus
          WL: This has me very sad about the prospect of deploying this. We
          shouldn't have the expectation that TLDs will change things.
          Warren Kumari (WK): Name server name encodes the existence of TLS,
          it's not the key.
          PW: It either has a key or some sort of identifier that cryptographically
          binds something. It points to something that has to point to something
          WK: Currently true with name server names.
          PW: But they never hard-failed before. This could be problematic. You
          are right - it is a better mechanism than storing the public key there,
          but it's still problematic.
          WK: I guess once you have turned on then you can't stop, but before then
          it's fine.
          ekr: Making a pretty strong case that whatever we define now we will be
          living with for a very long time. To summarize, you think that we should
          put this information in a DS records?
          PW: It's one proposal that I think is worth exploring. I think that
          you can get a DS record at the parent without you having to deploy
          DNSSEC. Most TLDs run DNSSEC, and the child zone does not need to.
          Ekr: So , I think the props of this signal , whatever it is have to be
          easily proped
          Only apply to this child, not all children with the same noame
          You want third property
          Being secure in the way you describe [on slide 6]
          If I go to .COM and it lies to set up an attack, but it already knows
          that I'm going to example.com
          I don't care between DS and SVCB
          VK: To ekr's point, I think Paul was assuming further labels in the domain
          name that you may not want to expose to .COM. DS indeed is far more viable
          than SVCB, provided we don't want to encode keying information. That's
          when we suddenly have the "cannot change" scenario. Minimal signaling, to
          find relevant key material go elsewhere. So, "try and find TLSA records"
          would be the simplest model. DS to signal desireablity of TLSA lookups.
          PW: If the SVCB content is pointing to the FQDN for a name server,
          then that could be an option too.
          VK: In principle yes, I'm sceptical if this is a place where you can
          rely on WebPKI to work.
          PW: We have both the options, and may the strongest one wins (or
          both). Lets not exclude authentication.
          VK: Yes, just don't encode keys there.
          Ted Hardie (TH): DS hack sounds promising. Agree with ekr that if
          reasonable semantics are in there, as long as it works. That doesn't
          mean that this goes from 10 years down to no years. We have to be
          practical. It's okay if this takes a while. Figuring out which is the
          best is fine, but I want to urge the working group... even if it's 10
          years, keep at it. It's still a major upgrade to get this done.
          PW: One clarification: if WG does that, please make it clear whether
          we're using SVCB as glue at the parent or authoritative at the parent,
          and argue why which one is better.
          BS: The name hack thing has some merit. I'm also supportive of people who
          want to support the DS hack. I think the advantages of the DS are a little
          more limited. The DS at the parent is also controlled by the parent,
          so in terms of large scale interception attacks mounted by the parent,
          the part is _always_ in a position to do that so nothing has changed. We
          need CDNSKEY not CDS, and we also need new hash algo types to be able
          to inject this into the DS. We can't expect software upgrades everywhere.
          PW: I think that's a fair point... especially CDS might not be as deployed
          as we hoped. I want to clarify, the SVCB at parent the only additional
          function is to protect in-bailiwick name servers, which I think is
          unfixable anyway. This is a lot of changes for a very small problem,
          and that seems like overkill to me.
          BS: I do think that one the things here is that DPRIVE is a big change so
          it shouldn't be a surprise that we're going to have to think hard about
          the changes. I'm comfortable with that. I think it's even conceivable
          that we're going end up wanting both of these.
          As Ekr mentioned, you need the TLDs to be fully encrypted to protect
          the 2LDs.
          dkg: I like the DS proposal. I want to point out that if we end up using
          this we may flush out bugs, because we're making a DS record that does
          not offer DS. These bugs would be see if we want to upgrade algorithms
          anyway. So this is preparing us to migrate to a new algorithm suite
          anyway. Running into these bugs would be healthy. Second thing. This
          signal should only indicate a couple of bits: hardfail/not, which
          mechanism, NOT keys. Would a signal in DS relate to entire zone or
          a specific name server of that zone. There are different impacts of
          deciding it in different ways.
          BH: We've talked about per-server or per-zone, and we have to work
          dkg: I know we've talked about that. I don't see how it can work with
          per-server mechanism.
          BH: Open issue.
          Erik Nygren (EN): Jumping into implementation solutions. Not writing
          down exactly what all requirements are. Might go a long ways to write
          down what the requirements are. I agree with Ted that we should aim
          for a long-term solution. Is there an incremental path towards the
          10-year solution? One path draft-tapril-ns2, has similarity to ekr's
          draft. SVCB-equivalent (NS2, living in parent zone) did not contain
          keys, but in ALIAS-mode record, so that key could live alongside the
          name server name. Configuration around keys lives with the owner of the
          name server and not with the zone.
          BH: Point of frustration about requirements discussion. We had a draft
          and didn't get much feedback.
          BD: DS proposal will be written up, will do it in DNSOP. Will be a new
          DS algorithm. Contents of record would be a concatenation of the NS
          RDATA for the child zone, linked to the NS records, independent of child
          zone itself. Characteristics tied to server not zone. Use a hash of the
          ...? Downside is getting it into the parent zone, which currently is
          EPP, but no work on TLD side, except permitting a new algorithm. Allows
          validatable NS delegations, currently missing in DNS.
          VD: With the NS signaling clarified to not carry keys, I am more
          sympathetic to it. Roughtly equivalent to DS, modulo that we don't have
          parent signing of NS. If that is desireable, we have to look at the pros
          and cons.
          ekr: Trying to figure out the way forward. 3 points. 1) If we were to
          change unauthenticated as I said earlier, that would get us a large
          part of the way there. If you agree with Paul's analysis this is fine
          because you cache a lot of information, then this gets us far along. 2)
          If you believe that the cache has to be hot (we've been assuming cold),
          that would be helpful to flesh out. 3) If we can agree on the information
          set in this value, then we could debate how it was propagated at the
          parent separately.
          PH: If the working group goes towards DS, Peter and I can change the
          signal we're using to be a new record type of DS-in-child with the same
          information in the same format. That might fix the CDS problem. We can
          come up with a new child record, with just the bits that we want, that
          can get copied in the parent.
          VD: The DS record in the child is unnecessary. CDS plus a new DS algorithm
          would work. If the parent information was a hash, you wouldn't need any
          additional information.
          PH: We're suggesting the DS in the child to allow compatibility.
          VD: There's more than one thing we can play with. SVCB least likely,
          but others have some creditibility.
          BH: Topics that need engaged discussions. Will kick off on mailing
          list. If people have topics they want covered, please let us know.

Generated from PyHt script /wg/dprive/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -