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

[Viktor Dukhovni <[e-mail]>]

> * Meta: I would have liked to find (if anything, in an appendix) the
> rationale for he changes being proposed by this document. Since the changes
> are said to originate on operational experience, I think that codifying
> the lessons (problems found, and a rationale for the workarounds). There
> seems to be a bit of this throughout the document, but not for most of
> the changes proposed.

I'll reread the draft and see where additional rationale text might
usefully be added.  Specific pointers to such places, if anyone
has any in mind, would be great.

> * 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 checks are designed to help keep public CAs honest (detect
surreptitiously misissued certificates).  With DANE-EE(3), no public
CA is involved, so CT (for the X.509 WebPKI) is logically out of
scope.  

If there is some day a CT for DNSSEC (or just DANE records validated
via DNSSEC), then this new CT might be applicable to keep registries
from signing rogue DS RRs, rogue evidence of non-existence of DS
RRs or rogue absense of delegation of a domain.  The present the
experimental CT does not apply to DNSSEC.  Also see changes in
the CT language in -13.

> * 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).

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?

> * Section 7, page 17:
>
> >    Though CNAMEs are illegal on the right hand side of most indirection
> >    records, such as MX and SRV records, they are supported by some
> >    implementations.  For example, if the MX or SRV host is a CNAME
> >    alias, some implementations may "chase" the CNAME.  If they do, they
> >    SHOULD use the target hostname as the preferred TLSA base domain as
> >    described above (and if the TLSA records are found there, use the
> >    CNAME expanded domain also in SNI and certificate name checks).
> 
> If CNAMES on the right hand side of most indirection records are illegal,
> why trying to process them in the first place?

Because this "illegal" configuration is both widely supported, and
actually practiced, sometimes by accident.  There are a lot of
domains with boiler-plate records configured by naive registrars
or users along the lines of:

	example.com.	IN A 192.0.2.1
	example.com.	IN MX 0 mail.example.com.
	; Note, no explicit mail.example.com RRsets
	*.example.com   IN CNAME example.com.

What this amounts to is that that the MX host for example.com is
mail.example.com which is in turn a CNAME right back to example.com.
Most MTAs seem to support this, RFCs notwithstanding.

So the draft explains what to do when such records are supported.
(A concession to the fact that MX hosts that are CNAMES are illegal
in theory, but not in practice).

> * Section 9, page 21:
> > This order SHOULD be configurable by the MTA
> >    administrator. 
> 
> Please expand "MTA". Also, why make the explanation mail-specific?

Fixed in -13.

> * Section 13, page 26:
> >    The signature validity period for TLSA records should also not be too
> >    long.  Signed DNSSEC records can be replayed by an MiTM attacker
> >    provided the signatures have not yet expired. 
> 
> Please expand "MiTM".

This was done in the introduction, but I notice a case difference
(MiTM vs MITM).  This should probably be made consistent in the
final version.  Queued for -14.

> Section 1.1, Page 4:
> >       difficult to host multiple Customer Domains at the same IP-
> >       addressed based TLS service endpoint (i.e., "secure virtual
> >       hosting").
> 
> s/addressed based/address-based/

Thanks, queued for -14.

> * Section 5.1, page 9:
> 
> >    With DANE-EE(3) servers that know all the connecting clients are
> >    making use of DANE, they need not employ SNI
> 
> I'm having trouble parsing this sentence... could you please take a look and tweak it if necessary?

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 notice a singular/plural mismatch above, so in -14 I've queued-up

    s/they may/it may/.

Is the final result better?

-- 
	Viktor.