[10:39:12] habbie joins the room
[12:08:19] habbie leaves the room
[12:51:05] habbie joins the room
[13:36:09] bortzmeyer joins the room
[13:38:26] bortzmeyer has set the subject to: DNSOP at IETF 107
[13:45:20] Hugo Salgado joins the room
[13:47:44] Willem Toorop joins the room
[13:49:40] Yoshiro YONEYA joins the room
[13:50:45] Warren Kumari joins the room
[13:52:26] Yoshiro YONEYA leaves the room
[13:52:52] Yoshiro YONEYA joins the room
[13:54:02] sftcd joins the room
[13:54:29] Shumon joins the room
[13:55:17] Matt P joins the room
[13:55:51] hardie joins the room
[13:57:30] Florian Obser joins the room
[13:58:23] Mike Bishop joins the room
[13:58:37] Suzanne joins the room
[13:59:13] <Hugo Salgado> Etherpad for bluesheets: https://etherpad.ietf.org/p/notes-ietf-interim-2020-dnsop-01?useMonospaceFont=true
[13:59:15] Ben Schwartz joins the room
[13:59:19] Benno Overeinder joins the room
[14:00:45] <Warren Kumari> Has anyone said anything yet? (not sure if my audio works….)
[14:00:50] <habbie> they have just started
[14:00:52] <Matt P> Benno just started the meeting
[14:00:54] <habbie> so your audio is not working
[14:01:08] keith joins the room
[14:01:26] <Warren Kumari> Yay, fixed it… thanks...
[14:01:45] Weiler joins the room
[14:02:57] vladimir.cunat joins the room
[14:03:33] Vittorio Bertola joins the room
[14:03:42] ash joins the room
[14:04:01] marka joins the room
[14:04:08] ericorth joins the room
[14:04:12] Pieter Lexis (PowerDNS) joins the room
[14:04:19] <Warren Kumari> WebEx audio / volume control on my machine is nutty…
[14:05:03] <Warren Kumari> Sometimes it is linked to the system control, sometimes not…
[14:06:03] <Vittorio Bertola> Paul Hoffman told me he will resume working on draft-resinfo and post an ADD-ized version to ADD
[14:06:27] <Vittorio Bertola> (I pinged him after the discussion we had here at the DPRIVE interim)
[14:06:42] Amelia Andersdotter joins the room
[14:06:50] cm-msk@jabber.org joins the room
[14:07:42] Petr Spacek @ CZ.NIC joins the room
[14:07:49] nygren joins the room
[14:08:19] jerry joins the room
[14:09:30] João Damas joins the room
[14:10:12] CJ joins the room
[14:10:38] Francisco Arias joins the room
[14:11:56] Tim April joins the room
[14:12:06] Tim April joins the room
[14:12:06] Tim April leaves the room
[14:12:31] Tim April joins the room
[14:13:08] shinta joins the room
[14:17:04] <sftcd> with ESNI now being ECHO, there can be two different ALPNs in the ClientHello - so far that's not handled in either this spec or ESNI
[14:17:34] Denesh Bhabuta joins the room
[14:19:35] <Mike Bishop> @sftcd, it's not clear that it needs special handling.  The server is going to respond to either the public ClientHello or the encrypted ClientHello.  There is only one set of ALPN tokens in the ClientHello the server actually responds to.  That's no different than anything else in the ClientHello.
[14:20:07] <sftcd> Well, the client has to put something in inner and something in outer - what is expected?
[14:21:18] <Mike Bishop> If the server doesn't speak ECHO / doesn't hold the ECHO keys, it's going to respond to the public CH.  If the protocol isn't deemed sensitive, probably the same thing both places.
[14:21:35] <sftcd> probably isn't easy to write code for is it?
[14:21:36] <Mike Bishop> More generally, whatever it would put in making an initial connection.
[14:22:13] <sftcd> we have public_name in ECHOConfig and ALPN in HTTPSSVC - that seems a bit broken to me (I created an issue for the ESNI spec on that)
[14:22:27] <Suzanne > Reminder: if you have a q for the mic, please confirm in webex chat (q+ to be added, q- to be dropped)
[14:24:08] Tim Wicinski joins the room
[14:25:08] mglt joins the room
[14:25:56] <hardie> If it specifies the default port, isn't the result the same?
[14:26:07] <nygren> https://github.com/MikeBishop/dns-alt-svc/issues/132  Clarify how ALPN interacts with ECHO         #132
[14:26:34] <sftcd> forgot to say: I'd also like a quick code point allocation but no need to bother people's ears with that:-)
[14:27:39] Tim April leaves the room
[14:28:30] <marka> We have already had lots of churn over the internals of the rdata.  Once a code point is allocated the rdata format MUST be considered FIXED.
[14:28:34] <nygren> https://github.com/MikeBishop/dns-alt-svc/issues/134  Add warning about using non-default ports   #134  [filed]
[14:29:30] <sftcd> @nygren: thanks, related issue to your #132 for  ESNI is https://github.com/tlswg/draft-ietf-tls-esni/issues/216
[14:30:05] Tim April joins the room
[14:37:07] <bortzmeyer> Note that section 7.1 of RFC 1035 already said you should limit the amount of outgoing requests per query.
[14:41:01] chi.jiun.su joins the room
[14:42:07] Tim April leaves the room
[14:46:03] Mike Bishop leaves the room
[14:46:07] Benno Overeinder leaves the room: Stream closed by us: Replaced by new connection (conflict)
[14:46:09] Benno Overeinder joins the room
[14:48:28] <Matt P> +1 Specifying SOA as the qtype for minimisation sounds like an excellent idea.
[14:48:37] <bortzmeyer> SOA requests less remarkable than NS requests? I don't think so.
[14:49:19] <bortzmeyer> And my experience seems to indicate that middleboxes blocking NS also block SOA (F5 loadbalancers)
[14:51:14] <Shumon> Yup, SOA has the same potential problem as NS, w.r.t. to broken authorities.
[14:51:30] kiran.ietf joins the room
[14:51:56] <nygren> Is there a reason the doc recommends QTYPE=A vs QTYPE=AAAA ?   It seems like some resolvers would always want to use AAAA over A as a default.
[14:52:31] <habbie> the broken middlebox argument (that I don't really find that convincing) would apply there as well
[14:52:40] <bortzmeyer> nygren: AAAA is a bit "more remarkable" (sticking out of the crowd) and a bit more susceptible to be blocked by middleboxes
[14:53:57] <Shumon> Note that F5's that are commonly misconfigured to not to respond to SOA/NS etc, are not middleboxes, but full fledged DNS authority servers (see F5 "GTM").
[14:55:33] <nygren> It depends on the network.  In some IPv6-only networks it is likely that AAAA is going to be less remarkable.  And for cases where AAAA gets queried first (and shortcuts an A lookup) it is going to be more performant to retain the QTYPE
[15:06:28] mcr joins the room
[15:10:03] <mcr> does the flag have to be set from some point, all the way up to the root?
[15:10:50] <vladimir.cunat> The slide says "expect"
[15:11:04] <habbie> the previous slide said 'powerbind' where it should say 'powerdns' :)
[15:12:48] <bortzmeyer> Counterexample: .pl (no subzone for nameservers)
[15:15:08] Wes Hardaker joins the room
[15:15:47] <mcr> how would we know it was there, given NSEC3?
[15:15:54] <jerry> please mute yourself if your not talking
[15:26:29] <cm-msk@jabber.org> Who owns this popular "nohats.ca"?
[15:26:35] <Matt P> Paul does.
[15:26:36] <Wes Hardaker> paul
[15:26:43] <Matt P> Paul's missing Warren's point.
[15:27:20] <cm-msk@jabber.org> kthx
[15:28:03] <sftcd> I'm not seeing how Warren is wrong tbh - it does seem to me he's right
[15:28:47] <Matt P> Yeah, he is.  Paul and Wes are missing the point.
[15:28:49] <mcr> Warren's attack would be observed because  the NS/DS would be changed.  If the parent changes the NS/DS for a *specific query only*, then maybe they would win and get around transparency.
[15:29:07] <Matt P> No, it wouldn't be observed unless warren, himself, is doing that logging.
[15:29:24] <sftcd> yep, or someone else seeing the same answers as Warren
[15:29:32] <mcr> Matt: I agree. But, for that to happen, the malicious parent has to answer differently for a specific query only.
[15:29:52] <Matt P> That's Warren's point.
[15:30:03] <sftcd> attack seems more broad than just one query to me
[15:30:10] <mcr> Agreed. I agree that Warren's attack is feasible.
[15:30:20] <bortzmeyer> Indeed. Changing the data in the base is much simpler than configuring your name servers to send malicious replies to some requests only.
[15:30:27] Ralf Weber joins the room
[15:30:30] <mcr> sftcd, if the answer for many queries, then they risk being discovered.
[15:30:39] <sftcd> sure
[15:31:26] <Ben Schwartz> I don't understand why this reduces log volume for a compliant zone
[15:31:28] <sftcd> off topic: when I saw this ns2 agendum, I wondered why we're doing simulations in the dns;-)
[15:31:46] <habbie> Ben, because you can limit your logging to just DS+DNSKEY instead of Everything
[15:31:59] <mcr> so, a TLD that would publish their entire zone (for "FTP"), [as for the root zone], then the parent might be sure it could do specific query lying.
[15:32:11] <Ben Schwartz> habbie: Why doesn't that apply without this?  Why would I log anything else?
[15:32:34] <habbie> that depends on how far you want to go in CT
[15:32:43] <habbie> the flag helps in a specific narrow definition of CT
[15:32:48] <vladimir.cunat> The root can sign anything (like A records) directly without any cuts in-between.
[15:32:53] <habbie> which, last time i checked, the draft fails to explain usefully
[15:33:43] shinta leaves the room
[15:35:18] <Weiler> it looks like NS2 is designed to exist in either parent, child, or both, right?
[15:35:23] <habbie> yes
[15:36:20] <Matt P> If we're redesigning NS, why not fix the parent/child ambiguity?
[15:36:37] <marka> The root still has trust anchors which be they DNSKEY or DS records indicate if the root is delegation only
[15:36:39] <Pieter Lexis (PowerDNS)> What Matt P saidx10000
[15:36:47] <Weiler> Matt: yeah.  There's so much worth rolling up into such a change.
[15:36:59] <Pieter Lexis (PowerDNS)> I once joked about DNS records "Delegation NS records" that only exist at the parent
[15:37:15] <Pieter Lexis (PowerDNS)> example.com IN DNS ns1.example.net.
[15:37:20] <Pieter Lexis (PowerDNS)> could be signed by the parent
[15:37:21] <Weiler> pieter: you're not the only one.  
[15:38:07] <Shumon> Yes, authoritative delegation records that can be signed!
[15:38:45] <Ben Schwartz> vladimir.cunat: Thanks.  It still seems like we could just log "everything signed by this zone's DNSKEY", which should be small for a compliant zone.
[15:38:54] <bortzmeyer> Shumon: joke aside, what would be the goal? (I understand the need to give connection parameters such as the TLS key but otherwise?)
[15:39:31] Tim Wicinski leaves the room
[15:40:08] <Shumon> It would prevent spoofed glue that a resolver needlessly followed to find the child nameservers, only to be verified later (DS->DNSKEY match) that they went to wrong place.
[15:40:28] <Warren Kumari> +lots
[15:40:30] <bortzmeyer> Shumon: so, optimisation, not security?
[15:40:44] <Shumon> security as early as possible.
[15:40:59] <Warren Kumari> It also solves an information leak (I think)
[15:41:03] <Shumon> i.e. detect misdirection early.
[15:42:03] <Warren Kumari> if I'm doing qname minimization I can "unroll" by doing a delegation (without the key) to get the recursive to sucessivly expose the qname...
[15:42:08] jerry leaves the room: Connection failed: connection closed
[15:42:24] <Warren Kumari> s/if I'm douing/if the victim/
[15:42:40] <Shumon> right, less info leak too warren.
[15:47:49] <nygren> Motivation/why: if we want to use a secure transport for recursive-to-authoritative then we need to rethink how we provision/configure this.  Getting information into the parents will eventually be necessary.
[15:49:17] <vladimir.cunat> Unless we're OK for some privacy leak due to bootstrapping.
[15:51:09] <bortzmeyer> Indeed, provisioning is an old subject:-) https://datatracker.ietf.org/doc/draft-regnauld-ns-communication/
[15:53:18] <Warren Kumari> Oooh! Lunch!
[15:53:23] <Warren Kumari> with tomatoes...
[15:53:42] <bortzmeyer> NETCONF or RESTCONF?
[15:53:54] sftcd leaves the room
[15:53:59] <Wes Hardaker> BESTCONF
[15:54:23] <vladimir.cunat> bortzmeyer: YANG modelling is shared by both
[15:56:26] <bortzmeyer> Wes Hardaker:  I wait for the draft
[15:56:37] <Wes Hardaker> next april 1
[16:00:22] <cm-msk@jabber.org> YAYANG
[16:03:01] <cm-msk@jabber.org> "no pressure"
[16:05:58] <Matt P> Catalogue Zones and YANG models have use cases at completely different ops scales.  I'd like to see them both exist.
[16:06:11] <habbie> Matt, that is definitely the idea
[16:06:28] <habbie> and powerdns definitely plans to support both
[16:06:53] <Matt P> Excellent!
[16:07:45] <cm-msk@jabber.org> are you doing weekly interims?
[16:08:14] <bortzmeyer> The doodle for the next meeting displays hours in UTC?
[16:08:23] Petr Spacek @ CZ.NIC leaves the room
[16:08:28] chi.jiun.su leaves the room
[16:08:32] Willem Toorop leaves the room
[16:08:43] ericorth leaves the room
[16:08:57] <Warren Kumari> Doodle displays in whatevedr timezone *you* select… (I beleive)
[16:09:02] Vittorio Bertola leaves the room
[16:09:04] Hugo Salgado leaves the room
[16:09:18] Wes Hardaker leaves the room
[16:09:24] nygren leaves the room
[16:11:55] <Benno Overeinder> It should display in your local time zone.
[16:12:28] Shumon leaves the room
[16:13:27] Benno Overeinder leaves the room
[16:13:56] bortzmeyer leaves the room: Stream reset by peer
[16:14:06] <Weiler> where is that doodle?
[16:16:53] Pieter Lexis (PowerDNS) leaves the room
[16:21:32] Yoshiro YONEYA leaves the room
[16:22:37] <vladimir.cunat> Weiler: nowhere so far but should happen soon, I believe.
[16:23:20] <Weiler> k
[16:24:58] ash leaves the room
[16:25:17] cm-msk@jabber.org leaves the room
[16:25:26] Matt P leaves the room
[16:28:32] Francisco Arias leaves the room
[16:28:33] Francisco Arias joins the room
[16:28:34] <vladimir.cunat> It's posted now!
[16:29:51] mglt leaves the room
[16:30:28] kiran.ietf leaves the room: I'm not here right now
[16:35:50] vladimir.cunat leaves the room
[16:37:48] Francisco Arias leaves the room
[16:39:15] Weiler leaves the room
[16:39:15] Ralf Weber leaves the room
[16:40:42] kiran.ietf joins the room
[16:50:43] Ben Schwartz leaves the room
[17:03:15] hardie leaves the room
[17:20:55] João Damas leaves the room
[17:25:02] keith leaves the room
[17:26:08] Florian Obser leaves the room
[17:43:51] Denesh Bhabuta leaves the room
[18:22:14] Amelia Andersdotter leaves the room
[18:27:22] mcr leaves the room
[18:59:07] CJ leaves the room
[19:30:04] kiran.ietf leaves the room: I'm not here right now
[20:24:16] kiran.ietf joins the room
[21:10:00] Pieter Lexis (PowerDNS) leaves the room
[22:06:18] kiran.ietf leaves the room
[22:11:50] kiran.ietf joins the room
[23:43:53] kiran.ietf leaves the room: I'm not here right now