[Dance] Re: [TLS] Re: Last Call: <draft-ietf-dance-client-auth-09.txt> (TLS Client Authentication via DANE TLSA records) to Proposed Standard

["Salz, Rich" <[e-mail]>]

  *
Thanks for the review Eric. Yes, we should have looped in the TLS
  *
working group earlier. (I've cc'd them).

Thanks for that.


  *
This draft's origin predated TLS 1.3, and earlier work on it happened when

  *
TLS 1.3 wasn't as widely deployed as it is now.

Yes, had TLS WG been involved earlier, it would have been better known I guess :)


  *
I would be inclined to just remove TLS 1.2 support from the specification, if
  *
there is agreement.

You will have to do that, since the extension can ONLY be registered for TLS 1.3


  *
> This has the effect of revealing the client's identity on the wire.


  *
It does, I guess unless encrypted DNS transport is being used.
  *
A number of other protocol mechanisms already have similar problems,
  *
don't they, like TLS client's lookup of SVCB records for ECH, etc, if
  *
not done with encrypted DNS transport.

A client looking up SVCB records does not expose the client’s identity. EKR pointed out that this doc explicitly has the server look up the client identity.

> At one point we had considered whether the client should look up
> its own DANE information and send it in an extension (the opposite
> form of RFC 9102: TLS DNSSEC chain extension), but decided that this
>might be too much complexity to impose on the client, particularly since
>some of them might be resource constrained. That topic could be revisited.

I think you should. A key point of TLS 1.3 is not to expose the client identity. As a bare minimum, if no changes are made, the security considerations should make this exposure explicit.

>could also probably shore up the language to mandate the use
>of the extension (non-empty), instead of allowing it to be omitted
>if the certificate only has one dns SAN identifier.

That seems like a good idea.

>> Below you say that the client MUST supply the client identity
>> extension if there are >1 SANs but what is the server to do
>> if the client does not?

>The server should abort the connection with an error (and maybe
>a tailored TLS alert needs to be defined).

You probably do not want a custom alert as that gives out too much information.