Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12

[Paul Wouters <[e-mail]>]

On Sat, 11 Jul 2015, Viktor Dukhovni wrote:

>> * Section 4.8, page 8:
>>> Therefore, when a TLS client
>>> authenticates the TLS server via a TLSA record with usage DANE-EE(3),
>>> CT checks SHOULD NOT be performed.
>>
>> What are the valid reasons for performing th CT checks? If there are not
>> any, why not make this requirement a "MUST NOT" instead?

CT auditors log EE-certs. Checking the CT logs also provides a way to
signal rogue EE-certs to the original webserver via a gossip/client
protocol. So I would not say Usage 3 should never check the CT logs.

> CT checks are designed to help keep public CAs honest (detect
> surreptitiously misissued certificates).

It's a litte more than just that:

    Certificate transparency aims to mitigate the problem of misissued
    certificates by providing publicly auditable, append-only, untrusted
    logs of all issued certificates.  The logs are publicly auditable so
    that it is possible for anyone to verify the correctness of each log
    and to monitor when new certificates are added to it.


>  With DANE-EE(3), no public
> CA is involved, so CT (for the X.509 WebPKI) is logically out of
> scope.

I don't think that whether or not public/private CA's are in used in
the TLSA record matters. A client that wants to confirm an EE-cert
via DNSSEC _and_ CT should be able to do so.

>> * Section 5.1, page 10:
>>> Servers SHOULD NOT rely on
>>> "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
>>> data for raw public keys.
>
> I am open to MUST NOT, if that's better.
>
> Note that the impact of such inadvisable reliance, is that some
> clients capable of using raw public keys (but also capable of
> handling certificate chains) might choose to not do so.  And other
> clients, that support only raw public keys, might go the extra mile
> and support extracing the public key from a "3 0 0" record, assuming
> they can parse X.509 certificates (part of the rationale for RPK
> is to allow clients to shed such code).

You keep trying to force different policies for raw public keys versus
(possibly throw away) x509 container based public keys. Because we know
software will only upgrade over a very long slow time, we know there
is going to be a substantial amount of time when "basically" raw keys
will go into a throw-away x509 container. Therefor, as I said before,
it is not wise to differentiate between the two. An EE-cert could be
a raw public key in disguise purely for compatibility reasons.

> So using "3 0 0" reduces opportunities to use RPK, and might fail
> to interoperate with RPK-only DANE clients that don't go the extra
> mile to support "3 0 0" (e.g. they may lack code to parse X.509
> certificates).  Is that enough reason to say "MUST NOT rely"?
>
> Is 2119 language appropriate here, we're not telling servers to
> not publish "3 0 0", rather we're telling them that if they do,
> they can't (must not) expect RPK to work.  Is "MUST NOT rely"
> or "SHOULD NOT rely" a suitable means to say that, or should
> this be downcased to non-normative english text?

No, I think you should not try to dictate the local policy behaviour.

> This was changed in -13:
>
>   If a server uses just DANE-EE(3) TLSA records, and all its clients
>   are DANE clients, the server need not employ SNI (i.e., they may
>   ignore the client's SNI message) even when the server is known via
>   multiple domain names that would otherwise require separate
>   certificates.

I am confused. If DANE is only talking about how to verify a certain
certificate received over TLS, I do not think this document should
modify the TLS protocol with respect to SNI. It's out of scope.

Paul