On Tue, Nov 19, 2019 at 6:50 AM Benjamin Kaduk <bkaduk@xxxxxxxxxx> wrote:
On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote:
> Hi Yaron,
>
> Thanks for reminding me about the codepoint issue. It's a sticky one.
>
> As far as I see it, there are three options:
>
> a) Change the document to UPDATE RFC 8446
> This feels like a heavyweight option and may complicate things since it
> will mean that SNI is allowed but undefined for CertificateVerify in the
> TLS handshake.
>
> b) Ask for a new extension point for SNI sent in a client-generated
> authenticator request.
> This has the downside of not scaling to future client hello extensions that
> could be useful in exported authenticator requests -- it forces the
> definition of a new code point for each new extension.
>
> c) Explicitly state that the CertificateRequest-like construction in
> client-generated exported authenticator requests is a new type of message
> (analogous to a ClientHello) and clarify the rules about which extensions
> can be used when it is client-generated (specifically, say that any
> extension supported in CH is allowed)
> This is my preferred solution.
Just to check: this would be adding a new possible value for the "TLS 1.3"
column at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 ?
Not necessarily. The text could be amended to say something like:
"the allowed extensions for client-generated authenticator requests need to have CH listed, and for server-generated authenticator requests need to have CR listed"
The only current extension that supports CR, but not CH is oid_filters, which is not relevant to client-initiated authenticator requests.
Thanks,
Ben
> I'm interested to hear what the working group thinks, and I'll happily
> present the options at IETF 106 if there's time.
>
