Re: [TLS] AD Review of draft-ietf-tls-tls13

On Tue, May 16, 2017 at 12:37 PM, Viktor Dukhovni
<ietf-dane@dukhovni.org> wrote:
>
>> On May 16, 2017, at 11:36 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> OK, does that put us back to the suggested wording:
>>
>>    "TLS depends on certificate path validation, and a conformant
>>     TLS implementation MUST implement certificate paths validation
>>     in a manner that achieves the same result as [RFC5280]. This
>>     section provides TLS-specific requirements.”
>>
>> For any developers following, does this help enough with any
>> interoperability questions?
>
> TLS does not depend on certificate path validation.  Many TLS
> *applications* rely PKIX certificate path validation (along with
> RFC 6125 server identity verification), but TLS itself supports
> various alternative authentication (and non-authentication) modes.
>
>    * PSK or SRP without certificates
>    * Opportunistic unauthenticated TLS (perhaps anon-(EC)DH with TLS <= 1.2)
>    * TOFU public key pinning
>    * Static leaf key or leaf cert matching
>    * RFC7250 raw public keys
>    * DANE-EE(3) leaf certificate/key verification, without expiration
>      or server name checks
>    * DANE-EE(3) ... with name checks (where UKS attack are relevant)
>    * DANE-TA(2) with RFC5280 chain verification, but the trust-anchor
>      is part of the chain, and identified via DNS TLSA records.
>    * PKIX-EE(1) which is RFC5280 + DANE leaf cert "constraint"
>    * PKIX-TA(0) which is RFC5280 + DANE CA "constraint"
>
> Keeping in mind that many implementations of RFC5280 violate that specification
> by interpreting EKUs in CA certificates to constrain the kinds of certificates
> that the CA may issue.  That de-facto usage is I think much more widely implemented
> than the far too complex X.509 policy constraints (RFC5280 4.2.1.11).

Sorry, I grabbed the wrong text as I was ineffective at multi-tasking.
I think we are back to the following text and would like to confirm
that and make sure it is agreeable to the WG and implementers:

    "In general detailed certificate validation procedures are out of
    scope for TLS. [RFC5280] provides general procedures for
    certificate validation. This section provides TLS-specific
    requirements."

There's also a thread that was discussing some interoperability
problems related to validation and I'd like to see the resolution for
that as well.

Thanks,
Kathleen

>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 

Best regards,
Kathleen