On Mon, Jan 26, 2026 at 7:38 AM Shumon Huque <[email protected]> wrote: > > On Mon, Dec 15, 2025 at 1:23 PM Eric Rescorla <[email protected]> wrote: > I would be inclined to just remove TLS 1.2 support from the specification, if > there is agreement. That would also simplify the description of the TLS > changes quite a bit.
Well, there's really no other option at this point because you're just not allowed to extent TLS 1.2. > > # Revealing the Client's Identity > > > > In TLS 1.3, the client's certificate is encrypted, but then this > > document explicitly asks the server to look up the TLSA record > > for the client's identity in the DNS in S 7. > > > > * Construct the DNS query name for the corresponding TLSA record. > > If the TLS DANE client identity extension was present, then this > > name should be used. Otherwise, identities from the client > > certificate are used. > > > > * Look up the TLSA record set in the DNS. The response MUST be > > cryptographically validated using DNSSEC. The server could > > perform DNSSEC validation itself, authenticating the full chain > > back to a configured trust anchor (normally the DNS root). > > Alternatively, it could also be configured to trust responses > > obtained via a validating resolver to which it has a secure > > connection, by requiring the Authenticated Data (AD) bit to be set > > in the responses. If DNSSEC validation fails, the server MUST > > treat the client as unauthenticated. > > > > 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. I don't see how this is relevant. One of the privacy features of TLS 1.3 is to encrypt the client's certificate. This extension effectively pulls the certificate out of the handshake, thus removing that encryption. That's a privacy regression. The situation with ECH is different in that without ECH the TLS handshake doesn't protect the server's identity at all (it's in the SNI), so we're making an incremental improvement. > > Although the connection identifier is not provided, as a practical > > matter an observer can determine this from timing. As far as I can > > tell, there is no technical reason for this design; instead the client > > should supply its DANE information as a Certificate extension > > (permitted in TLS 1.3). This will then be encrypted. > > 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. > > A hybrid design could be contemplated, where the client looks up and > supplied just its DANE record (and signature, and any associated CNAME/ > DNAME chains), and have the server additionally query and validate the rest > of the DNSSEC chain leading up to it. I don't understand what you're optimizing for. What resource constraints do you believe the client is operating under? > > # Cross-Protocol Attacks > > > > S 2.1 of client-auth contemplates that the client might have multiple identities > > corresponding to different applications. If these services have the > > same public key, it appears that an attacker could mount a > > cross-protocol attack there traffic is redirected from one service to > > another. > > We could state that those different identifiers should have different > keys. (There might be temptation to use a DNS wildcard to map all > service identities for the same client to a common DANE record with > a common cert/public key, but we could have text that discourages this). > > > Arguably, this attack already exists if the server uses the same > > identity for both protocols, but it seems possible that there might be > > a setting in which this was inferred solely from something like the > > client IP address. In any case, it seems like it would be better for > > the service identifier to be included in the transcript. > > Isn't the service identity already included in the transcript by > virtue of it being specified in the dane-client-id extension? We > 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. As you say, you don't require it. I suspect that would help but haven't thought through that entirely. > > # Indicating Certificate Presence > > > > Section 2 of client-auth states: > > > > which one the server should use. An additional situation in which > > this extension helps is where some TLS servers may need to > > selectively prompt for client certificate credentials only for > > clients that are equipped to provide certificates. > > > > However, that doesn't work with TLS 1.3 if the server send sthe > > extension in CR, because CR appears first. Instead, you want > > something in CH, like https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/. > > Yes, this text is a relic of the pre TLS 1.3 version of this document. > I agree that the Request-MTLS flag is a better solution to this > problem. We can reference that. Well, you're going to need your own flag. > > > > * Construct the DNS query name for the corresponding TLSA record. > > If the TLS DANE client identity extension was present, then this > > name should be used. Otherwise, identities from the client > > certificate are used. > > > > 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). I don't think you should define a new alert. You just need to say that you abort wit alert X. > > The wire format of a domain name is limited to 255 octets. In > > keeping with the practice of most TLS extensions, this extension > > specifies the use of the textual presentation format of domain names > > instead. In theory, the presentation format can exceed 255 > > characters because it allows the expression of any arbitrary octet > > with the "\DDD" sequence of characters (where DDD is the decimal > > value). Applications using this extension (and the DANE TLSA Client > > Authentication protocol more generally) should ensure that client > > domain names being used do not need to resort to the \DDD syntax by > > limiting the alphabet suitably, such as only allowing letters, > > digits, hyphens, and underscores. This ensures that the presentation > > format client domain name will comfortably fit within the 255 octet > > limit. > > > > Why not just allow 2^16-1? > > > > We could. > > But the general consensus was that we didn't want to support arbitrary > domain name syntax, and expect that client names would conform to the > typical hostname alphabet. In which case 2^8-1 is sufficient. Well, then I think you need to have a bunch of MUSTs here about how you have to use LDH and MUST not use \DDD or something. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
