Re: [Uta] WGLC for draft-ietf-uta-rfc6125bis-06

[Peter Saint-Andre <[e-mail]>]

On 6/25/22 2:43 PM, Viktor Dukhovni wrote:
> On Sat, Jun 25, 2022 at 10:13:28PM +0300, Yaron Sheffer wrote:
> 
>> My question was about identity validation, which is what 6125bis is
>> about. So it's a subset of your second option, "validation of
>> certificates". And yes, this boils to, are DANE-based EE certificates
>> expected to adhere to the draft's requirements.
> 
> Yes, when the DANE TLSA certificate usages are:
> 
>      * PKIX-TA(0)    (trust-anchor constraint)
>      * PKIX-EE(1)    (pkix with EE pinning)
>      * DANE-TA(2)    (trust-anchor assertion)
> 
> But when the certificate usage is DANE-EE(3), then for some
> application protocols (notably not HTTP) it is admissible to
> ignore names and expiration in the certificate, because these
> are more than adequately handled at the DNS layer.

It might depend on what we mean by "PKIX-based". We essentially say that 
"PKIX-based" means the certificate is in X.509 format. I believe that 
all DANE certificates (even DANE-EE) are in X.509 format, although the 
specific encoding might vary; for instance, Section 2.1.1 of RFC 6698 
states:

    The certificate usages defined in this document explicitly only apply
    to PKIX-formatted certificates in DER encoding [X.690].

Thus it seems to me that 6125bis could in theory apply to all DANE usages.

However, as Viktor says, some application protocols might not require 
checking of service identifiers for usage 3 (DANE-EE). If that's the 
case, they should make that clear in the relevant protocol specification 
(but I don't think we need to do that in 6125bis).

>> And the reason I raised this question is that the draft defines its
>> own scope with these words:
>>
>> 	This document applies only to service identities that meet these
>> 	three characteristics: associated with fully-qualified domain
>> 	names (FQDNs), used with TLS and DTLS, and are PKIX-based.
> 
> Even DANE-TA(2) is "PKIX based" for validating all the certificates
> below the trust-anchor.  All that changes is the source of the trust
> anchor from local to remote via DNS.  Whether DANE-EE(3) also needs
> to adhere PKIX-rules depends on whether UKS (Unknown Key Share) attacks
> are a concern for the application in question or not.
> 
>> I wasn't sure whether "PKIX-based" should be interpreted to include
>> DANE certificates.
> 
> It does for the majority of the certificate usages, but in practice
> today DANE is primarily used with SMTP, and predominantly with
> DANE-EE(3) TLSA records, in which case identity questions are settleda
> at the DNS layer, and the presented identifiers in the certificate are
> irrelevant.

Even in this case, doesn't the certificate include a service identifier?

Peter