> On Nov 5, 2018, at 10:27 PM, Benjamin Kaduk <bka...@akamai.com> wrote:
>
> This seems to suggest that we may need more precise text in the
> document about what it is (and is not) trying to do. The slides Sean
> posted for the Wednesday session note that fairly early in the timeline
> we thought:
>
> Primarily aimed at making
> DANE practical for HTTPS,
> where last-mile considerations
> on the client end are a
> significant part of the adoption
> barrier.
>
> Paul, are you proposing that this would only be PKIX-{EE,CA} to the
> exclusion of DANE-{EE,CA}? (In terms of "restricts the webpki".)
I think that deciding which DANE usage are most appropriate for
browsers is up to the folks who think deeply about Web browsers
and Web servers, and I would not presume to tell them which model
they should find more attractive. My expectation would be that
they would be more comfortable with PKIX-{EE,TA}, because that
gives both the strongest security guarantee and preserves
certificate transparency as an option.
In SMTP, I got consensus for just specifying DANE-{EE,TA}, but
for HTTP I can well imagine a different outcome. The key reason
for the divergence is that SMTP security depends critically on
the integrity of MX records, so if you DNS is compromised PKI
does not help much.
HTTP does not use MX, SRV or similar indirection, so the analysis
comes out differently.
This draft will not define a single approach for all applications,
that's up to the various application area specialists to figure out.
--
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
