Re: [Dance] client-id and client-auth WGLC summary

[Joey Salazar <[e-mail]>]

Thank you Shumon for the clarifications and follow up questions.

Michael Richardson, Rick, Viktor D, and dance at large, we look forward to
reading your thoughts on these!

--
Joey

On Mon, Jul 10, 2023 at 8:34 AM Shumon Huque <[e-mail]> wrote:

> On Wed, Mar 1, 2023 at 11:24 AM Joey Salazar <[e-mail]> wrote:
> > Hello DANCErs,
> >
> > WGLC was held in November for the 2 extension documents; client-id [1]
> and client-auth [2].
> >
> > Here's a summary of the feedback received.
>
> I've started preparing updated drafts to address the WGLC comments.
> However, some discussion needs to happen on some of the points, which I'll
> begin with this email.
>
> I won't be able to make the IETF117 draft cutoff deadline (today)
> obviously, but aim to have updated drafts ready to be released once the
> submission window opens again during IETF117 week on July 24th.
>
> > client-id:
> --------------
>
> > The draft SHOULD say what RR content it expects
>
> Looking through email, it looks like this comment is from Robert
> Moskowitz, and I'm not sure I agree. The TLS DANE client identity extension
> only conveys the server and client's capability/intent to do DANE client
> authentication. Details of what type or format of DANE record to be
> employed seems to me to be an application specific detail better handled in
> other documents that define those characteristics of the application. The
> DANE client authentication draft could in theory constrain the format of
> the RR (e.g. only allowing say the DANE* usage modes, or a specific
> selector/matching type) but then again, that may unnecessarily inhibit
> certain applications that wanted to do something different.
>
> > Needs a check regarding the supported TLS version, the reference used
> for framing extensions (RFC6066 vs RFC8446) and for the architecture
> document
>
> This comment came from Michael Richardson. The specs support TLS 1.2 and
> 1.3 (and presumably future versions going forward). What specific check do
> you propose to be included?
>
> We reference 5246 for TLS 1.2 and 8446 for TLS 1.3. RFC 6066 is a
> companion document to 5246 that describes the currently (at that time)
> defined extensions in TLS 1.2. The general definition of extensions is in
> 5246 and 8446, so I don't think this draft needs to reference 6066.
>
> Yes, we should reference the DANCE architecture document. I'll queue up
> that change.
>
> > Request for clarity on the ClientName limit definition and the
> decode_error alert and a closedown of the connection when using empty
> dane_clientid extensions defined as <1..255>
>
> The limit question came from Michael Richardson I believe - and yes, and
> we can expand on why the "1..255" length was chosen. Technically, the 255
> character limit is the limit on a "wire" format domain name (see RFC 1035,
> section 2.3.4), whereas in keeping with how TLS specifies hostnames, the
> extension uses textual presentation format domain names without the
> trailing dot. However, in practice these 2 lengths are close enough and
> most hostnames seen in the wild don't approach anywhere near that limit.
>
> The potential "decode_error alert" on using empty extension comment was
> from Rick van Rein, who says the definition of this in the draft does not
> account for an empty extension, and this will cause an error. However,
> reading the draft more closely, we clearly state this:
>
>     "Its extension data (if not empty) has the following format:
>
>        opaque ClientName<1..2^8-1>;"
>
> So, this definition is only for the extension data in a non-empty
> extension, which seems to correctly account for this. I'm not an expert in
> TLS presentation language syntax however - if there is a way to more
> cleanly define an extension with optional extension data, please suggest a
> modification here.
>
> > Request for consideration of the use case for mixed environments in
> terms of certificate_authorities
>
> We don't directly address this, but I suspect the typical methods employed
> in mixed mode environments would work here too. You would either separate
> endpoints (or URLs), and if the application on top of TLS needs to instruct
> clients of new authentication parameters, I suspect it would probably use
> re-negotiation (TLS 1.2) or post-handshake authentication (TLS 1.3). Rick -
> do you have any specific suggestions about how you think such environments
> would handle it? And even better, do you have any proposed text?
>
> > More stiff requirements suggested in order to improve interoperability
> and reduce code complexity
>
> Reading email archives, the strict mode suggestion was to say things like
> MUST supply the extension. We could. But I think we are again branching
> into application and environment specific requirements which are best
> specified in other documents - mixed mode environments, to refer to a
> previous comment, maybe one case where such mandating could cause problems.
>
>
> > client-auth:
> ------------------
>
> > Request to add domain name example and text on the use of wildcards and
> DANE-TA
>
> Yes, we can add an example of a wildcard DANE-TA TLSA record.
>
> > Request to consider the potential need to encode the transport label
>
> I think this comes from Michael Richardson's comment that there may be
> situations in which the transport protocol may matter - and that presumably
> a client could need different credentials for each transport. I agree that
> could be the case. But as the doc already says, these are examples of
> client TLSA record names that could be generally useful, and not
> comprehensive or proscriptive. Individual application profiles of DANCE are
> free to specify those details and define their own specific formats. My
> immediate suggestion would be to remove the absolute like language from the
> draft ("There is no need to encode the transport label").
>
> > Request for clarity on the security considerations from RFCs 6698 and
> 7671
>
> Ok, I'll see if I can pick out specific security considerations pertinent
> to DANCE.
>
> > Request for clarity on the exception that allows for SHOULD when using
> X.509 certificate and a suggestion to change it to MUST
>
> The specific question from Michael is: "What is the exception that allows
> for SHOULD?" in relation to the following text:
>
> } Additionally, when using raw public key authentication, the client MUST
> } send the TLS DANE Client Identity extension [TLSCLIENTID] in its Client
> Hello
> } message. When using X.509 certificate authentication, it SHOULD send this
> } extension.
>
> The short answer is that with X.509 authentication the server can extract
> the client name from the certificate, whereas with raw public key, the
> client has to send its name in the DANE client identity extension, because
> there is nowhere else to get it from. Let me see if I can make the text
> clearer. We also need to clarify whether the SHOULD refers to sending the
> extension, or sending data in the extension.
>
> > Smaller wording suggestions and nits IRT DNSSEC validation, distinction
> between TLS and DTLS, [_service] and device notation, references for both
> RFCs and inactive drafts
>
> I'm not 100% sure what this paragraph is referring to, but am digging into
> past email list discussion.
>
> > Looking forward to the upcoming discussion about any of these points and
> updated drafts,
>
> I look forward to more discussion on these points, and we can then work on
> text.
>
> Viktor D - it would be helpful if you can review this too.
>
> Thanks,
> Shumon.
>
>