Re: [dane] I-D Action: draft-ietf-dane-protocol-15.txt

[Paul Hoffman <[e-mail]>]

Great stuff!

On Feb 5, 2012, at 11:49 PM, Scott Schmit wrote:

> In section 2.1.3:
> ]  Because a client support for multiple hash algorithms might be
> ]  limited, ...
> 
> Grammar: s/a client/client/ or s/a client/a client's/

Got it.

>> - Text regarding protocol-specific specifications
> 
> In section 3:
> ]  Unless there is an protocol-specific specification that is different
> ]  than this one, TLSA resource records are stored at a prefixed DNS
> ]  domain name.  The prefix is prepared in the following manner:
> 
> Grammar: s/an protocol/a protocol/

Got it.

> Unless I misread the stated consensus, this draft doesn't address the
> result of Issue 28 at all. Warren stated this was the consensus: "use
> the first name that has a TLSA record".

That's only half of what he said. The full text is "use the first name that has a TLSA record, unless there is a protocol specific exception".

> If I understand the called consensus correctly, the client should first
> do a lookup at the name provided to the client and if the TLSA record
> isn't there, check at the hostname on the right-hand side of the SRV
> record it's trying to connect to.  Draft -15 doesn't say that at all.

The draft doesn't say it because there needs to be a protocol-specific exception to know when to look. That's why we added the text we did. Given what we read from the chairs, there is only one defined "first name", namely the one that *every* protocol starts with. Anything beyond that needs to be specified, given that the lengthy discussion on the list showed that there is no agreement on how to define what the follow-up names are.

> Assuming I'm not totally off-base in my reading of the stated consensus,
> here's some proposed text:
> 
> |  TLSA resource records are stored at a DNS domain name of the form:
> |
> |      _<port>._<protocol>.<name>
> |
> |  <port>:
> |      The decimal representation of the port number on which a TLS-
> |      based service is assumed to exist.  This number has no leading
> |      zeros.
> |
> |  <protocol>:
> |      The protocol name of the transport on which a TLS-based service
> |      is assumed to exist.  The transport names defined for this
> |      protocol are "tcp", "udp" and "sctp".
> |
> |  <name>:
> |      The DNS domain name the TLSA resource record belongs to.
> |
> |  The name and port to use to look up the TLSA resource record depends
> |  on whether the protocol in use by the client uses SRV to determine
> |  the port and address of the service.
> |
> |  If SRV is not used, the client uses the domain name and port that the
> |  client was provided (e.g., by the user and/or a well-known service
> |  port) to generate the name for the TLSA lookup.
> |
> |  For example, to request a TLSA resource record for an HTTP server
> |  running TLS on port 443 at "www.example.com", you would use
> |  "_443._tcp.www.example.com" in the request.  To request a TLSA
> |  resource record for an SMTP server running the STARTTLS protocol on
> |  port 25 at "mail.example.com", you would use
> |  "_25._tcp.mail.example.com".
> |
> |  If SRV is used, the client begins with the domain name that the
> |  client was provided (e.g., by the user) and first performs a SRV
> |  lookup to get an list of port/target pairs sorted as specified by
> |  RFC 2782.  For each port/target the client is attempting to connect
> |  to, the client first performs the TLSA lookup using the port and the
> |  initial name. If that TLSA lookup returns no records, then the client
> |  performs a lookup using the port and target name.
> |
> |  For example, to request a TLSA resource record for an XMPP server
> |  with the following SRV records:
> |
> |    _xmpp-server._tcp.example.com. IN SRV 0 0 1234 xmpp.example.net.
> |    _xmpp-server._tcp.example.com. IN SRV 1 0 5678 im.example.org.
> |
> |  you would first do a TLSA lookup at "_1234._tcp.example.com". If that
> |  returns no records, you would then do a lookup at
> |  "_1234._tcp.xmpp.example.net". If you are unable to reach
> |  xmpp.example.net, you would then do a TLSA lookup at
> |  "_5678._tcp.example.com" and so on.
> |
> |  Future protocol-specific specifications may specify a different
> |  scheme for looking up TLSA records.

I think this is *way* beyond what the chairs asked us to do. If I'm wrong, I'm sure we'll hear from the chairs soon enough.

> In section 4.3:
> ]  This usage allows a domain name administrator to specify a new trust
> ]  anchor, such as if the domain issues its own certificates under its
> 
> should be, given the use case names in RFC 6394:
> |  This usage is sometimes referred to as "trust anchor assertion" and
> |  allows a domain name administrator to specify ...

Good call.

> Section 5:
> ]                                     ...  Clients that rely on another
> ]  entity to perform the DNSSEC signature validation MUST use a secure
> ]  transport between themselves and the validator.  Examples of secure
> ]  transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec
> ]  [RFC6071].  ...
> 
> Slight nit: "entity" is rather vague and could be interpreted as
> "software component" (such as the OS).  Would "host" be a better term?

No, for the exact reason you gave: it might be an OS service. We should not restrict this to "you need to go to another host".

>> - Expanded "TLSA and DANE Use Cases and Requirements"
> 
> ]  The different types of certificates associations defined in TLSA are
> 
> Grammar: s/certificates assocations/certificate assocations/

Yep

> ]  matched with various sections of [DANEUSECASES].  Three use cases
> 
> I think you can cover all 4 usage types with a reference to the use
> cases in RFC 6394, so s/Three/The/
> 
> ]  3.3 Domain-Issued Certificates  -- Implemented using certificate
> ]     usage 3.
> 
> Based on the title of section 3.3, I'd rewrite that as:
> |  3.3 Trust Anchor Assertion and Domain-Issued Certificates --
> |     Implemented using certificate usages 2 and 3, respectively.

I like this!

> In section 8.1:
> ]  In the following sections, "RFC Required" was chosen TLSA usages, and
> ]  "Specification Required" for selectors and hashes, because of the
> ]  amount of detail that is likely to be needed for implementers to
> ]  correctly implement new usages as compared to new matching types and
> ]  hash types.
> 
> Grammar: s/chosen TLSA/chosen for TLSA/

Yes.

> Also, you don't need any of the commas after the first (and they made
> the text harder to read because it made me think it was delineating a
> parenthetical clause).

I prefer the current way slightly, but if you were confused, that's good enough. (Let's see if the RFC Editor adds them back in...)

> Also, the terms used in the paragraph don't seem consistent with the
> rest of the draft/the registry names/itself. Should it read:
> |  In the following sections, "RFC Required" was chosen for TLSA usages
> |  and "Specification Required" for selectors and matching types because
> |  of the amount of detail that is likely to be needed for implementers
> |  to correctly implement new usages as compared to new selectors and
> |  matching types.

Yep

> I'm not sure if specification required is sufficient for selectors, not
> because they're going to be tremendously complex, but because some could
> be a really bad idea, at least in some cases. Imagine I wrote up a
> specification for DN matching or certificate policy matching. With
> usages 0 & 1, that would be fine, but with usages 2 & 3, that would be
> very foolish. Perhaps local client policy considering that to be weak
> would resolve that, but it's not written that broadly.

This is a good consideration for WG LC.

> The matching type registry has a similar problem, IMHO. (What about a
> URI matching type?)

Not sure how that would work.

> As far as I can tell from RFC 5226, the main difference between RFC
> required & specification required is whether the referenced document
> must have IETF consensus. Spec required will be checked for
> interoperability, but nothing more AFAICT.

This is not correct: you can get an RFC without IETF consensus, and that is actually called out in 5226.

> I realize this may never be a problem in practice but why not strengthen
> the language?

If the WG wants to change these rules, we can. It seems worth discussing in WG LC.

> In section 9 (Security Considerations):
> 
> The first two paragraphs talk about looking up A/AAAA records. Do we
> need to add SRV to that list?

No.

> Or maybe we should just refer to DNS
> records (as there is also the issue of CNAMEs, etc).

No. :-)

This is a morass that is specific to some applications that use TLS. The current spec does *not* address them. (Your proposed change for issue #28 would probably lead us to make this change.)

> Also, the considerations include:
> ]  Client treatment of any information included in the trust anchor is a
> ]  matter of local policy.  This specification does not mandate that
> ]  such information be inspected or validated by the domain name
> ]  administrator.
> 
> Should this text be expanded to include usage 3?

I believe not, but I would like to hear more. Usage 3 is "match", not "match after poking at the contents", so there is no local policy about included information. Did you think otherwise?

> Do we want to add a paragraph reminding DNS admins that record
> expiration is controlled by RRSIG expiration and not TTL, so the
> signature period should take into account how long the domain can afford
> to wait for the TLSA record to expire in the event of a server key
> compromise.

This was discussed earlier, and I thought the resolution was that it is, in fact, the TTL. The *ability to use a TLSA record* is based on the RRSIG expiration, but the signature period of a certificate is unrelated to that.

> We should probably add a reminder that clients must exercise care that
> TAs introduced by type 2 aren't usable for validation of other TLS
> connections. It should probably be a MUST somewhere in the text, but I'm
> not sure where it would best fit.

It's already there: "The TLS session that is to be set up MUST be for the specific port number and transport name that was given in the TLSA query." How would you suggest to make this stronger?

> In section 11 (with the help of id nits):
> * draft-ietf-dane-use-cases has been published as RFC 6394
> * draft-ietf-tls-rfc4347-bis has been published as RFC 6347

Good

> * Downref: Normative reference to an Informational RFC (the use cases)

I'll move the use cases down; I'm not sure why we said they were normative for implementers.

> In section A.1:
> ]   When creating TLSA record with certificate usage type 0 (CA
> Grammar: s/record/records/
> 
> ]  and 1 (SubjectPublicKeyInfo).  A careful choice is required because
> ]  the different methods for building trust chains are used by different
> Grammar: s/because the/because/
> 
> In section A.1.1:
> ]  o  The client may not have an associated root certificate in trust
> ]     store and instead uses a cross-certificate with an identical
> Grammar: s/in trust/in its trust/

Yes, yes, and yes.

> HTH


Most definitely yes!

--Paul Hoffman