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

[Shumon Huque <[e-mail]>]

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.