|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.