The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
draft-ietf-dane-protocol-23

[Ballot comment]
  Section 1.3 says:
  >
  > This document only applies to PKIX [RFC5280] certificates, not
  > certificates of other formats.  Later updates to this document might
  > specify how to use certificates in other formats.
  >
  I suggest that the second sentence be deleted.  Neither the TLS charter
  nor the DANE charter calls for support of new certificate formats.

  An informative reference to define "SSL proxy" would be very helpful.

[Ballot discuss]
Updated based on exchanges with Paul.

1) Don't you need to specify how SPKI is encoded:

  The SubjectPublicKeyInfo is a binary structure defined in [RFC5280].

be:

  The SubjectPublicKeyInfo is a DER-encoded structured defined in [RFC5280].

2) I misunderstood - cleared.

3) I misunderstood - cleared.

4) s4.1: Normally I'd say these two were comments, but I know the 2nd to last paragraph came about of about 1M messages and I want to make sure these have some teeth.

Shouldn't the should be SHOULD in the following:

If a request for a TLSA record
does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication
that TLSA was applied.

Further shouldn't the not be NOT in the following:

If an application has a configuration setting
for turning on TLSA use, or has any indication that TLSA is in use
(regardless of whether or not this is configurable), that application
MUST not start a TLS connection or abort a TLS handshake if either of
the two criteria above are not met.

5) s4.1.1: The 2nd to last paragraph in question discusses certificate usages 0 and 1, but not 2 and 3.  Did the WG punt on this type of a paragraph for usages 2 and 3?

6) cleared

[Ballot discuss]
1) Don't you need to specify how SPKI is encoded:

  The SubjectPublicKeyInfo is a binary structure defined in [RFC5280].

be:

  The SubjectPublicKeyInfo is a DER-encoded structured defined in [RFC5280].

2) s2.1.4: Why does s2.1.4 not discuss type 3?  Is the CAD not used with type 3?

3) s4.1: I might not be following along (or maybe this is just a typo but I'm not sure), it says:

If an application
receives one or more usable certificate associations, it attempts to
match each certificate association with the TLS server's end entity
certificate until a successful match is found.

Doesn't this apply only to type 1?  If the type is 0 then this will never be true because the certificate association is to the CA but the TLS server's certificate is for an end-entity.  I just think this might need to be reworded.

4) s4.1: Normally I'd say these two were comments, but I know the 2nd to last paragraph came about of about 1M messages and I want to make sure these have some teeth.

Shouldn't the should be SHOULD in the following:

If a request for a TLSA record
does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication
that TLSA was applied.

Further shouldn't the not be NOT in the following:

If an application has a configuration setting
for turning on TLSA use, or has any indication that TLSA is in use
(regardless of whether or not this is configurable), that application
MUST not start a TLS connection or abort a TLS handshake if either of
the two criteria above are not met.

5) s4.1.1: The 2nd to last paragraph in question discusses certificate usages 0 and 1, but not 2 and 3.  Did the WG punt on this type of a paragraph for usages 2 and 3?

6) s8.1.1: Contains the following:

These trust
anchors are selected carefully, but with a desire for broad
interoperability.

They're chosen carefully or you paid enough to get them in the root store?  Any chance for a pointer to how "carefully" they are selected?

[Ballot comment]
1) s1: Probably splitting hairs, but I think the certificate isn't the key - it's that the key is "in" the certificate:

OLD:

Having a certificate for a key is only helpful if
one trusts the other key that signed the certificate.

NEW:

Having a key in a certificate is only helpful if
one trusts the other key that signed the certificate.

2) s1:  Again, maybe just nit picking:

OLD:

CAs protect their secret
key vigorously, while supplying their public key to the software
vendors who build TLS clients.

NEW:

CAs protect their secret key vigorously, while supplying their
public key in a certificate to the software
vendors who build TLS clients.

3) This kind of jumped out at me:

DANE is envisioned as a
preferable basis for binding public keys to DNS names, because the
entities that vouch for the binding of public key data to DNS names
are the same entities responsible for managing the DNS names in
question.

isn't this supposed to be about "public keys in certificates to DNS names" .

4) s1.2: In s1.1 you used the term "public CA" and here you saying "external CA" shouldn't we use the same terminology?

5) s2.1.1, usage 1: r/that must be/that MUST be

6) s2.1.1, usage 2: r/that must be/that MUST be

7) s2.1.1., usage 3: r/that must match/that MUST match

8) s3: two musts in bullet 3 to MUST?

9) s4.1: I think it would be helpful to move the last paragraph to the 2nd paragraph.

10) s6: Completely agree with Russ on the SHA-3 reference paragraph.

11) s8: r/cause the user to go/cause the client to go

12) s8: Maybe put quotes around SSL Proxy because we don't have a spec to point to?

13) s8, para 5: Uses the term "certificate trust anchor".  Can you strike the word certificate?

14) s8: para 6: Using end entity seems a little confusing to me because I'm not sure which end entity you're talking about - assume it's the server so:

If a server's certificate is revoked, or if an intermediate CA in a
chain between the *server* and a trust anchor has its certificate...

15) s8, 3rd to last para: Not sure you need end entity in the following:

… TLS server's end entity certificate is evaluated …

16) s8, 2nd to last para: Removing it doesn't mean it's gone immediately - it's got to propagate around doesn't it?  Can you that there's some time lag between when it's removed and how long it takes that change to propagate and that's a small window there where clients will continue to use the TLSA.

17) s8.1: Not sure why the last sentence in the 1st para is needed in this document.  I could see an IPsec or SSH draft saying we use DANE and those  things still apply here.

18) s8.1.1: (I was going to make this a discuss but this has to be an editorial thing) The following is a little confusing because the keys used to validate the signing chain are all public - and get no protection because they're public.  I think you need to add "private" before each instance of key.

  The risk that a given certificate that has a valid signing chain is
  fake is related to the number of keys that can contribute to the
  validation of the certificate, the quality of protection each key
  receives, the value of each key to an attacker, and the value of
  falsifying the certificate.

19) (along the same lines as the previous one) s8.1.1 has

  Also, because a given DNSKEY can only sign ...

  and some more in the bullets at the end about protecting the DNSKEY

Isn't the "DNSKEY" just the public key: DNS Public Key (DNSKEY) (from RFC 4035)?  It doesn't do the signing it's the private key that's associated with the key in the DNSKEY RR?

and add:

  the number of *private* keys capable of

20) s8.1.1: contains the following:

Two things about the following:

As currently
deployed, most PKIX clients use a large number of trust anchors
provided with the client or operating system software.

Isn't this really about TLS clients?  I guess if you include OSes then you can expand it to include PKIX clients.

21) s8.1.4: r/to domains that with/to domains with

22) General: "TLSA certificate association" and "TLS certificate association" are both used.  Can we use one term throughout?

[Ballot discuss]
1) Don't you need to specify how SPKI is encoded:

  The SubjectPublicKeyInfo is a binary structure defined in [RFC5280].

be:

  The SubjectPublicKeyInfo is a DER-encoded structured defined in [RFC5280].

2) s2.1.4: Why does s2.1.4 not discuss type 3?  Is the CAD not used with type 3?

3) s4.1: I might not be following along (or maybe this is just a typo but I'm not sure), it says:

If an application
receives one or more usable certificate associations, it attempts to
match each certificate association with the TLS server's end entity
certificate until a successful match is found.

Doesn't this apply only to type 1?  If the type is 0 then this will never be true because the certificate association is to the CA but the TLS server's certificate is for an end-entity.  I just think this might need to be reworded.

4) s4.1: Normally I'd say these two were comments, but I know the 2nd to last paragraph came about of about 1M messages and I want to make sure these have some teeth.

Shouldn't the should be SHOULD in the following:

If a request for a TLSA record
does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit
from TLSA and should not make any internal or external indication
that TLSA was applied.

Further shouldn't the not be NOT in the following:

If an application has a configuration setting
for turning on TLSA use, or has any indication that TLSA is in use
(regardless of whether or not this is configurable), that application
MUST not start a TLS connection or abort a TLS handshake if either of
the two criteria above are not met.

5) s8.1.1: Contains the following:

These trust
anchors are selected carefully, but with a desire for broad
interoperability.

They're chosen carefully or you paid enough to get them in the root store?  Any chance for a pointer to how "carefully" they are selected?

[Ballot comment]
1) s1: Probably splitting hairs, but I think the certificate isn't the key - it's that the key is "in" the certificate:

OLD:

Having a certificate for a key is only helpful if
one trusts the other key that signed the certificate.

NEW:

Having a key in a certificate is only helpful if
one trusts the other key that signed the certificate.

2) s1:  Again, maybe just nit picking:

OLD:

CAs protect their secret
key vigorously, while supplying their public key to the software
vendors who build TLS clients.

NEW:

CAs protect their secret key vigorously, while supplying their
public key in a certificate to the software
vendors who build TLS clients.

3) This kind of jumped out at me:

DANE is envisioned as a
preferable basis for binding public keys to DNS names, because the
entities that vouch for the binding of public key data to DNS names
are the same entities responsible for managing the DNS names in
question.

isn't this supposed to be about "public keys in certificates to DNS names" .

3) s1.2: In s1.1 you used the term "public CA" and here you saying "external CA" shouldn't we use the same terminology?

4) s2.1.1, usage 1: r/that must be/that MUST be

5) s2.1.1, usage 2: r/that must be/that MUST be

6) s2.1.1., usage 3: r/that must match/that MUST match

7) s3: two musts in bullet 3 to MUST?

8) s4.1: I think it would be helpful to move the last paragraph to the 2nd paragraph.

9) s6: Completely agree with Russ on the SHA-3 reference paragraph.

10) s8: r/cause the user to go/cause the client to go

11) s8: Maybe put quotes around SSL Proxy because we don't have a spec to point to?

12) s8, para 5: Uses the term "certificate trust anchor".  Can you strike the word certificate?

13) s8: para 6: Using end entity seems a little confusing to me because I'm not sure which end entity you're talking about - assume it's the server so:

If a server's certificate is revoked, or if an intermediate CA in a
chain between the *server* and a trust anchor has its certificate...

14) s8, 3rd to last para: Not sure you need end entity in the following:

… TLS server's end entity certificate is evaluated …

15) s8, 2nd to last para: Removing it doesn't mean it's gone immediately - it's got to propagate around doesn't it?  Can you that there's some time lag between when it's removed and how long it takes that change to propagate and that's a small window there where clients will continue to use the TLSA.

16) s8.1: Not sure why the last sentence in the 1st para is needed in this document.  I could see an IPsec or SSH draft saying we use DANE and those  things still apply here.

17) s8.1.1: (I was going to make this a discuss but this has to be an editorial thing) The following is a little confusing because the keys used to validate the signing chain are all public - and get no protection because they're public.  I think you need to add "private" before each instance of key.

  The risk that a given certificate that has a valid signing chain is
  fake is related to the number of keys that can contribute to the
  validation of the certificate, the quality of protection each key
  receives, the value of each key to an attacker, and the value of
  falsifying the certificate.

18) (along the same lines as the previous one) s8.1.1 has

  Also, because a given DNSKEY can only sign ...

  and some more in the bullets at the end about protecting the DNSKEY

Isn't the "DNSKEY" just the public key: DNS Public Key (DNSKEY) (from RFC 4035)?  It doesn't do the signing it's the private key that's associated with the key in the DNSKEY RR?

and add:

  the number of *private* keys capable of

19) s8.1.1: contains the following:

Two things about the following:

As currently
deployed, most PKIX clients use a large number of trust anchors
provided with the client or operating system software.

Isn't this really about TLS clients?  I guess if you include OSes then you can expand it to include PKIX clients.

20) s8.1.4: r/to domains that with/to domains with

21) General: "TLSA certificate association" and "TLS certificate association" are both used.  Can we use one term throughout?

[Ballot comment]
In general, I find section 3 wrongheaded. I think it was a poor design choice to use _port._protocol.rest.of.name. But a poor design choice is not a reason for a DISCUSS. However, I do think that the document should make *some* attempt to justify this poor design choice. Perhaps it's not a poor design choice at all and I'm all wet. But I'd like to hear an explanation. Section 1 says (emphasis mine, excerpted):

  TLS uses certificates to bind keys and *names*.

  The public CA model upon which TLS has depended is fundamentally
  vulnerable because it allows any of these CAs to issue a certificate
  for any *domain name*.

  The DNS Security Extensions (DNSSEC) provides a similar model that
  involves trusted keys signing the information for untrusted keys.
  However, DNSSEC provides three significant improvements.  Keys are
  tied to *names in the Domain Name System (DNS)*, rather than to
  arbitrary identifying strings; this is more convenient for Internet
  protocols.  Signed keys for any domain are accessible online through
  a straightforward query using the standard DNSSEC protocol, so there
  is no problem distributing the signed keys.  Most significantly, the
  keys associated with a *domain name* can only be signed by a key
  associated with the parent of that *domain name*; for example, the
  keys for "example.com" can only be signed by the keys for "com", and
  the keys for "com" can only be signed by the DNS root.  This prevents
  an untrustworthy signer from compromising anyone's keys except those
  in their *own subdomains*.

  DNS-Based Authentication of Named Entities (DANE) offers the option
  to use the DNSSEC infrastructure to store and sign keys and
  certificates that are used by TLS.  DANE is envisioned as a
  preferable basis for binding public keys to *DNS names*, because the
  entities that vouch for the binding of public key data to *DNS names*
  are the same entities responsible for managing the *DNS names* in
  question.

Nowhere does it say that any legacy use of the CA model, nor any designed use of the DANE model, is about anything but a biding between keys and *domain names*. Yet section 3 goes on to add the additional design requirement that I use a port *and* a transport to identify the TLSA record I'm looking for. That prevents me from having a single TLSA record for "www.example.com", which I suspect will be the widest use case, unless I try to do crazy things with wildcards or DNAMEs (and all of their associated pain) as described in Appendix A. There was a requirement in 6394 that "DANE should be able to support multiple application services with different credentials on the same named host, distinguished by port number", but nowhere does that say that it has to be done on the lookup side. (For example, it could be that multiple TLSA records exist for "www.example.com", but they are distinguishable from the data returned. If data size was the problem, you could have had the TLSA records point to a record that actually contained the cert data.) And nowhere does 6394 say that multiple *transports* is a requirement. Note that 6394 also gives wildcard use as a requirement, but that is barely met by this document in that I can't wildcard "all names", but rather I must create subdomains of "_tcp.example.com" and "_udp.example.com" and "_sctp.example.com" and put wildcards under there. Even then, that does not allow me to wildcard all possible transports which I currently don't know about.

So I think this was a terrible design choice. I don't think it reasonably satisfies the requirements of 6394. But a design choice it is. I do ask that you add some text justifying that design choice.

[Ballot discuss]

  Please add a description of Full Certificate to Section 2.1.2.  I
  suggest: "Using the Certificate binary structure defined in [RFC5280]."

  Based on the briefing in the SAAG Session at IETF 83, I strongly
  suggest that this text be removed from Section 6.
  >
  > At the time this is written, it is expected that there will be a new
  > family of hash algorithms called SHA-3 within the next few years.  It
  > is expected that some of the SHA-3 algorithms will be mandatory
  > and/or recommended for TLSA records after the algorithms are fully
  > defined.  At that time, this specification will be updated.

[Ballot comment]

  Section 1.3 says:
  >
  > This document only applies to PKIX [RFC5280] certificates, not
  > certificates of other formats.  Later updates to this document might
  > specify how to use certificates in other formats.
  >
  I suggest that the second sentence be deleted.  Neither the TLS charter
  nor the DANE charter calls for support of new certificate formats.

  An informative reference to define "SSL proxy" would be very helpful.

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- 1.2, last paragraph --
   This document only
   relates to securely associating certificates for TLS and DTLS with
   host names; other security protocols are handled in other documents.

This makes it sound like there are other documents related to DANE for things like IPsec and SSH.  They're about keys in DNS in general, and the next sentence refers to non-DANE stuff.  Then the last sentence comes back to TLS/DTLS.

I suggest doing this paragraph as two paragraphs, this way:

   Sentence 1.  Sentence 2.  Sentence 5.

   Sentence 3.  Sentence 4.

And then re-phrase the new second paragraph to say something like, "...retrieving certificates from DNS for other protocols is handled in other documents."

-- 1.3 --
   The DNSSEC signature needs to be validated on all responses
   that use DNSSEC in order to assure the proof of origin of the data.

Don't *all* responses need to use DNSSEC, as well?  Or is it possible to have a mixture of DNSSEC and unsecured DNS responses?  Maybe it would be better to say it this way?:

NEW
   The DNSSEC signature needs to be validated on all DNS responses
   in order to assure the proof of origin of the data.

-- 2.2 --
   [in three places] MUST be represented as an 8-bit
   unsigned decimal integer.

What does "decimal integer" mean?  I presume you should just take the word "decimal" out in all three places.  Or is there something I'm missing?

-- 2.3 --
The order here is odd: you haven't introduced the _443 and _tcp things yet, but you're showing them in the examples.  Maybe that's OK, but it feels a little confusing to me.  Consider moving the examples after Section 3 (to a new Section 4).

-- 4.1 --
      If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, this MUST cause TLS not to be started

Clearly, "bogus" is a technical term that means something distinct from "indeterminate or insecure" (in the next bullet).  Alas, I cut class the day they explained "bogus", and so I need an explanation.  Can you help?  (I can't explain why I didn't think about this when I reviewed -14; sorry.)

   Thus, in order to achieve
   any security benefit from certificate usage 0 or 1, an application
   that sends a request for TLSA records needs to get either a valid
   signed response containing TLSA records or verification that the
   domain is insecure or indeterminate.

There you define two criteria:
1. Get a valid signed response containing TLSA records.
2. Get verification that the domain is insecure or indeterminate.

   If a request for a TLSA record
   does not meet one of those two criteria but the application continues
   with the TLS handshake anyway, the application has gotten no benefit
   from TLSA and should not make any internal or external indication
   that TLSA was applied.

What indication might it make?  Are we just talking about audit logs of some sort?  In a user application, who will know or care about any indication that TLSA was applied?

In any case, this sentence seems to say that the application can get neither of  (1) or (2), and yet still continue with the TLS handshake.  It's advised not to set an indication that it's using TLSA, but that's not a MUST, and anyway it can go ahead with the handshake in any case.

   If an application has a configuration setting
   for turning on TLSA use, or has any indication that TLSA is in use
   (regardless of whether or not this is configurable), that application
   MUST not start a TLS connection or abort a TLS handshake if either of
   the two criteria above are not met.

That sentence confuses me, for a couple of reasons.  It seems contradictory to the prior sentence.  If you didn't get what you expect...

a. It says that if you have a configuration setting for TLSA, whether or not the setting is enabled, you have to abort.  I don't think that's what you mean.

b. It says that if you ignored the advice above and set your indication anyway, you MUST NOT [if you keep this, you need caps on the "not"] do stuff.  But the previous sentence said you could go ahead anyway.

c. The scope of the MUST NOT is wrong: it appears to say that you MUST NOT abort the TLS handshake, and I'm sure you don't mean that.

d. If *either* of the two are not met?  You mean if *both* are not met, because getting either is OK (and they're mutually exclusive).  Right?

-- 8.3 --
   For this reason, it is RECOMMENDED that DNSSEC validation always be
   performed on-host, even when a secure path to an external validator
   is available.

I found this odd, because at several earlier points you talked about using an external validator with a secure path, and this is the first mention that it's not advisable.  Please consider a reference to this section the first time you talk about that option (Sec 1.3), possibly in 4.1 after the bullet list, and also in Appendix A.3.


========
Other comments; no need to respond to these. Take them or modify them
as you please:

-- 2.1.2 --
   (Note that the use of "selector" in this document is completely
   unrelated to the use of "selector" in DKIM [RFC6376].)

Was there really confusion about that?  Wow.  DKIM also doesn't have anything to do with certificates.  Oh, well... no harm in mentioning this.

-- 8 --
   This in
   essence allows an intermediate CA to be come a trust anchor

Typo: "become" should be one word.

Last paragraph:
   While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may deny to trust the certificate (such as due to
   weak cryptography), the same as it is with PKIX trust anchors.

This is a really awkward sentence.  May I suggest this?:
NEW
   While such trust is limited to the
   specific domain name, protocol, and port for which the TLSA query was
   made, local policy may decline to accept the certificate (for reasons such
   as weak cryptography), as is also the case with PKIX trust anchors.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA) to Proposed Standard


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) Transport Layer
  Security (TLS) Protocol: TLSA'
  as Proposed Standard

This is a 2nd IETF LC on this document. The reason is that there
were quite a few text changes, though no protocol changes, as a
result of the 1st IETF LC and we'd like to check if the comments
have been addressed in an acceptable (note: not perfectl!) manner.

The difference between -19 and -21 can be seen at:

https://tools.ietf.org/rfcdiff?url1=draft-ietf-dane-protocol-19&difftype=--html&submit=Go!&url2=draft-ietf-dane-protocol-21


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@ietf.org mailing lists by 2012-05-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Encrypted communication on the Internet often uses Transport Level
  Security (TLS), which depends on third parties to certify the keys
  used.  This document improves on that situation by enabling the
  administrators of domain names to specify the keys used in that
  domain's TLS servers.  This requires matching improvements in TLS
  client software, but no change in TLS server software.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.

IESG:

IANA has reviewed draft-ietf-dane-protocol-19.txt and has the following comments:

IANA understands that, upon approval of this document, there are five actions
which IANA must complete.

First, in the Resource Record (RR) TYPEs subregistry of the Domain Name System
(DNS) Parameters registry located at:

http://www.iana.org/assignments/dns-parameters

a new RRtype will be registered as follows:

Type: TLSA
Value and Meaning: 52 TLSA
Reference: [ RFC-to-be ]

IANA understands that the Expert Review for this action is already complete and
that the entry has already been added to the registry. Upon approval of the
document the reference for this entry will be updated.

Second, a new main registry will be created in the "Domain Name System (DNS)
Parameters" section of:

http://www.iana.org/protocols/

called "DNS-Based Authentication of Named Entities (DANE)" with a reference
pointing to [ RFC-to-be ]. There will be new subregistries for this new registry.

Third, in the new "DNS-Based Authentication of Named Entities (DANE)" created
above, a new subregistry will be created. It will be called "Certificate
Usages for TLSA Resource Records". Maintenance of this registry is via RFC
Required as defined in RFC 5226. There are initial values for this registry as
follows:

Value Short description Reference
--------------------------------------------------------------
0 CA constraint [ RFC-to-be ]
1 Service certificate constraint [ RFC-to-be ]
2 Trust anchor assertion [ RFC-to-be ]
3 Domain-issued certificate [ RFC-to-be ]
4-254 Unassigned
255 Private use

Fourth, in the new "DNS-Based Authentication of Named Entities (DANE)" created
above, a new subregistry will be created. It will be called "Selectors for
TLSA Resource Records". Maintenance of this registry is via Specification
Required as defined in RFC 5226. There are initial values for this registry as
follows:

Value Short description Reference
--------------------------------------------------------------
0 Full Certificate [ RFC-to-be ]
1 SubjectPublicKeyInfo [ RFC-to-be ]
2-254 Unassigned
255 Private use

Fifth, in the new "DNS-Based Authentication of Named Entities (DANE)" created
above, a new subregistry will be created. It will be called "Matching Types
for TLSA Resource Records". Maintenance of this registry is via Specification
Required as defined in RFC 5226. There are initial values for this registry as
follows:

Value Short description Reference
--------------------------------------------------------
0 No hash used [ RFC-to-be ]
1 SHA-256 RFC 6234
2 SHA-512 RFC 6234
3-254 Unassigned
255 Private use

IANA understands that these five actions are the only ones that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

CC:

Reply-To: ietf@ietf.org

Subject: Last Call:  (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard





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)'

  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@ietf.org mailing lists by 2012-04-25. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.



Abstract





  Encrypted communication on the Internet often uses Transport Level

  Security (TLS), which depends on third parties to certify the keys

  used.  This document improves on that situation by enabling the

  administrators of domain names to specify the keys used in that

  domain's TLS servers.  This requires matching improvements in TLS

  client software, but no change in TLS server software.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-dane-protocol/ballot/





No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested...


This document is requested to be published as Proposed Standard.
The title page header identifies: "Intended status: Standards Track".
The description in RFC 2026 Section 4.1.1 (Proposed Standard) covers
this draft, and so it is the correct "type".

(2) The IESG approval announcement includes a Document Announcement
Write-Up...

Technical Summary

Encrypted communication on the Internet often uses Transport Level
Security (TLS), which depends on third parties to certify the keys
used. This document improves on that situation by enabling the
administrator of a domain name to publish the keys used in the
DNS, secured with DNSSEC.


Working Group Summary

The working group made extensive use of the issue tracker:
listing, opening, discussing and then calling consensus on
each issue. This gave everyone the opportunity to participate
and be heard. There have been approximately 2,000 messages
discussing this (and closely related) documents.

Document Quality

There is a tool (Swede - https://github.com/pieterlexis/swede)
that generates TLSA records, and a proof-of-concept implementation
of DANE for NSS (https://mattmccutchen.net/cryptid/#nss-dane).
A number of vendors have mentioned that they are planning on
implementing the specification.

I do not think that it would be fair (or possible) to single
out any specific reviewers -- we have had a large number of very
active reviewers / participants and they have all been very diligent
(and sometimes vocal :-)) in providing feedback.

Personnel

Warren Kumari is acting as the Document Shepherd.
Stephen Farrell is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Document Shepherd is also one of the WG Co-chairs, and has been
involved in reviewing, calling consensus, etc. He has reviewed the
document and believes that it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. This document has received lots of review. We have been
fortunate in having folk from many other working groups participating,
and believe that we are good for both breadth and depth.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

This document requests a new DNS RR type (TLSA). A
request for expert review for the RRTYPE has been submitted.
http://www.ietf.org/mail-archive/web/dnsext/current/msg12303.html


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

None.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes -- authors have been polled and state that they have no IPR to
disclose.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed (yay!).


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

In the chairs opinion there is strong to very strong consensus. As
with any complex document that has had a lot of discussion, a number of
folk have points that they are not 100% happy with. These points don't
overlap very much though.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this
document...

ID Nits found 1 nit:
Missing Reference: 'This' is mentioned on line 654, but not defined

This is *not* an issue, it is simply a reference to this document (but
mentioned for completeness).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

It meets the requirements by not having any!

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement...

No.


(15) Are there downward normative references references...

No.


(16) Will publication of this document change the status of any
existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, ...

The document creates 3 new registries. They clearly state the
requirements to get an allocation, contain a clear list of the current
allocations, and have reasonable names.


(18) List any new IANA registries that require Expert Review...

None.


(19) No formal language.