At 03:48 12-04-2012, Ond ej Surý wrote:
RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make references
to obsoleted documents. As a side note, we don't say "to both TLS 1.2", but
just TLS.
Not really.
On an unrelated note,
draft-ietf-mile-rfc6046-bis-09 should reference
RFC 4346 normatively instead of the informative
reference. The was a discussion about a protocol
where the argument was MUST implement TLS 1.1 and SHOULD implement TLS 1.1.
SHA-2 was first published 11 years ago and I don't really think that
applications which will decide to implement DANE will not have support
for SHA-2 family.
The date of publication of a specification
doesn't materially affect what's available out there.
The quoted sentence just says: Use closest available algorithm to help
clients (e.g. please don't use SHA-3 if the certificate signature is SHA-256).
I'm ok with SHA-2 btw.
Here the rules from RFC3207 can be applied:
The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
Similar logic applies to DANE, but it's not the DANE which decides the
name, but TLS capable client, which already know which name to expect.
I have read the rules from RFC 3207. You could
use the above the declare the issue as out of
scope. However, if you take that path, it's
better to drop the example as well.
It's just a note, that we expect that future standards would be able
to assign new values (f.e. new hash algorithms when SHA-3 is out).
This is IANA paperwork. You don't really have to
fix it. Someone reading that text literally
might presume that you can request a "specific"
value. It seems to me that the objective is not
about having to deal with applications for lucky numbers.
This draft faces problems which are similar to
what RFC 6125 tried to tackle. RFC 6125 does not
fix the Application protocols mess. There was a
mention of deployment on the DANE mailing
list. DANE is conditional on DNSSEC
deployment. It is conditional on applications
using it. Although it's not up to the working
group to tackle all that, you'll end up with half
a solution as long as you don't tackle issues relating to RFC 6125.
Section 1 of the draft is well-written. There
were some comments by other participants about Section 8. For example:
"Current public CAs are assumed to have better defenses than current
DNSSEC validators, but that perception cannot be proven one way or
another. Similarly, if DNSSEC validation becomes more common after
the release of this document, it cannot be predicted whether or not
that will increase the level of security of DNSSEC validators more or
less than the security of public CAs. Thus, it is difficult to
foresee which system has a higher risk."
I would not make the assumption mentions in the
first sentence of that paragraph. I don't mind
if the working group decides that it is appropriate to make that assumption.
Parts of Section 8.2 about DNS caching could be
moved outside the Security Consideration
section. It is more useful as guidance for
application implementations of the protocol.
Regards,
-sm