Subject: [dane] [Technical Errata Reported] RFC6698 (3594)

From: RFC Errata System <[email-masked]>
Date: Tue, 16 Apr 2013 15:18:17 -0700 (PDT)

The following errata report has been submitted for RFC6698,
"The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6698&eid=3594

--------------------------------------
Type: Technical
Reported by: Viktor Dukhovni <[email-masked]>

Section: 2.1.1

Original Text
-------------
      2 -- Certificate usage 2 is used to specify a certificate, or the
      public key of such a certificate, that MUST be used as the trust
      anchor when validating the end entity certificate given by the
      server in TLS.  This certificate usage is sometimes referred to as
      "trust anchor assertion" and allows a domain name administrator to
      specify a new trust anchor -- for example, if the domain issues
      its own certificates under its own CA that is not expected to be
      in the end users' collection of trust anchors.  The target
      certificate MUST pass PKIX certification path validation, with any
      certificate matching the TLSA record considered to be a trust
      anchor for this certification path validation.

Corrected Text
--------------
      2 -- Certificate usage 2 is used to specify a certificate, or the
      public key of such a certificate, that MUST be used as the trust
      anchor when validating the end entity certificate given by the
      server in TLS.  This certificate usage is sometimes referred to as
      "trust anchor assertion" and allows a domain name administrator to
      specify a new trust anchor -- for example, if the domain issues
      its own certificates under its own CA that is not expected to be
      in the end users' collection of trust anchors.  The target
      certificate MUST pass PKIX certification path validation, with any
      certificate matching the TLSA record considered to be a trust
      anchor for this certification path validation.  Since clients cannot
      be presumed to have their own copy of the trust-anchor certificate,
      when the TLSA association specifies a certificate digest, the TLS
      server MUST be configured to provide the trust-anchor certificate in
      its "certificate_list" TLS handshake message.

Notes
-----
This is critical for interoperability between clients and servers.  A client that commits to verify TLSA RR certificate associations will fail if it can't obtain the required certificates.  With usage "2" there is no presumption that these are available to the client.  If servers are not obligated to provide them the protocol will consistently fail.  With non-interactive protocols where there is no user to "click OK", such as SMTP, there is no good work-around and both client and server owners suffer.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6698 (draft-ietf-dane-protocol-23)
--------------------------------------
Title               : The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
Publication Date    : August 2012
Author(s)           : P. Hoffman, J. Schlyter
Category            : PROPOSED STANDARD
Source              : DNS-based Authentication of Named Entities
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: John Gilmore <[email-masked]>
Date: Tue, 16 Apr 2013 16:17:09 -0700

> can log in to change the status and edit the report, if necessary. 

I think it should be rejected.

There are numerous ways to make any protocol fail, by selecting
mutually incompatible options.  The draft does not have to require
that users of DANE-TLS configure their servers to work; they are free
to configure them to fail.  Similarly, there are often numerous ways
to make any protocol work, by selecting different combinations of
compatible options.  The RFC does not have to require ("MUST") a
particular combination, nor should it do so.

The issue is certificate usage "2", defining a new trust anchor.

To make a system interoperate with DANE-TLS clients when publishing
TLSA records that specify usage 2, a server operator and domain
administrator must:

  *  Supply the entire trust anchor certificate in their TLSA record,
     specifying selector 0 (full certificate) and matching type 0
     (exact match); or

  *  Configure their TLS server to supply the relevant trust anchor
     certificate in the certificate list that it sends [the option
     that Mr. Dukhovni suggests]; or

  *  Supply the public key of the trust anchor in their TLSA record,
     specifying selector 1 (Subject Public Key Info) and matching type 0
     (exact match), allowing any certificate(s) signed by the trust anchor
     to be validated; or

  *  Only interact with clients who already have a copy of the trust
     anchor certificate or public key.  Some applications may be
     designed or configured to work only with a restricted set of
     clients.

Any or all of these options are valid and will result in DANE-TLS
interoperability.  The erratum should be rejected.

	John

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Apr 2013 19:57:09 -0400

+1

Plus, this is for TLS, and in TLS, the server is required to present a cert
chain.  So the situation cited in the erratum can't happen.

On Tuesday, April 16, 2013, John Gilmore wrote:

> _______________________________________________
> dane mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 00:25:19 +0000

> chain.  So the situation cited in the erratum can't happen.

This is false.  There is no pre-DANE requirement for servers to
present a *complete* chain, they may for example omit the root CA,
since prior to DANE, the client always needed that on hand.

> I think it should be rejected.

Note, the erratum only suggests requiring the server certificate
when the TLSA RR is a *digest*, so "2 0 0" and "2 1 0" were never
in scope.

> The issue is certificate usage "2", defining a new trust anchor.

Via a digest of public key material.

>      specifying selector 0 (full certificate) and matching type 0

Not in scope for the erratum.

>      that Mr. Dukhovni suggests]; or

Correct.

>      (exact match), allowing any certificate(s) signed by the trust anchor

Not in scope for the erratum.

>      designed or configured to work only with a restricted set of

Then the specification should say so.  That is, either the server
operator intends to *only* support pre-configured clients, or the
server operator MUST include the TA certificate in the server chain.

My concern is that many server operators have a weak grasp of
cryptography, and may naively expect "2 1 1" or "2 0 1" to work,
since they specified the TA in their TLSA record, (surely that's
enough :-).

> interoperability.  The erratum should be rejected.

For SMTP prior to DANE, TLS is either never used or used
opportunistically, so the server operator will continue to receive
email from DANE-unaware clients for years to come.

Not publishing the TA certificate is not an access control mechanism,
it just complicates client implementation even for clients that have
a copy of the TA certificate somewhere.

Augmenting the server chain with TA certs by digest is rather
non-trivial as these can be anywhere in the chain, but OpenSSL,
for example, only stores self-signed roots in the trust store.

Supporting out-of-band TA certificates is rather non-trivial.  The
proposed language makes the protocol more robust and easier for
users to understand and implement correctly.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Apr 2013 17:39:06 -0700

This is not an erratum, it is a proposal to add operational guidance for how TLS servers should act when an associated TLSA record of a certain type would be used. The guidance is correct, but it is not an erratum.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 00:52:41 +0000

On Tue, Apr 16, 2013 at 05:39:06PM -0700, Paul Hoffman wrote:

> This is not an erratum, it is a proposal to add operational
> guidance for how TLS servers should act when an associated TLSA
> record of a certain type would be used. The guidance is correct,
> but it is not an erratum.

I guess I can live with that.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 17 Apr 2013 07:42:34 +0200

> This is not an erratum, it is a proposal to add operational guidance for how TLS servers should act when an associated TLSA record of a certain type would be used. The guidance is correct, but it i…

I agree, it should not be an erratum.

	jakob

---

From: [email-masked] (Martin Rex)
Date: Wed, 17 Apr 2013 14:31:21 +0200 (CEST)

Paul Hoffman wrote:
>
> This is not an erratum, it is a proposal to add operational guidance
> for how TLS servers should act when an associated TLSA record of a
> certain type would be used. The guidance is correct, but it is not
> an erratum.

Erratums _include_ omissions.

We talked about this issue on the DANE mailing list, e.g.
   http://www.ietf.org/mail-archive/web/dane/current/msg04252.html

but the necessary information appears to have been omitted from the
final document, so posting this errata now is perfectly valid.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Apr 2013 07:49:19 -0700

> Erratums _include_ omissions.

I understand why you might feel that way, given how often your positions are not supported in WGs and yet you repeat them nearly endlessly. However, that's not what the RFC Errata system is designed for.

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Wed, 17 Apr 2013 18:22:56 +0200 (CEST)

Paul Hoffman wrote:
>
> [email-masked] (Martin Rex) wrote:
> >
> > Paul Hoffman wrote:
> >> 
> I understand why you might feel that way, given how often your positions
> are not supported in WGs and yet you repeat them nearly endlessly.
> However, that's not what the RFC Errata system is designed for.

You're significantly mistaken.

The IETF has an underlying principle of
"we reject Kings, Presidents and voting.  We believe in rough consensus
 and running code".

The same is illustrated by what I previously quoted from rfc2026.

   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified,

The IETF values feedback from implementors, and most situation where
Implementors return the feedback "this is not sufficiently clear",
deserves a clarification to be added.

When it comes to implementation experience, the feedback from implementors
is significantly more relevant that the personal taste in purely theoretical
review (and decision / rough consensus based on it) and more relevant than
personal taste of assigned document editors.

And filing clarifications to Proposed Standards, that are going to result
from implementation experience, through the RFC errata process is perfectly
valid, because that is what rfc2026 implies to apply for Proposed Standards.

Really, the IETF needs to be much more appreciative of implementors
feedback, or we will see less of such feedback in the future!

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Apr 2013 09:40:59 -0700

All of what you say about the IETF needing more input from implementers is true. And it is also irrelevant to the discussion of trying to jam that input into the errata for an RFC. You don't seem inclined to write down your implementation experience in operational RFCs, but it sounds like Viktor is.

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Wed, 17 Apr 2013 13:03:54 -0400

> since prior to DANE, the client always needed that on hand.

Fair enough.  But the upshot of this is that the server needs to EITHER:
(1) Provide the cert in DANE, OR
(2) Provide the cert in TLS

So it is completely plausible for DANE to have a mode where only a hash of
the cert is presented.  As Paul notes, this is deployment guidance, not a
gap in the DANE protocol.

That said, it might be worth starting a document to collect deployment
recommendations of this type.  Especially if it were written by people
actually deploying DANE :)

--Richard

> [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 17:04:09 +0000

On Wed, Apr 17, 2013 at 09:40:59AM -0700, Paul Hoffman wrote:

> All of what you say about the IETF needing more input from
> implementers is true. And it is also irrelevant to the discussion
> of trying to jam that input into the errata for an RFC. You don't
> seem inclined to write down your implementation experience in
> operational RFCs, but it sounds like Viktor is.

Though I don't much mind what ultimate form the operational
requirements for TLSA "2 ? [12]" take, I'd strongly prefer to see
this discussed in 6698 itself, rather than a new operational RFC.
A separate RFC will be easily missed, and the operational requirement
will be less well publicized.

If the text is not changed to "MUST" per the erratum, the right
thing IMHO is to add a subsection somewhere, that explains the
practical need to provide the TA cert in most circumstances.
Something along the lines of:

    4.2 TLSA certificate usage 2 digest associations.

    Since with certificate usage "2" the client cannot generally
    be presumed to have its own independent copy of the associated
    trust-anchor certificate or public key, when publishing TLSA
    certificate usage 2 associations with a digest matching type
    (e.g.  "1" or "2"), a server that communicates with clients
    outside a small set known by the server operator to be
    pre-configured with any required trust-anchor certificates must
    provide a corresponding trust-anchor certificate to the client
    via the SSL server certificate message "certificate_list" (
    https://tools.ietf.org/html/rfc2246#section-7.4.2) Failure to
    provide the certificate in the server "certificate_list" will
    lead to interoperability problems.

I wrote "must" in lower-case, in its informal natural language
sense, predicated on the servers need to interoperate on the public
Internet, not a home LAN.  Can we find a reasonable home for such
language in 6698?  My guess is that Section 4 is not a bad place,
but I am open to other suggestions.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Wed, 17 Apr 2013 19:13:07 +0200 (CEST)

Paul Hoffman wrote:
> All of what you say about the IETF needing more input from implementers
> is true. And it is also irrelevant to the discussion of trying to jam
> that input into the errata for an RFC.

I would recommend that you actually take a look at the
**published** guidelines for errata:

  http://www.rfc-editor.org/status_type_desc.html

and the IESG rules for evaulating submitted errata:

  http://www.ietf.org/iesg/statement/errata-processing.html

an in particular item 4., 5. and 6. on that list, and why the errata
process knows about a status "held for document update".

>
> You don't seem inclined to write down your implementation experience

I am not a _DANE_ implementor.

However, I occasionally implement specifications an can easily understand
Viktors confusion.  As I said, this kind of confusion was easily
predictable for someone who is in general used to do implementation work:
  http://www.ietf.org/mail-archive/web/dane/current/msg04252.html

>
> in operational RFCs, but it sounds like Viktor is.

Do you seriously want to suggest such a heavyweight process as writing
and publishing an I-D in order to get one single clarifying sentence
added into an insufficiently clear "Proposed Standard" RFC?

The pragmatic approach is to submitted as errata to the RFC early on,
and expect the list of erratas ("held for document update")
to grow non-marginally with implementation experience.

There is one problem with the current errata processing: it's impossible
for the submitter himself to edit the errata after submission.  This should
be considered a defect of the current User Interface.  Due to this defect,
it is preferable for the submitter to consult/discuss with document authors
or the responsible WG.  Not for keeping them from submitting the errata,
but for trying to ensure that the errata will be useful to others as well,
not just the original submitter.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 17:26:58 +0000

> (2) Provide the cert in TLS

Or even as some have argued.

  (3) Communicate only with clients that have obtained the cert by prior
      arrangement.

> gap in the DANE protocol.

I don't agree with Paul, but I don't much care about the niggly
details.  Some text should be added to 6698 that makes this potential
problem clear to implementors.  I've added such text to the server
certificate seciton of the Postfix TLS_README, but this only covers
a subset of server operators.

The practical requirement when the association is a digest (which
rules out (1)) to necessarily do (2) (except in narrow cases when
(3) is an option) should IMHO be explained *somewhere* in 6698.

> actually deploying DANE :)

This issue goes beyond a deployment recommendation, it is a logical
pre-requisite for interoperability that is easily missed when one
does not carefully analyze what the client needs to do in order to
use the TLSA RRs in question.  Therefore, it should I believe be
added to 6698 in some form.  If "MUST" is too strong for (2), given
the occasional possibility of (3), then a more nuanced wording is
fine.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Apr 2013 13:24:20 -0700

> will be less well publicized.

RFC 6698 is published. No bits in it can change. RFC's *never* change.

If there are errors, an erratum can be filed. The chance of a developer seeing an erratum is near zero.

This WG can write an RFC that updates RFC 6698; that new RFC would contain new information, such as operational guidance.

Any individual can write an individually-produced RFC with operational guidance.

The chance of a developer seeing the update of the RFC, or a separate RFC, is *much* higher than of them seeing the erratum.

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Thu, 18 Apr 2013 00:36:37 +0200 (CEST)

Paul Hoffman wrote:
> If there are errors, an erratum can be filed. The chance of a
> developer seeing an erratum is near zero.

The title page of rfc6698 reads:

http://tools.ietf.org/html/rfc6698

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6698.

The page behind the URL from the RFC says:

   Please refer _here(*)_ for any errata for this document. 

(*) http://www.rfc-editor.org/errata_search.php?rfc=6698

And that page shows Viktor's errata.

I believe the above process for finding this errata 
does not exceed the skill of an average devoloper/implementor.

YMMV.

Viktor's submitted errata is both important and valuable.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Apr 2013 23:11:55 +0000

> developer seeing an erratum is near zero.

Understood, but at least everyone stopped ignoring me. :-)

> This WG can write an RFC that updates RFC 6698; that new RFC
> would contain new information, such as operational guidance.

This needs to be an update.  It is not just operational guidance,
because it is an interoperability requirement.

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Apr 2013 20:52:44 -0400

> Viktor's submitted errata is both important and valuable.

That may well be, but I don't think it's an erratum.  It's a
substantive change.

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 17 Apr 2013 21:45:59 -0400 (EDT)

> If there are errors, an erratum can be filed. The chance of a developer seeing an erratum is near zero.

It would help if IETF would start redirecting old plain text RFC documents
to the copies on that have hyperlinks that do link to errata.

Ensuring page rank for http://tools.ietf.org/html/rfc5996 or
http://datatracker.ietf.org/doc/rfc5996/ would be higher then the page
rank for http://www.ietf.org/rfc/rfc5996.txt would be helpful for people
using search engines to find RFCs to land at pages that _do_ have the
errata information.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 18 Apr 2013 02:02:53 +0000

> That may well be, but I don't think it's an erratum.  It's a

It is an explanation of a somewhat non-obvious interoperability
requirement to server operators who may miss it otherwise.  No
change at all.  If the server operator publishes TLSA 2 1 1, for
example, but fails to provide the associated certificate, clients
will not be able to verify his chain, even it may seem to many that
publishing the TLSA RR is enough.

I am trying to be flexible in how this is resolved, but surely
Andrew's response is wrong.  I will resist what little temptation
exists to explain it again, by now the thread contains more than
enough ways of explaining the same thing.  Even Paul has agreed
that my observation is basically sound (and does not change the
standard), the only question that remains is what is the most
effective way to communicate this to server operators so that the
standard will work in practice.

-- 
	Viktor.

---

From: [email-masked] (Martin Rex)
Date: Thu, 18 Apr 2013 04:05:13 +0200 (CEST)

Andrew Sullivan wrote:
> Martin Rex wrote:

Huh?

The additonal clarification _neither_ changes the DANE protocol,
_nor_ does it change the TLS protocol.  So it is merely a
technical clarification, but *NO* (technical) change!

However, this errata is extremely important information for an implementor
of a DANE client
  - for knowing which location to typically search for a potential
    match to the info from the TLSA record
  - what error message and suggestion to produce when the necessary
    certificate is not present in a handshake,
  - what kind of configuration interfaces will be necessary for
    the typical DANE client
  - what to write into the documentation of the DANE client
    or the documentation of the APP that contains the DANE client.
    (example configurations and pitfalls).

Viktor's submitted errate is a brief and accurate description
of vital information that is missing in rfc6658.

With the current guidance in rfc2026 about the to-be-expected defects
of documents at Proposed Standard maturity level, and the existing
guidance about Erratas from RFC Editor and IESG, and the lack of
any alternative mechanism to add missing clarifications to a published RFC,
Viktor's approach is currently the one and only that is documented,
and it is an extremely reasonable solution.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Apr 2013 19:26:25 -0700

> to the copies on that have hyperlinks that do link to errata.

You meant to send this to [email-masked] instead of the DANE WG mailing list, yes? :-)

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Fri, 19 Apr 2013 14:45:32 -0700

Hi Victor,
>Understood, but at least everyone stopped ignoring me. :-)

I am not ignoring you.  I read the messages discussing about CNAMEs. :-)

Regards,
-sm

---

From: SM <[email-masked]>
Date: Fri, 19 Apr 2013 20:42:32 -0700

Hi Victor,
>standard will work in practice.

The corrected text may be valuable but in my opinion it is, as Andrew 
Sullivan mentioned, a substantive change.  This is grounds for 
rejecting erratum #3594.

If the standard does not work in practice it means that RFC 6698 is 
defective.  That's a different issue.  There are different schools of 
thought about how a RFC should be written and how things should be 
done in the IETF.

Regards,
-sm

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Apr 2013 03:58:32 +0000

> The corrected text may be valuable but in my opinion it is, as
> Andrew Sullivan mentioned, a substantive change.  This is grounds
> for rejecting erratum #3594.

Any grounds or explanation for this opinion?  How is text that
highlights a deductive-logic consequence of the specification a
change?

-- 
	Viktor.

---

From: SM <[email-masked]>
Date: Fri, 19 Apr 2013 22:12:25 -0700

Hi Victor,
>highlights a deductive-logic consequence of the specification a

RFC 6698 is a document which reflects the consensus of the IETF at 
the time it was published.  The substantive change I mentioned is a 
change to that consensus.  I look at it this way: if I am 
implementing a specification documented through a RFC I don't want 
the RFC to be changed as it can affect my implementation.  There are 
disadvantages to that, e.g. when there is a defect in the specification.

Regards,
-sm

P.S. I saw your other message.  I have to do some reading before 
sending a reply.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Apr 2013 05:25:07 +0000

On Fri, Apr 19, 2013 at 10:12:25PM -0700, SM wrote:

> change to that consensus.

Lack of RFC WG consensus does not trump simple deductive logic,
which remains irrefutably true even if the group did not explicitly
endorse it.

You repeat the same assertion, but still with no justification,
what is the change you speak of?

    Server: Via DNS: My TA digest is 12345
    Server: Via TLS handshake: my certificate chain is A, B, C
    Client: Sees that none of A, B, or C have 12345 as their digest.
	    Does not have any certificates in hand with digest 12345
	    (no presumption of this with certificate usage 2).
	    Verification fails.

Therefore:

    Observation: If server does not want the client to fail, include
    the TA cert in the chain A, B, C, D (assuming, for example, that
    D is the missing TA certificate that signed C).

Recommendation, publish this purely deductive observation so that
server operators don't fail to note the (logical rather than imposed
by additional text in the RFC) requirement.

-- 
	Viktor.

---

From: SM <[email-masked]>
Date: Fri, 19 Apr 2013 23:19:33 -0700

Hi Viktor,
>what is the change you speak of?

I expressed my opinion.  I can be wrong.  I'll explain my point of view:

  (a) The working group has to decide what to do about this erratum.

  (b) I do not have to convince the working group about whether to approve the
      erratum or not to approve it.

  (c) I read the messages on this thread and I gathered that my opinion would
      not make any difference.  I am ok with that.

Regards,
-sm

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Apr 2013 07:51:23 -0700

>    D is the missing TA certificate that signed C).

Yes. And there are probably other valuable operational considerations that are not in RFC 6689 that you and others are discovering as well. These should be captured in an RFC that updates RFC 6689. That way, future developers and implementers can find them in a widely-distributed and stable document series.

If the WG wants to add this to the charter, I would be willing to be editor again. However, I think that an actual implementer and/or operator of DANE services would probably be a better editor (nudge, nudge Viktor). If the WG doesn't want to add this to the charter (or if the AD does not was us to add this to the charter), an operational document such as this that updates RFC 6689 is a completely reasonable thing for individual submission.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Apr 2013 16:41:31 +0000

On Sat, Apr 20, 2013 at 07:51:23AM -0700, Paul Hoffman wrote:

> Yes. And there are probably other valuable operational considerations
> that are not in RFC 6698 that you and others are discovering as
> well. These should be captured in an RFC that updates RFC 6698.
> That way, future developers and implementers can find them in a
> widely-distributed and stable document series.

Since my goal is not IETF politics, but rather an attempt to help
would be users who deploy server-side DANE achieve interoperability
with my implementation,  I don't really have a prior bias on the
form in which my experience is disseminated.

Since RFCs don't change once published, and errata are rarely read,
though getting an erratum adopted would be a moral victory, and I
think even a legitimate "bug fix" to 6698, it likely would not
address my goal.

So a separate document needs to be published either way.  So far
the totality of what I have to share is:

    - The already discussed to death server requirements for usage 2 digests.

    - Client requirement for usage 0 digests (willingness to fail with
      servers whose root CA cert is not on hand).  If the client does not
      expect to have a sufficiently complete set of trusted root CAs, it
      may need to treat usage 0 digest TLSA RRs as "unusable" in order
      to avoid failing.

      Thus with SMTP, with no user to click OK, and no history of
      requiring a "complete" set of CAs,  "IN TLSA 0 0 1" and "IN
      TLSA 0 0 2" (and their public key variants) should by default
      be treated as "unusable",  with the choice to enable these
      left to the user (SMTP client administrator).

    - Client processing of "IN TLSA 2 1 0" full public keys in DNS.
      Here the client can't actually fully conform to RFC 5280
      PKIX, since DNS only provides a TA public key and parameters,
      with no TA "name" (DN, or any other kind).  Since the client
      will often not have the full TA certificate on hand, if the
      server operator does not provide the TA certificate in the
      chain, the client needs to check whether the top of the server
      chain is "signed by" the TA from DNS, it cannot build verify
      whether the chain is "issued by" "the TA", since the DNS
      specifies only an equivalence-class of TAs that share the
      same public key, presumably some member of that class issued
      the chain (and with CA best practice ideally the class has
      at most one member).

    - Futility of usages "0" and "1" with DNS indirection.  When
      the base domain of the TLSA server is obtained from DNS (e.g.
      via MX or SRV records), the additional protection that some
      seek from successful attacks on DNSSEC by also performing
      PKIX validation is not available.  Once DNSSEC is compromised,
      the attacker can freely serve forged SRV or MX records, and
      thus freely chosen associated TLSA RRs.  [I would like to see a
      substantive comment on this from Tony Finch].

      Therefore, applications such as SMTP, that are completely at
      the mercy of DNSSEC, as they rely on MX or SRV RRs to construct
      the TLSA base domain, may reasonably choose to avoid the
      PKIX validation requirements for usages 0 and 1.  For "1 x y",
      the application may choose to simply treat the TLSA RR as "3 x y",
      with no loss in security.  Likewise for "0 x 0" (full certificate
      or public key in DNS).  For "0 x [12]", per the previous comment,
      the application may need to treat the TLSA RR as "unusable".

    - Leveraging CNAME indirection to simplify key management in virtual
      hosting environments.  Use CNAME target domain as the base domain
      for TLSA lookups.  Avoid requirement for domain owners and server
      operators to resort to SNI.  (Clients must still send SNI since
      the server operator may be using SNI to support TLS certificate
      selection even sans CNAME RRs).  Servers don't have to implement
      SNI, they may choose to only support a single TLS server name.
      (CNAMEs are illegal in SRV and MX RRs, and clients should either
      fail or securely chase the CNAME to obtain the TLSA base domain).

    - A description of an implementation of DANE with no changes to
      OpenSSL, just a verification callback.

Would these all be one draft?  Are there are other implementors on this
list, and do they have additional material to contribute?

-- 
	Viktor.

---

From: nudge <[email-masked]>
Date: Sat, 20 Apr 2013 18:42:13 +0200

On Sat, Apr 20, 2013, at 04:51 PM, Paul Hoffman wrote:
> that are not in RFC 6689 that you and others are discovering as well.
> These should be captured in an RFC that updates RFC 6689. That way,
> future developers and implementers can find them in a widely-distributed
> and stable document series.
> 
> If the WG wants to add this to the charter, I would be willing to be
> editor again. However, I think that an actual implementer and/or operator
> of DANE services would probably be a better editor (nudge, nudge Viktor).

We've not implemented or operated (yet) but we're all for Viktor

sorry

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Apr 2013 10:02:44 -0700

> list, and do they have additional material to contribute?

If this is a WG document, that decision is ultimately made by the WG. Note that, when a motivated document editor puts additional important considerations in a document, the WG rarely removes them. (Although the WG might significantly change them, often for the better, as we saw in this very WG.)

If this is an individual submission, the author is the sole decider of what goes in or not. Things might be removed during IETF Last Call, but that is rare; the most common outcomes are minor additions and changes.

>      OpenSSL, just a verification callback.

RFCs rarely have such descriptions. However, this sounds quite useful, and I would hope that an appendix that has this would be allowed to remain.

--Paul Hoffman

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 20 Apr 2013 19:40:52 +0100

Hi there,
 a data point:
In ENUM, the version 2.0 specs were RFC3261 and RFCs 3401-3405. These were "non-trivial" to implement fully.
[This whole area also had informational RFCs making 2116 statements, had a few odd interactions with other specs, and so on -- fun].

=> Rather than just produce narrow errata against the specs, we created an "ENUM Experiences" slide deck deck (and then an I-D) to capture the way in which folks had misunderstood the ENUM spec[s] and where there were options that didn't work as easily as originally planned**
The output of this I-D became a WG doc, and that was eventually released as a BCP (RFC5483).

As this BCP showed that there was genuine confusion over how to implement this stuff, we rolled the lessons learn into an update of the ENUM spec (RFC6116).

This needed people willing to do the work, some honest implementors to explain what c*ck-u*s they had had made, and a great deal of patience; it took years.

Was it worth it? Yes, IMHO.
Was it easy/quick? Nope.

I might add that it did teach me that producing the one true scheme that combined two different ways of thinking (URIs and URNs) made for a b*st*rd to implement system. This and other DANE threads show how much fun the different use cases are, and how they require implementors to get their heads in quite different orientations to make the whole thing work. ... but that's just me.

Going for an "Implementation Experiences" capture document may well defuse the "errata or change request or dispepsia" discussions.
The RFC exists, and if it leaves scope for people to shoot themselves in the foot (or for the server owners to shoot the clients in the foot), it's much better to produce an improved doc set (as "experiences" and then an osoletes/updates spec), IMHHO.

=> Who is going to do the work, and capture the DANE experiences? -- it's a non-trivial effort, but crucial to duffers who might want to use this stuff.

=> Is there enough energy **and goodwill** in the WG to take this forward, rather than argue the toss over whether or not this particular use case or that is the spawn of satan?

all the best,
  Lawrence

** [That Experiences work DID require a promise in blood that those who talked to the authors would not be identified, nor laughed at too loudly]

---

From: [email-masked] (Martin Rex)
Date: Mon, 22 Apr 2013 15:27:52 +0200 (CEST)

> thought about how a RFC should be written and how things should be 

Rfc6698 will fail interop if the server admin asks his DNS admin
to create a TLS record for usage 2 that contains only a certificate
hash or SPKI hash, and fails to have his server send the respective
certificate in certificate_list of the TLS server Certificate handshake
message.

This will become obvious to an implementor when trying to implement
usage 2, wondering about missing information, and deducing the
missing information by formal logic.

The requested clarification simply adds explicit words for what is
already implicitly required by the existing specification.  It is
not just valuable, it is the only formal correct interpretation
of what is already there.  Anything different from that requested
clarification would amount to a change of the specification.

Anyone who believes that this clarification is a "substantive change"
has not looked at the existing spec from the perspective of formal
correctness.

-Martin

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Apr 2013 09:56:03 -0400

> has not looked at the existing spec from the perspective of formal

Nonsense.  It is a _correct_ clarification, but specifications can be
vague in ways that, with the wrong interpretation, fail to
interoperate.  (One could argue that a significant portion of the
history of DNS is an illustration of that principle.)  Correcting such
vagueness is still a substantive change, and should not be handled
using an erratum.  If you think this is important enough, I urge you
to write 6698-bis, not abuse the erratum procedure.

A

-- 
Andrew Sullivan
[email-masked]

---

From: [email-masked] (Martin Rex)
Date: Mon, 22 Apr 2013 16:07:25 +0200 (CEST)

> to write 6698-bis, not abuse the erratum procedure.

I'm sorry, this is non-sensical.

Rewriting an RFC for the simple addition of one single clarifying
sentence, about something that is formally provable implied by what
is already there, is a complete and thorough misunderstanding of the
IETF process and the Proposed Standard document maturity level.
It irritates me to see such a statement from folks that I consider
part of the IETF leadership.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 22 Apr 2013 16:24:06 +0200

Hi all,

sorry for the lack of time to step in earlier, we are expecting our first born and it obviously follows IETF processes, since she has already missed a milestone (be born) by a week, so my thought are little bit elsewhere at this moment.

I would like every to please take a deep breath before continuing in this discussion (you know the drill -> write an email, save it into a drafts, go to sleep, check the email in the morning, send it only if it seems to be still ok).

I think we have a consensus that the proposed change is correct.  If not, please correct me.

It seems we have three different course of actions possible and as we still believe in the opinion of the WG (and the consensus), and I agree with all three points below, I would like to have a quick vote (is week ok?) on the topic:

a) do nothing
b) accept errata as is
c) start work on RFC6698bis and include this change

Please try to limit your response to a), b) or c), so we our thread don't turn into a threat as we have observed many times on this list.  If I did miss an option, please change the subject to your proposal and clearly state the option and reasoning.

Thank you,
Ondrej

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Apr 2013 10:35:12 -0400

On Mon, Apr 22, 2013 at 04:07:25PM +0200, Martin Rex wrote:

> is already there

If it is formally provably implied in the document, then there is no
reason for an erratum anyway.

> , is a complete and thorough misunderstanding of the

I disagree.  I think that PS is PS precisely _because_ this sort of
problem might be in them, and that the process of updating documents
is how we advance them.  We do not track all the things that ought to
be added to a document during update in errata, and I don't believe we
should start now.  I agree with you that your proposal is an advisable
update.  I just don't think it's an erratum.

> part of the IETF leadership.

For the record, I'm not responding with any hat on.  I'm not the boss
of this anyway, either.  Also, as anyone who has ever read anything
I've written or heard anything I said knows, the idea that a dot of
any colour on my badge indicates any special kind of wisdom or
knowledge is not backed up by the evidence.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 22 Apr 2013 16:54:17 +0200

Folks,

I see no DANE material here.  Please take it to [email-masked] and take it back when and if you can reach the agreement.  This is purely policy discussion and thus it doesn't belong to the DANE list.

Thank you for the understanding,
Ondrej

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Apr 2013 07:58:57 -0700

> I'm sorry, this is non-sensical.

It is what nearly everyone on the DANE WG mailing list other than you has said. It's not clear how you define "sensical", but in a participatory group like the IETF, "sense" is often determined by what most people are saying. Being in a small minority is fine (I'm often there, as many people know), but that doesn't make the view of the small minority the only sensical one.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Apr 2013 08:00:22 -0700

> c) start work on RFC6698bis and include this change

(c) seems good, and Viktor has already said that he is willing to start on it.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 Apr 2013 15:12:17 +0000

On Mon, Apr 22, 2013 at 08:00:22AM -0700, Paul Hoffman wrote:

> On Apr 22, 2013, at 7:24 AM, Ond?ej Sur? <[email-masked]> wrote:
> 
> > a) do nothing
> > b) accept errata as is

Sure, but I started work on an "operational guidance" I.-D.  If we're
updating 6698, the content would be quite different.  Which is the immediate
priority?  A 6698 update or an operational guidance draft?

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Apr 2013 08:55:54 -0700

> priority?  A 6698 update or an operational guidance draft?

My thought is to create the operational guidance draft first and then see whether the WG wants it separate or as a 6698bis. That decision can be made late.

--Paul Hoffman

---

From: [email-masked]
Date: Mon, 22 Apr 2013 19:27:26 +0200

On 2013-04-22 17:55, Paul Hoffman wrote:
> My thought is to create the operational guidance draft first and then
> see whether the WG wants it separate or as a 6698bis. That decision
> can be made late.

Sounds good to me.

Ondrej

---

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Apr 2013 17:10:27 -0400

> My thought is to create the operational guidance draft first and then see whether the WG wants it separate or as a 6698bis. That decision can be made late.

<no hat>
This sounds like the right plan to me as well. 

I'm suspecting that having this in the operational draft is a good plan (and maybe also include it in a 6698bis as well, if one is written). It feels sort of operational, and I suspect that developers will read the op draft as well...
</no hat>

W

P.S: Apologies for not responding earlier in the thread. I was in Beijing (for ICANN, don't ask…) and fell behind on mail. I was planning on reading mail using a web interface over a VPN (so I wouldn't have it stored locally), but a: I dislike web interfaces for mail[0], and b: for some unexplained, mysterious reason my VPN, which if fine everywhere else, refused to remain stable in Beijing… 

[0]: Yeah, yeah...

-- 
"He who laughs last, thinks slowest." 
    -- Anonymous

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 23 Apr 2013 10:31:46 -0700

Warren Kumari <[email-masked]> writes:

> I'm suspecting that having this in the operational draft is a good
> plan (and maybe also include it in a 6698bis as well, if one is
> written). It feels sort of operational, and I suspect that developers
> will read the op draft as well...

And I highly doubt we'll end up with only a single recommendation about
operational guidance.  So collecting thoughts now for it seems wise.
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

---

From: James Cloos <[email-masked]>
Date: Tue, 23 Apr 2013 18:20:15 -0400

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> My thought is to create the operational guidance draft first and then
PH> see whether the WG wants it separate or as a 6698bis. That decision
PH> can be made late.

+1 on that.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: [email-masked] (Martin Rex)
Date: Thu, 25 Apr 2013 03:59:10 +0200 (CEST)

> c) start work on RFC6698bis and include this change

(b) -- I'm fine with either "approve" or "hold for update".

-Martin