Monday 7 November 2022
Room: Kensington 1
9:30-11:30 UTC
Log into the IETF datatracker to access:
Presenter: Thomas Howe & Dan Petrie (in-person)
draft-petrie-vcon
Messages
Mailing list
Ted Hardie: It has to go for a BoF. It is a large-scale piece of work.
At the BoF, we will want to tackle a very fundmental question: Is this
the right lego piece? In IETF, we build building blocks - this is
partially built from other building blocks. If you model this with full
ontology, this is actually an utterance. This utterance has the identity
properties and the linkage of different utterances into time sequence or
set of exchanges is what you are calling a conversation. What I want to
see all these utterance by this particular identity cross a series of
conversions. If we run a BoF, need to be specific on what we're asking
people to build. What are the building blocks that are going into this?
To back up a step, if we are going to run a BoF, what are we asking
people to build? How many pieces are there? Some of the privacy
considerations that you have will expand a good bit. Whether or not the
identity framework is suitable if you look at from a single interchange
may be quite different if you look at from a different perspective.
Thomas Howe: Appreciate that, I thought about the same thing and I
understand that. When you took the primitives that we already have, they
roughly represent the elements that are composite and putting together.
But if you think about them from a system diagram, the actual component
we think about is externally referenced not from the application layer
but regulations from vendors side and it transforms us to the entire
ecosystem. We have a lot of requirements on that component, that is what
brought me to there. I agree with you.
Jonathn Rosenberg: Two comments. One is that it should go for a BoF.
Second thing is, unclear but valuable to the BoF, who is this meant to
be exchanged between? Needs a system diagram. Clarifying the scope of
what are the participants that you want to exchange between, what should
be in this or not.
Thomas Howe: The 25-page white paper has 15 use cases. How to make it be
useful for the BoF?
Jonathan Rosenberg: Write a draft on these use cases.
Robert Stepanek: Don't want to start bike-shedding, but vCon is a
confusing name.
Thomas Howe: Started from a joke. If you have a better name, I would
like to hear about it.
Eric Rescorla: This should go to a BoF clearly. The requisite for a BoF
would be a clear problem statement document and a use cases document.
Lay out the problem space so people understand what we are trying to
solve. Share the problem statement around with other vendors who might
be interested.
Thomas Howe: Thanks.
Martin Thomson: Maybe a BoF is not the right thing to do it. Forming a
constituency around this, possibly the W3C might be interested in this
work.
Thomas Howe: They have reached out. We believe that there were enough
privacy and security requirements that were coming from the bottom of
the stack, so we suggested it should be part of the problem. It is more
a basement than an attic.
Martin: Joint work? A lot of higher layer work discribing things like
data models. Thomas: Please look at the 25-page white paper. It shows
how it applicable to so many different places.
Cullen Jennings: BoF. This is very interesting to us. I am Cisco AC rep
for W3C. Interested in the use cases that help us manage ML training
data. Will this be done on top of semantic web? It will be ignored if
so.
Jonathan Rosenberg: I don't think that W3C is the right venue. This is
like telephony stuff, lots of work on call detail records. Think IETF is
fine and it should be a BOF.
*Dispatch outcome: Create draft with use cases, problem statement to
clarify scope, and then take to a BoF.
Presenter: Rick van Rein
draft-vanrein-sipauth-sasl
Messages
Jon Peterson: 10 years ago somebody presented this before for SIP. We
kinda come up with security primitives that work for SIP. We have
managed most of the security gaps which SASL may rectify, together with
STIR. It is a tough sell. No action for dispatch.
Rick van Rein: If there's documentation of discussion 10 years ago,
would like to see it
Eric Rescorla: Dispatch: no action. Do not think this is going to go. As
mentioned in email, start with "does anybody who operates a SIP system
want to do this". Has anybody deployed this?
Rick van Rein: I want to work on it. Eric: does anybody want it? Rick: I
think for the wireguard it's a good use case.
Eric Rescorla: the question is: does anybody who operates an existing
system want to use SASL? If the answer is no, then this doesn't matter.
Rick van Rein: For wireshark there's currently no mechanism for setting
it up. This adds new venue.
Eric Rescorla: Has anybody who operates these systems, e.g. wireguard,
want to deploy this?
Rick: I will take the question and look around to see if people are
interested.
Eric Rescorla: On the technical side, this misunderstands the security
situation around SIP. We have mechansims that work. The right way to do
this is to extend those identity sets with STIR, not by replacing the
whole thing.
Rick van Rein: I want to use it as domain names. Eric Rescorla: But will
anybody who runs a sip system want to use the domain names?
Cullen Jennings: Technical comment - when you're talking about
end-to-end security, SIP is a hop-by-hop system. You might want to put
this security on top of the VPN layer rather than the inherantly
hop-by-hop system.
Rick van Rein: Will start with wireguard, maybe it needs some work.
Anthony Somerset: Operate a large scale voice network (Liquid) - what
are we trying to solve? Authenticate caller ID? That the caller is a
person on an endpoint? They are two different things with two different
problems. It's hop by hop and you have to make routing decisions. Want
to echo "authenticate the network layer". But would like to see an
alternative to Digest. Might be difficult from a network to network
perspective.
Rick van Rein: What I am into here is to make a cross-domain call
possible. What you said would be a general use case. Thank you for
stating that you would like to see a replacement for Digest.
Jon Peterson: Didn't want to go technical details but will just a little
bit. STIR is not limited to telephone numbers, like RFC4474. If you're
concerned about securing TO and FROM, they're usually not controlled by
the same party anyway - so figuring out who should attest to the
identity. So SASL is not aligned to the problem that SIP is trying to
solve. When question is interoperable layer cross domain, we've got that
as fixed as it can be with STIR.
Rick van Rein: Looking STIR only one RFC? Jon: There are 10-12 RFCs.
Rick: I will look into it.
DKG (via Jabber): Wireguard deliberately avoids any fancy authentication
mechanisms for the sake of simplicity (endpoints are identified by raw
public keys). I suspect that wireguard itself will never adopt fancier
authentication schemes.
Eric Rescorla: Think it's important to distinguish between two things
(authenticate client to SIP server) - where SASL is usually used. The
other is end-to-end. Think it's inappropriate for this, and peers who
work on client-server say that's already solved. My sense is that you
like SASL. If you want SASL in SIP, you should look at client to server.
Rick van Rein: Need to organise what is actually needed and if this is
the solution for that.
*Dispatch outcome: Do not proceed with this work in IETF.
Presenter: Wei Chuang (virtual) and Bron Gondwana (in-person)
Four draft solutions to a common problem:
Murray Kucherawy: Is anyone using any of these yet?
Bron Gondwana: Yahoo is using. It is not a perfect solution though.
There are a lot talks about it. People are trying to find out the right
solution.
Barry Leiba: Former DKIM WG chair. We discussed about this issue a lot
in the original DKIM design, but we could not resolve it. We now have
more information and operational experience. We know about the
priorities and ability to compare the different proposals. So it is
important to look at this. A new WG is the right venue.
Eric Rescorla: There seems enough energy behind this. A new WG seems
good.
Jim Fenton: This is something that was considered in the design of DKIM.
The requirement for confidentiality of BCC recipients in the same domain
should also be considered. This is an interesting problem to solve.
Whether it is a solvable problem with all the constraints without
breaking something?
Bron Gondwana: This question has been answered in several drafts. Each
BCC recipient can only see their own address not others. That solves it.
It is not a big cost now. We consume it is required because computer is
fast and it is not a problem now.
Jim Fenton: Gmail has enough capacity to handle the additional incoming
mail? This is also a burden on mailing list.
Bron Gondwana: It is already happening.
Wes Hardaker: Agree with Eric, these problems get bigger and bigger.
This is big enough of a problem to require a WG, will consume 2 hours
every time we meet. But how will this evolve over time? Work needs
continous discussions and measure how things work. It seems to me that a
longer term maintanence WG is needed as well.
Bron Gondwana: Agree. In the next couple of years, we need to talk with
the ADs to consolidate several email WGs into a maintenance WG. AD, do
you want to comment on that?
Murray Kucherawy: We have talked about that. There is a related concern.
A lot of drafts are heading to ISC because there is not a maintenance
working group. It can also turn into the ocean boiling so we need to
control it properly. The conversation is happening. It sounds that
people are OK to start a WG without a BoF? If anybody wants to chair it
please let me know.
Cullen Jennings: A lot of people in this room don't believe the problem
solvable. BoF would provide an opportunity to discuss the problem and to
see whether this problem is solvable. We tried to solve this problem
many times before but we failed. We need a BoF to see whether there is
anything that has changed fundamentally.
Barry Leiba: To Cullen, what has been changed is that we have more
experience with using DKIM. We know about the more important use cases
than those ones which we can compromise on. Why we did not want to do
the solution before can be re-evaluated to see now whether we can say
now these use cases are less important.
Cullen Jennings: That make sense. But there is no discussion on any use
case. This is missing.
Barry Leiba: That is up to the WG to solve.
Kirsty: Have heard no-one but Cullen ask for a BoF before the WG
forming, if you disagree and think a BoF is needed - please join the
queue now and express that view. Given no-one joined, will say that is
not necessary and the WG can be formed directly.
DKG (via Jabber): I'd hope that a WG could consider recipient-controlled
permissioning something like ORCA
(https://www.usenix.org/conference/usenixsecurity22/presentation/tyagi),
to accomodate opt-in situations like the mailing list use case
*Dispatch outcome: Form a new WG without a BoF for this problem.
Presenter: Sergio Garcia Murillo, Cheng Chen
draft-murillo-whep
Messages
Cullen Jennings (Jabber): I can't figure out how to get on the q anymore
but +1 on recharter WISH WG to do this
Murray: Has this been discussed at WISH?
Sergio Garcia Murillo (speaker): It is in the agenda for this Thursday.
We tried to present in the last IETF meeting, but only 5mins. It is
difficult to discuss something that is not in the charter of the WG.
Hope we could get the WG to rechartered so we could get it into the
agenda.
Murray: We'd better to wait for the outcome from WISH meeting.
Sean Turner (Chair of WISH): We have 5 minutes to talk about it last
time, we have a 30 minute session on it in the WISH WG session this
week, so let's see if that's in scope.
*Dispatch outcome: wait for the outcome from WISH WG discussion this
week.
Murray Kucherawy: If there's anything in my queue that I haven't
acknowledged, let me know.
Presenter: Stephen Farrell
Slides
Stephen: mostly just raising awareness of funding, no questions.
Presenter: Dave Thaler
Slides
David Schinazi: I used to think IETF should not standarise API. IETF has
changed. I think it is important. If you make your analogy with
JavaScript work, that would be amazing. IETF would be a good place.
Dave Thaler: Encourage you to go to the Side meeting.
Eric Rescorla: This is good stuff. I'm less excited about having it at
IETF, purely for cultural reasons. Like this requiring knowing how JITs
work, different languages, verification etc. Possibly looking at what
was done with TC-79, in W3C, that had the community (bringing a lot of
JIT compiler folks together), very intense working mode culture. Want to
emphasise this is exciting work and I'm glad it's happening. Will avoid
"drop-in tourism".
Dave Thaler: My counter is this is widely deployed and not standardised.
There's a bunch of people already out there in the community that do
this but they are not "IETF people". I would like to encourage more
interaction between these communities, regardless of where this happens.
Eric Rescorla: Requires care and feeding.
Dave Thaler: It is not yet mature and still evolving. It depends on how
fast the IETF's proceedures are. To get everybody in the same room could
help.
Harald Alvestrand: What's your perception of the relationship between
this and WASN? And the two dev communities?
Dave Thaler: I don't know WASN well enough to know the difference. Is
one used more in kernel space, rather than user space?
Eric Rescorla: Does not have the proof stage that this has. Part of the
proof is about verifying termination.
DKG (via Jabber): Don't knock standardizing APIs -- we need APIs to be
able to communicate the properties we believe we are offering to the
upper layers.
Side meeting is on Thursday at 6pm.
Presenter: Hans Wang
draft-sandowicz-httpbis-httpa2
Messages
Eric Rescorla: In the diagram shown in slide 4, how much of the
webservers is running in the TEE?
Hans Wang: In this use case, we only demonstrated one.
Eric Rescorla: Is the entire webserver running in the TEE or just a tiny
bit?
Hans Wang: It could be either one. It depends on how you design the
webservice scope.
Alex Chernyakhovsky: Why are we doing this rather than an attestable
TLS? What are the benefits by putting this at the HTTP layer, now every
service needs to be aware of the attestion? Could not see any benefit
and how this will be used in the wild.
Hans Wang: The key motivation is to build the trust inside the TEE. We
don't trust anything outside of the TEE. The best way is to implement at
the high level like L7.
Alex Chernyakhovsky: I don't think so. You could simply implement TLS
mutual authentication inside the TEE.
Hans Wang: In that case, you will have to implement everything inside
the application gateway. The implementation will be difficult.
Alex Chernyakhovsky: Your goal is to have an untrusted gateway and have
the TEE do the verification. You don't want to do the sni-based routing
or anything else?
Hans Wang: Those routing can happen. We want to make sure that the
confidentiality of the message can be protected.
Dave Thaler: (Chair of TEEP) I have seen at least five different
proposals in the CCC metings. Don't think TEEP is the right place since
it is for provisioning as opposed to the actual communications here.
RATS is a good group to review it.
Martin Thomson: This is on the agenda for the secdispatch this week for
5 mins. I suggest to take this discuss to that meeting. We could better
answer the questions.
Hank: First go to the HTTP first and then RATs to review the protocols
if needed.