Hi, Viktor.
Thanks for the quick response. I'll wait for the revised draft to
revisit the RFC 2118 stuff.
I think the TLS1.2 point and the reference to RFC6781 probably need to
be discussed with Stephen as your AD. I can't see that you can operate
DANE without a good understanding of how to operate DNSSEC (particularly
on the rekeying aspects) and you explicitly call out timeout issues
discussed in RFC6781. Whether this needs to administrative hassle of
the downref is another matter.
There is a bit about the OS issue in line below.
Cheers,
Elwyn
On 22/06/2015 19:52, Viktor Dukhovni wrote:
On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote:
Summary: Almost ready. There are a couple of minor issues, and I think
the authors need to reassess whether all the cases where RFC 2119 keyworrds
are actually protocol requirements as opposed to operation best practice
recommendations.
Thanks, will double-check the SHOULDS/MUSTS/...
s3: I am not a security expert, but I suspect you may get some pushback on
not making TLS 1.2 mandatory.
We'll see what happens. The most widely deployed use of DANE is
with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like
an unnecessary restriction for an opportunistic protocol. However,
non-support of TLS 1.2 is getting increasingly less common, so if
push comes to shove, we can "require" TLS 1.2. Of course with no
Internet Police to enforce this, the requirement will likely make
little difference in practice.
TLS clients and servers using DANE SHOULD support the
"Server Name Indication" (SNI) extension of TLS.
Under what circumstances would it be reasonable for a DANE/TLSA server not
to support SNI? Maybe I could see that a single domain server could do
without it.
That's the primary use case, a server with a single certificate,
and a "3 1 1" TLSA record has no need to support SNI. It can just
respond with the same default certificate, regardless of the SNI
extension value sent by the client.
I think this needs to be spelt out - earlier text seems to
indicate that SNI support was pretty much mandatory.... Ah! Later I see that
s5.1 gives a case where SNI is not mandatory - a forward pointer would help.
Thanks, will try to make the text more consistent throughout.
s4.1: I am not clear that this section adds any value to the discussion in
s4. Why should the protocol designer be less inclined to use PKIX-xx rather
than DANE-xx when the protocol supports an OS mode as opposed to just fully
authenticated or fully authenticated plus cleartext modes?
The basic principle is based on RFC7435. The issue is that PKIX
is more brittle, the client and server must happen to agree on a
mutually trusted CA, but with OS the client is just trying to
protect the communication at the request of the server, and would
otherwise be willing to use cleartext or unauthenticated TLS. Use
of fragile mechanisms (like public CA authentication for some
unspecified set of trusted CAs) is not sufficiently reliable.
Since the OS client is basing the decision to employ DANE on the
presence of TLSA RRs in DNS, no additional security is gained via
the PKIX usages unless they are the only ones supported by the
application protocol (the attacker who compromises DNS can just
inject "3 1 1" records instead). So DANE-xx is more reliable
at no security loss. Thus PKIX-xx is just a needless opportunity
to fail that should be avoided.
Maybe I have misunderstood how OS is intended to behave. I thought I
understood that if the client was able to handle OS and it was not able
to authenticate the server then it would potentially try for encryption
only. Is the problem that there is a difference between there being no
authentication available for a domain and an attempted authentication
failing (aside from any explicit policy declared by server or client)
when using OS? Otherwise I can't see that there is a difference between
OS and the general case - in either case, using PKIX-xx is reckoned to
be fragile and the process takes more resources without gaining
anything. I can see the downside, but it appears to be general - is
there an upside for OS in positively going for DANE-xx or is the
downside further down in the case of OS? Otherwise there doesn't seem to
be a lot of point in being more damning for the OS case (apart from it
being a current topic of development :-) ).
Nits/editorial comments:
=====================
Will review those... thanks.
s17.2: I can't decide whether I would like RFC6781 to be normative. It would
of course be a downref. This is always going to be a problem since the
draft is combining operational considerations and protocol updates. The
one explicit reference indicates you have to know something about how to run
DNSSEC to run DANE - in practice I think you have to know a great deal about
how to run DNSSEC if you are going to run DANE so I would be inclined to
make this normative (and maybe refer to it in the introduction as well).
Not sure what if anything to do about that.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
