Time: 2024-03-21 10:30–11:30 and 15:30-17:00 [+1000]
Place: Brisbane, AU
Chars: David Lawrence, Glenn Deen
Note taker: Lars-Johan Liman
Administration [10 min]
Announcements from Chairs
Document status
Docs
Architectural Directions Discussion
AOB / Discussion (all)
Planning & Wrap up
Session 1, 10:30–11:30
Agenda bash
Some items were moved between morning and afternoon sessions.
Welcome from chairs
Several drafts received support for publication, but also pushback, esp.
regarding security. The WG will be taking a step back discuss further.
Much discussion has passed, around "we need secure DHCP opt!", "No it
won't work."
Since the last meeting the group has discovered how to do ADD resolver
through DHCP environments and published a draft.
Chairs will leave to the WG to decide which path to take. Discussion
will happen now, and be continued during the afternoon session.
Tiru Redda presented (see slides). Goal: to deploy encrypted DNS on
CPEs. Problem: handling CA-signed certificates.
Michael Richardson: name constraints are real. Getting service from
CAs for this is problematic. There are policy restrictions from above on
what can be done. Becomes a price issue. It's not a technology issue,
it's a legal and business issue.
Ralf Weber: Can TLSA records in the DNS be used?
Answ: no, not supported in browsers.
Ben Schwartz: what's the actual issue?
Answ: too expensive, and too dependent on CA.
Discussion about how to bootstrap encrypted DNS ensued. Opportunistic
enc is much easier to accomplish than auth enc.
Ray Bellis: strongly suggest to look at RFC 5625: DNS Proxy
Implementation Guidelines.
Erik Nygren: trying to establish authenticated encryption in a CPE
doesn't make sense.
Ralf Weber: (to Ben S.) opportunistic encryption doesn't work
reliably in this situation.
Chair: this is an important question. Does the WG feel sufficiently
informed?
Puneet Sood: which applicatinos/clients are we talking about? Is DDR
not implemented?
Answ: DDR doesn't work in opportunistic mode. It could work, but no
support for it.
Andrew Campling: "Is this a problem that needs to be solved?" Yes!
Geoff Huston: star cert cannot be revoked. You just have to live
with it. Not good!
Answ: we are not using start certs. Using normal revocation mechanisms.
GH: revocation is a real issue. Checking status is a huge amount of
traffic. And slow: revocation lists are typically updated very seldom.
Chair: we ned to add revocation as part of the solution.
Lorenzo Colitti: slides say "if you con't have a public IP address,
it doesn't work". That's for IPv4, so don't use it.
Ben Schwartz: there are three modes: 1) name-based DDR, 2) IP-adress
modes a) authenticated, b) opportunistic. 2b doesn't make things worse,
but also not much better. For 2b it doesn't matter if the IP address is
public or not.
Ralf Weber: link-local addresses are used, so Ben's comment is moot.
Ben Schwartz: the problem of connecting to your local DNS in a
secure fashion is the same problem as connecting securely to any other
service. Should be discussed in a broader context in the IETF.
Eric Vyncke (AD): I'm starting to see that this problem is bigger
than ADD.
Meeting ajourned until after lunch.
Session 2, 15:30-17:00
Tommy Jensen presented (see slides).
Tommy Pauly: some nits: would like change how DDR is referenced. Use
terminology from the DDR doc. Examples of RR responses would be nice.
Redirection vs. designation in sect 5: is there a difference?
TJ: good point. They are very similar. Need to spell this out to
implementers.
TP: Also, important that the point which the client is redirected to
can continue with the same set of protocol parameters. There is need for
more specificity. Put in text that explains that there are performance
optimisations for the client that the server can do.
TJ: The purpose with redirection in sect 5 is not to tell the client
all the points the client can connect to, but the one where it would
like the client to connect.
Manu Bretelle: There is a problem when a redirection shifts the
client from anycast to unicast, which may be down. How to switch back?
TP: if service goes down, the client will restart the search process
from scratch, and self-heal.
Ralf Weber: sect 4 and sect 5 have different trust models.
Chair: this document is not a WG doc, but I see a lot of
participation, so we will run an adoption call on the list.
Tommy Pauley: try to get as many edits as possible in before
adopting it.
Tiru Redda did a quick rerun of this morning's presentation (see
slides from the morning).
Chair: several options:
Jim Reid: good job identifying the problem, and it needs to be
solved. If we move the scope to be wider, then this WG is no longer the
right place.
Tiru Redda: there is a difference between the CPE problem and other
services (e.g., printer). Other services have bootstrapping techniques,
but here.
Eric Vyncke, AD: if we see that this issue is broader than what we
see in this WG, we probably have to start a new WG.
Chair: we have a limited sense of direction at this point.
Tommy Pauley: agree that opportunistic DDS is a way forward.
Ralf Weber: would like to have the problem solved. If opportunistic
encryption would work it would be OK, but it doesn't, so we need
something that does.
Eric Rescorla: we need to sharpen the problem statement. This
problem is solved.
Chair: Tiru, can you please repeat the problem with Let's Encrypt.
Tiru Redda: yes. They thought we were DDoSing them, due to
millions of CPE requests.
Eric Rescorla: You need to manage a credential for each CPE. There
is no way around that. There will be problems if several CPEs have the
same credentials.
Lars Eggert: I agree with ER. The better way is individual
certificates.
Andrew Campling: Tiru, you have identified solutions, but they are
note suitable, is that correct?
TR: basically, yes.
AC: maybe reframe the questions. If the solutions aren't right, specify
clearly which problem the WG is expeted to solve.
TR: is there a better way than the one we use?
Wes Hardaker: You could do DANE.
Chair: Next steps: we need to tease out the problem, have it
documented, and captured, so we can iterate around it. Maybe we will
need a new WG. Looking for volunteers for such a problem statement
document.
Eric Rescorla: There's a third problem statement: manufacturers
like to have a giant pile of certificates – one for each device – and
they'd like to issue them in some more efficient fashion. I think
that's like, original problem statement. It's not unique to the DNS.
TR: Yeah. That makes sense.
ER: Maybe we need to update the technical restrictions. Unfortunately,
we don't have the right PKI people in this room.
Chair: Do we need more discussion? Is this a bad idea?
TR: we can write down what we have.
Andrew Campling: in addition to problem statement, please expand on
what the current solutions are, and why they are not viable.
Chair: yes. Include that in the problem statement.
Jim Reid: prob statement is a good idea, but what is the
continuation? We need a hum.
Lars Eggert: cannot find where this fits in the charter.
Chair: this has failed an adoption call, but also received support.
WG stepped back to formulate a statement. If we don't get adotion, we
can capture why and see if we can find a better place for this problem.
Tommy Jensen: we can change details in our solution, but the problem
is more general, and I think we should work on it.
Tiru Redda: we didn't want opportunistic encryption, but
authenticated encryption.
Chair (to LE): if we canot solve this, we will have missed our core
task.
Tommy Pauley (to TR): eplain why opportunistic is not OK.
TR: we want authenticated discovery.
TP: with private addr, the best you can do is opportunistic with a valid
cert, or do DNR, which is fine.
TJ: it can work, but not perfect.
Mike Bishiop: there is a design from a differenent spece that is
trying to solve a similar issue. Look at Plex and the way they get
certificates work on install. They put the IP address in the host name
and generate A URI where the DNS will resolve certificate will match.
Leslie D'aigle: get agreement on the problem statment before going
forth!
Eric Vyncke, AD: the job ewill probably not be done in ADD, as this
WG doesnt have the right expertise. Documenting the problem will be
useful.
Chair: poll: who would like to see the problem statemnt done in this
WG?
There was a clear yes in the room.
The chairs will bring this to the list suggesting that the WG create a
problem statement, preferrably before the next IETF.
None.
The chairs thanked for good discussion in a civil tone.