- From: Simone Bordet <simone.bordet@gmail.com>
- Date: Tue, 23 Sep 2014 14:54:20 +0200
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
Hi, On Tue, Sep 23, 2014 at 2:23 PM, Eric Rescorla <ekr@rtfm.com> wrote: > I see what you mean. I think clearly a conformant HTTP client is going to > need to configure > the TLS stack to suppress any ciphersuite it doesn't recognize. How can the client do that if it does not even know what is the protocol that the server will choose ? The ciphers that would need to be suppressed for h2 may not need to be suppressed for h1. Along the lines reported by Michael Sweet for iOS, I have doubts that JDK/Android implementations of TLS will offer much in this area, and if they do it will take years. >> Now say the API is a bit more elaborated and the TLS library client offer >> h1 with cipher set C1, h2 with C2 and Pn with C3. Only C1 and C3 contain >> cipher Cn. The TLS client library does a union of the cipher sets and as Pn >> is the preferred protocol the Cn is up in the list of ciphers. The server >> choose h2 and Cn. Now again the client can't continue although it supports >> h2 and Cn. It even can't continue with h1 as h2 was negotiated with ALPN. > > Again, this seems like a "don't do that then" kind of situation. Can you expand on what you exactly mean here ? The client has no idea what the server will choose so from the client point of view everything is legal. Had the server chosen Pn and Cn, everything would have worked fine, so how can the client "don't do that" if the server chooses h2 ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Received on Tuesday, 23 September 2014 12:54:49 UTC