On Wed, May 13, 2015 at 05:15:03PM -0700, John Gilmore wrote:
> > I've still not heard anything from Paul Wouters or John Gilmore
> > about any additional text they might want to see in support of Raw
> > Public Keys (RFC 7250). Perhaps the present text is sufficient.
>
> I took a brief look at the draft, and I don't think the present
> text is sufficient.
Thanks for reply. I was hoping you'd chime in!
> It doesn't explicitly repeal the requirement that TLSA records can
> only be used with X.509 certificates. When there's a bald statement
> to that effect prominently in RFC 6698, it's not sufficient for a
> minor paragraph halfway through minor section 5.1 in the middle of a
> subsequent document to show a counterexample. As courts are fond of
> saying, Congress does not hide elephants in mouseholes. Standards
> committees shouldn't either. The X.509 requirement needs to be
> plainly, succinctly and obviously repealed.
Do you have specific suggested language? It might reduce the number
of back and forths if you're willing to make the first step in the
desired direction. Otherwise, Wes or I will have to give it a go,
but I'm leaving on vacation on Sunday, so cycles are very limited.
> I think the same is true of the RFC 6698 requirement that TLSA only be
> used with TLS and https. The port number prefix avoids confusion and
> overhead when authenticating multiple protocols that are used with the
> same host.
I don't see any HTTPS requirement in 6698, just TLS. Thus, SMTP
with STARTTLS on port 25 is using TLSA records, as is XMPP. What
additional protocols over TCP that employ certificates, but not
TLS did you have in mind? I don't recall much discussion of that
possibility in this WG, and it certainly goes beyond RFC 7250 (still
TLS) support. I am not opposed if the shoe fits, but I think that's
very new, and would probably need a separate draft.
> There seems to be an entire section of the draft that says it does not
> represent the consensus of the WG and that maybe it belongs in a
> separate document. Section 9 is pointed out as not-conensus by
> Section 12. Why is such a section still sitting in a draft that's
> supposedly in last call?
It seems I neglected to remove the weasel words. Perhaps we can
have a consensus call on Digest Agility.
> Section 9 also seems to say that if you have two valid TLSA records,
> one of which specifies a full key and the other of which uses a
> digest, a client can't use the one with a full key even if it is
> identical to the key used in the TLS negotiation?
That's certainly NOT the intention. I guess the language needs to
be more clear. Matching type Full(0) keys are not intended to be
skipped even in the presence of digests. Rather, section 9 is
about agility between digest algoritms (allowing weaker algorithms to
be ignored in the presence of records with stronger algorithms).
> It also seems to
> say that if the server doesn't publish any TLSA records that use the
> client's favorite BetterAlg, then the client should not authenticate
> the server, even if the client supports WorseAlg and the server
> publishes WorseAlg TLSA records.
That also NOT the intention. Again the text applies only when BOTH
appear in the TLSA record. The client can ignore some of the
published records when ones with a more favoured algorithm are
*present*.
This is what's implemented in Postfix, and I hope to have similar
logic in OpenSSL in the not too distant future.
I'll put together more clear language for Section 9 promptly.
Thanks again.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
