On Tue, Nov 19, 2019 at 6:50 AM Benjamin Kaduk <[email protected]> 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.
> >
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to