Add text on MITMs, and misc changes #2
Conversation
| @@ -320,7 +321,7 @@ | |||
|
|
|||
| <t> | |||
| The order of returned RRsets is unspecified and a TLS client MUST NOT | |||
| assume any ordering of RRsets. | |||
| assume any ordering of RRsets other than that RRsigs follow each RRset. | |||
There was a problem hiding this comment.
I've now seen multiple cases of RRset not immediately followed by its RRSIG from nameservers, so we'll not make this change...
| <t> | ||
| Each zone in the DANE chain validation path for a domainname can | ||
| impersonate the server to any client. A mitigation is for clients | ||
| to prefer or require TLSA usage 2, binding a WebPKI issuer as the |
There was a problem hiding this comment.
s/prefer or//, and that would be usages PKIX-TA(0) and PKIX-EE(1).
There was a problem hiding this comment.
The impersonation happens in DNS, not in the TLSA chain only. If the server generates the chain from public data, it is the public DNS data that is "wrong", but one might of course argue that the parents are always "right". If you have a rogue parent, no TLSA usage won't help you and adding trust into webpki parties just dilutes the trust and increases the attack surface by all the CAs - something we are explicitly trying to move away from with a DNSSEC based PKI. So I am opposed to introducing that now here.
| is for clients that can to separately lookup the DANE chain up to | ||
| the last zone delegation identified in the TLS DNSSEC chain | ||
| extension, and verify that they match. | ||
| </t> |
There was a problem hiding this comment.
I don't understand the text:
A less practical / less likely mitigation
is for clients that can to separately lookup the DANE chain up to
the last zone delegation identified in the TLS DNSSEC chain
extension, and verify that they match.
| DNSSEC need only log changes in signed delegations (both, changes | ||
| to unsigned, as well as DS RRset changes), which are much less | ||
| frequent than WebPKI end-entity certificate issuance or TLSA RRset | ||
| signing. |
There was a problem hiding this comment.
I'd like to hear Paul's thoughts on this...
There was a problem hiding this comment.
There are thoughts about CT-DNSSEC, but I don't think this doument should or need to reference it.
No description provided.