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

[Tina TSOU <[e-mail]>]

Dear all,  

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments that arrive in timely manner, and not significantly belated.

I've found this document well-written. I believe it is ready for publication modulo some small issues that can hopefully be addressed prior to publication:


**** Technical *****

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


* 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?


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

Same here.


* 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?



* Section 9, page 21:
> This order SHOULD be configurable by the MTA
>    administrator. 

Please expand "MTA". Also, why make the explanation mail-specific?


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



**** Nits *****

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/


Section 4.2, page 8:
> Publication of the server
>    certificate or public key (digest) in a TLSA record in a DNSSEC
>    signed zone by the domain owner assures the TLS client that the
>    certificate is not an unauthorized certificate issued by a rogue CA
>    without the domain owner's consent.

Avoiding the double-negation improves clarity... i.e., please change to "...is an authorized certificate issued by a rogue CA
    without the domain owner's consent"


* 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?


Thank you,
Tina