On Tue, Jul 28, 2015 at 04:03:12PM -0800, Melinda Shore wrote:
> On 7/28/15 3:57 PM, Viktor Dukhovni wrote:
> > See my follow-up message. I think you should reconsider.
>
> Nothing's cast in concrete, and your point about ECC signatures
> is well-taken. We'll likely get a revision out by the end of
> August. Because this is a TLS extension we'll be working with
> the TLS working group, and it's not clear at this point what
> sort of biases they'll have that are different from the
> preferences of DNS experts.
I think that the payload of the extension really needs to be vetted
by folks with DNS expertise, and the TLS WG review mostly focused
on where the extension goes in the handshake, whether its payload
is in the clear or not, whether (as I think should be the case)
SNI is a pre-requsite to signal which domain the server starts the
validation chain from, ...
This is based in part on the architectural assumption that in many
cases the right way to process it on the client side will be a
hand-off a local DNS service.
I would also posit that also on the server, obtaining the requisite
payload might be obtained by constructing appropriate new requests
to the local DNS service (which likely has all the relevant data
in its cache).
The design of the payload should not preclude delegation of the
work of building it to a DNS service on either end. Of course if
either initially (for lack of supporting DNS services) or through
explicit design choice, some implementations prefer to do everything
in an application library, so be it, they can then construct the
appropriate DNS-compatible payload messages. Libraries to do so
are likely not too hard to find.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
