On Tue, Feb 6, 2018 at 10:39 PM, Adam Roach <a...@nostrum.com> wrote:
> On 2/6/18 9:28 PM, Viktor Dukhovni wrote: > >> >> On Feb 6, 2018, at 10:19 PM, Adam Roach <a...@nostrum.com> wrote: >>> >>> Unless I missed something important, this scenario doesn't seem to make >>> much >>> sense: if the client provides name A and the server replies with name B, >>> the >>> client either (1) isn't performing server name validation (in which case >>> it is >>> nonsense for the client to ask for a dnssec_chain), or (2) is going to >>> error >>> out the connection. Do I have that right? If there's some situation in >>> which >>> the server acting as described above provides some benefit, I would love >>> to >>> see it described in here. If it's just a matter of having completely >>> described >>> behavior for corner cases, it may be worthwhile indicating that the >>> client >>> will reject the connection if the server decides to complete the >>> handshake >>> like this. >>> >> DANE clients sometimes accept more than one name for the server. This >> happens >> when the server name is obtained indirectly from MX OR SRV records, or as >> the >> result of (DNSSEC-validated) CNAME expansion. >> > > Ah, that's an interesting point. You may want to keep this in mind when > responding to the question put forth by the GEN-ART reviewer. > > So in principle, more than one name might be acceptable to the client. In >> practice however, I don't yet see a mechanism where a client that can't do >> DNSSEC validation on its own would be in a position to do this. >> > > My understanding is that this mechanism isn't just for clients that can't > do their own DNSSEC validation; it's also intended to reduce latency for > interactive applications (web browsers and real-time-communication clients > in particular). > >> >> > Yes, that's true. But if we were to consider the MX/SRV use case, then for this specification to be complete, it would have to consider clients that are unable to validate on their own. This means the dnssec_chain extension would have to provide records that can (also) validate the MX or SRV records, which it doesn't do right now. In early discussions about the scope of this draft, I believe we decided to omit the MX/SRV case to keep things simple. This is why the draft only references RFC 6698 and 7671, and not 7672 and 7673. (Well it mentions 7672 only tangentially to suggest that such clients likely won't need this mechanism). Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
