On Tue, Aug 04, 2015 at 10:05:12AM -0700, Alissa Cooper wrote:
> Section 4:
> s/generally RECOMMENDED./RECOMMENDED./
> s/a mixture of clients; some supporting/a mixture of clients, some
> supporting/
Sure.
> Section 4.2:
> I note that this section is silent about the interaction between CT and
> the PKIX-TA(0) and PKIX-EE(1) usages. I'm assuming the implication is "go
> ahead and use CT if you want to in those cases," but whatever it is,
> might it be worth making it explicit here?
Yes, full steam ahead with PKIX-TA/PKIX-EE. I'll add something
suitably concise to that effect.
>
> Section 10.3:
> "A service with DNSSEC-validated TLSA records implicitly promises TLS
> support. When all the TLSA records for a service are found
> "unusable", due to unsupported parameter combinations or malformed
> associated data, DANE clients cannot authenticate the service
> certificate chain. When authenticated TLS is mandatory, the client
> SHOULD NOT connect to the associated server."
>
> Seems like that last requirement should be a MUST NOT.
Yes, MUST NOT will do.
>
> Section 14:
> "When TLS is opportunistic, the client MAY proceed to use
> the server with mandatory unauthenticated TLS."
>
> I find the use of the word "mandatory" here confusing -- what is
> mandatory in the opportunistic case? Seems like this would make more
> sense without the word "mandatory."
Good catch, this is unclear. When the client is using TLS and DANE
opportunistically, and finds TLSA records all which happen to be
"unusable", to avoid downgrade attacks to cleartext, it MUST still
use TLS, but without (DANE) authentication (which is not possible).
This is already specified in the SRV and SMTP drafts. In this
draft it is stated more generally.
Will fix.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
