I've been thinking about this on and off. From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla Sent: 08 March 2018 23:25 I think that this and draft-putman are not competing, but rather that they serve different use cases Agreed. It sounds like you have a set of use cases where you know how to predistribute the server key? This is the part we found challenging in the web context.
Yes, the use case I was addressing was identical to external PSK, so the server key is distributed in the same way as the external PSK is distributed (for example, factory provisioning). But in the web context, it occurs to me that the server key could be distributed in the URL. An method similar to (or even a repurposing of) the username/password option could be used when chaining from one web site to another. For example, one site could link to another using the URL https://<keyid>:<ECDH public key>@<host>. This would allow the client to make its first request to the new site using 0-RTT traffic. A number of issues: 1) What if the public key has been retired? The client should include alternative authentication methods so that the handshake could proceed, though of course the request would have to be repeated once the connection was established. 2) This allows an attacker to leverage a vulnerability in one site to impersonate another. To mitigate this, the handshake could include Certificate/CertificateVerify messages in server's response to provide independent authentication. 3) Does this work at web scale? I can't answer: not my area of expertise. Proxies would have to be smarter, but provided the client includes non-3DH authentication methods in the ClientHello, then the failure cases will not cause any additional RTTs in setting up the connection. Is it worth tackling these issues to save one RTT when connecting to a new host? Again, I don't know, but I think it's a question worth asking. Tony Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK. This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment. Dyson may monitor email traffic data and content for security & training.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
