Subject: [dane] New protocol draft

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Aug 2011 08:53:00 -0700

Diffs at <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-10>.

Based on the discussion at the meeting in Québec, we have made Appendix A operational issues of deploying TLSA records. We have rewritten the text in that section to be in a more operational light, and would very much appreciate input on the wording.

We also added a new appendix, B, which is pseudocode for TLS resolution with DANE. This section definitely needs careful review. If we muffed the pseudocode, we need to fix it, but we also probably need to be clearer in the main document about how the resolution works.

Neither of these requests should deter people from commenting on the issues that the WG chairs are opening; we can juggle them all. We hope that the chairs open a few more issues at once so that we can get this work finished in a reasonable amount of time.

--Paul Hoffman

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Aug 2011 23:51:12 +0300

On Mon, Aug 15, 2011 at 08:53:00AM -0700, Paul Hoffman wrote:
> We also added a new appendix, B, which is pseudocode for TLS resolution
> with DANE. This section definitely needs careful review. If we muffed the
> pseudocode, we need to fix it, but we also probably need to be clearer in
> the main document about how the resolution works.

Looks like you have mismatch between the code and the spec:

What happens if one has the following:

_443._tcp.foo.example. IN TLSA 1 3 b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c
(and nonthing else)

I.e. Known certificate type but unknown reference type. Right now the code
tries to invoke unknown hash and then presumably rejects the server.

AFAIK, the text specifies that fallback to legacy authentication should occur.

-Ilari