On 12. 4. 2012, at 9:11, SM wrote:
> At 18:41 11-04-2012, The IESG wrote:
>> The IESG has received a request from the DNS-based Authentication of
>> Named Entities WG (dane) to consider the following document:
>> - 'The DNS-Based Authentication of Named Entities (DANE) Protocol for
>> Transport Layer Security (TLS)'
>> <draft-ietf-dane-protocol-19.txt> as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@xxxxxxxx mailing lists by 2012-04-25. Exceptionally, comments may be
>
> In Section 1.2:
>
> "This document applies to both TLS [RFC5246]"
>
> Does this mean that DANE is not applicable for TLS 1.1?
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.
> In Section 1.3:
>
> "A DNS query can return multiple certificate associations, such as in
> the case of a server is changing from one certificate to another."
>
> The sentence seems incorrect.
Dave already commented on this. I also don't see anything wrong with the
sentence.
> In Section 2.1.1:
>
> "The certificate usages defined in this document explicitly only apply
> to PKIX-formatted certificates in DER encoding."
>
> I suggest adding a reference to X.690.
Seems reasonable.
> In Section 2.1.3:
>
> "If the TLSA record's matching type is a hash, having the record use
> the same hash algorithm that was used in the signature in the
> certificate (if possible) will assist clients that support a small
> number of hash algorithms."
>
> As a comment that does not argue for any change, having SHA-256 hash as the "lowest" hash excludes SHA-1, a widely deployed hash algorithm. I gather that the WG has made a tradeoff between perceived security and ease of deployment.
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 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).
> In Section 3:
>
> 'For example, to request a TLSA resource record for an HTTP server
> running TLS on port 443 at "www.example.com",
> "_443._tcp.www.example.com" is used in the request. To request a
> TLSA resource record for an SMTP server running the STARTTLS protocol
> on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
> used.'
>
> HTTPS for www.example.com is a straight-forward example. In the case of a SMTP server, it is not as easy. Once the target host is located, mail.example.com in this case, one might assume that the server would advertise that hostname or the domain name used to locate the target host as an identity. That's rarely the case due to issues outside the scope of DANE. It's easier not to use the STARTTLS protocol as an example.
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.
> In Section 7.2, 7.3 and 7.4:
>
> "Applications to the registry can request specific values that have
> yet to be assigned."
>
> What is the meaning of "can request specific values" in that sentence?
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).
> In Section 8.1:
>
> "If it is less likely that a user will hear about its trusted DNSSEC
> validators being hacked that it is of a public CA being compromised"
>
> I suggest using "compromised" instead of "hacked".
lgtm
O.
--
Ondřej Surý
vedoucí výzkumu/Head of R&D department
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej.sury@xxxxxx http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------