Minutes IETF101: tls: Mon 17:40
minutes-101-tls-201803191740-00

Agenda bashing
Stephen Farrell: why are we here considering there was “no consensus”
Joe: There’s interest and different technical approaches.
Kathleen: Support chairs, trying to determine if there is a way we can move
forward without strong technical or other obligations. Ted Lemon: Perhaps we
focus on proposals that don’t haves strong technical objections

Record Header Extension
Ekr: If you have the CID, you can look up the state, and you can put whatever
you want after that. Why do you need a generic extension mechanism that’s keyed
off the header? (We’re doing CID-based state lookup in QUIC.) Two different
designs — one that is packets that are self-describing, and those that are not.
Ekr: Things shouldn’t be in the packet header unless they are needed to
interpret the packet (header). DKG: Seems like SPUD moved one layer down No —
SPUD was not about endpoint-to-endpoint after negotiation. DKG: Similarity is
that it’s arbitrarily extensible outside encrypted envelope. We decided not to
do SPUD. MT: This helps with packets that arrive on different 4 tuple than
original connection, and there are no expectations about whether or not packets
have CID. (That seems rare.) Clients and servers that care about this problem
will likely use CID. Maybe not care about those who don’t use CID? Want to
avoid wasting cycles to filter trash packets. MT: In what environment do you
not have to deal with trash? IOT for the moment (?) Hannes: (missed) Ekr: CID
on Wednesday, this is strictly about the extension proposal Proposal for
generic extension mechanism Tobias Gondrom: Like the idea, though don’t
necessarily need the generic extension mechanism.

TLS Visability:
Stephen: Can you explain “many” in this context?
Nick Sullivan summarized a different approach, and others discussed on-list
Stephen: Who receives the key? More than one party?
Ted: Can the key manger send the key to more than one peer?
Yes.
Stephen: Does that meet the criteria?
Ben Kaduk: Does this need to be negotiated, or can parties just agree to do it?
People who raised concerns and want opt in objected to draft-green, which was
between server and key manager. This new draft resulted from that criticism.
Ben: Extensions used to negotiate protocol features. In datacenter you know if
you’re talking to a specific peer, with a specific implementation, so you can
decide that between a given set of peers a specific thing will be done. It may
or may not be TLS. Why is this in-protocol negotiation really needed? Doesn’t
out-of-band agreement suffice? Can’t you create a TS-like protocol that allows
this visibility. That would be another design choice. Not the one here. Darren:
Continuity in topic speaks to the need of datacenter decryption. We’d like to
ask for a vote forward for this. PHB: Agree that this is important use case —
in SCADA (?) world. Big concern in some applications is integrity, not
confidentiality. This protocol does not have the right degree of control, so I
filed a patent on the new design. Yaov Nir: Draft proposed online decryption
only. Do we need offline or online? Could make the case that anti-malware
doesn’t need online keys for analysis, as it should be higher up the stack. Not
sure why we need this feature of the protocol when passive, offline decryption
is needed. We’ve looked at cases where real-time decryption is needed. Nick
Sullivan: Does this offer the ability to compute exporters? Yes. XXX: know that
large providers do use packet flow analysis for cybersecurity reasons. Authors
have listened carefully to draft-green concerns, have addressed them and found
a technical solution that addresses privacy on the open Internet. Steve Fenter
(?): After-the-fact decryption is useful for troubleshooting. There are a
number of uses for live decryption, e.g., application performance monitoring.
Metadata is created and packets are thrown away. Fraud monitoring is another
example. For large complicated applications, it is effectively to insert traces
in many places and help debug. Stephen: How would you characterize this work in
analysis between 1.3 and the work that went into the analysis of this draft?
TLS 1.3 went through analysis, there is no analysis here yet. Stephen: Would
you not agree that formal analysis is necessary? Agreed, the same level of
analysis is needed if the WG wants to go forward. Stephen: Analysis says that
this extension is a bad idea. Shouldn’t you do that first? No, we can do it as
we work on it. David Schinazi: Can you clarify what clients and what servers
are being used? Are they data center hosts or servers? Load balancer, e.g., is
client. In some cases client is outside the data center, e.g., a POS terminal.
David: If it’s purely datacenter, you don’t need TLS (or this extension). What
is the point if browsers do not want to implement this? Absolutely. Ted: Number
of distribution points that receive keying information will not be one. State
actors might require operators to share keying material within territory for
future analysis. This type of attack must be taken into account in the
analysis. Only foreseeable way to address that is to share identities of all
listeners in the technique. Leads to increased complexity. DKG: Thank for your
acknowledging that the goal is not strictly within the datacenter. Client opts
into sharing with someone — anyone (key manager). Does the client have any way
of knowing with whom the key is shared. That’s what Ted said previously. DKG:
was that intentional? Yes, we can revisit. Kathleen Moriarty: Still hearing
major concerns that could be enough to block consensus standpoint. Would like
to see if there’s a way to constrain to datacenter use case. What if this was
server-to-server in datacenter only, and clients terminates with LB or another
entity on the boundary. Can we constrain the design as such. Do not believe
this is a fruitful way forward. There are use cases in different enterprises
where clients will not be LBs. Brian Witten: It sounds like you’re open to the
approach where client authenticates the key manager. Yes, willing to discuss.
Brian: Clients on the open Internet do not accept this visibility, and
employers when connecting to their own network do accept it.

Adoption?
Ben Schwartz: Sounds like one purpose is to guard against data exfiltration
attacks. Does not seem technically fit for that purpose. Attacker who manages
to break in can exfiltrate all plaintext traversing the network. XXX: Share
concern that this might increase attack surface area. How much more costly is
this than doing opt-in via cert installation and active MITM? Charles:
Out-of-band decryption is highly prevalent in enterprise circumstance. SIP
endpoints need it to help troubleshoot. Healthcare endpoints need it for (?).
Stephen: Can you explain how breaking TLS like this is in the scope of the WG
charter? It’s a TLS extension. Stephen: Do not believe WG was chartered to
support this type of functionality? Perhaps we start by re-chartering?
Kathleen: Are there other mechanisms that might be more agreeable?

Adoption hum: no consensus to adopt. Authors must go to the ADs to proceed next