Re: [dane] Last Call: <draft-ietf-dane-protocol-19.txt> (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard

[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.

Regards,
-sm



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]