On 4/26/19 08:45, Victor Vasiliev wrote: > > From the technical standpoint, I agree with Martin that a > NewSessionTicket extension would be a better fit, but this is > something that we can figure out later without much trouble. I agree with Martin and Victor, that the NewSessionTicket extension is the better fit to signal support for this TLS extension. > > The policy questions (when /should/ the client resume?) are more > difficult here, and there are multiple aspects to this. One is, as > Martin pointed out, is clarifying the notion of server identity from > application perspective in cross-domain scenario. Another is ensuring > that the linkability properties are not altered in ways we don't > understand. On the surface, one can argue that this is semantically > the same procedure as HTTP/2 connection pooling, but without the IP > match requirement. This is good, because we can build on the analysis > of an existing mechanism. Still, in practice, this might open us up > to attacks that with the IP match were impractical. We should ensure > that the document describes things we've learned from connection > pooling, too. > I agree, that the new feature of this extension for web browsing is to conduct HTTP/2 connection pooling without the IP match requirement. However, we should consider a network attacker to be anyway in control of DNS. Thus, the requirement of a matching IP does not provide security benefits against this attacker.
As learnings from connection pooling I'm aware of origin confusion attacks against virtual hosting. Can somebody point out other relevant attacks in this context? Best, Erik _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
