Move to a cipher suite blacklist (WIP) #644
Conversation
| described in this section with a <xref target="ConnectionErrorHandler">connection | ||
| error</xref> of type <x:ref>INADEQUATE_SECURITY</x:ref>. | ||
| The TLS implementation MUST support the <xref target="TLS-EXT">Server Name Indication | ||
| (SNI)</xref> extension to TLS. HTTP/2 clients MUST indicate the target domain name when |
There was a problem hiding this comment.
Even when the client is in Private Browsing mode?
There was a problem hiding this comment.
Yes, if we want SNI and thus TLS to be as widely deployable as we would like them to be. We might as well not send the "Host" header or not do DNS lookups in Private Browsing mode.
There was a problem hiding this comment.
I am merely reflecting the gathered consensus. In a private browsing context, we might want to start using an SNI confidentiality mechanism. waves hands
There was a problem hiding this comment.
Browsers support SNI identically in private browsing mode and the default browsing mode. There's no need for a change here regarding private browsing.
| <t> | ||
| Note that clients might advertise support of cipher suites that are prohibited by the | ||
| above restrictions in order to allow for connection to servers that do not support | ||
| HTTP/2 and only prohibited cipher suites. This allows servers to select HTTP/1.1 with a |
There was a problem hiding this comment.
s/and only prohibited/and support only prohibited/
Seems easier to read.
This is based on the long set of negotiated changes added to #615. This adds the blacklist as Sam Hartman proposed at IETF 91.
Closes #612.