Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application)

From: Antoin Verschuren <[email-masked]>
Date: Thu, 1 Dec 2011 10:56:02 +0100

On 30-11-11 22:07, Ondřej Surý wrote:

> 
> --new text--
>    An application that complies with this document first requests TLSA
>    records in order to make certificate associations.
> 
>    Determining whether a TLSA RRset can be used depends
>    on the DNSSEC validation state (as defined in [RFC4033]).
> 
>    o A TLSA RRset whose DNSSEC validation state is secure MAY be used
>      as a certificate association for TLS.
> 
>    o 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
>      or, if the TLS negotiation is already in progress, to cause
>      the connection to be aborted.
> 
>    o A TLSA RRset whose DNSSEC validation state is indeterminate or
>      insecure cannot be used for TLS and MUST be marked as unusable.
> --new text--

+1

I hope though that implementers will warn me when the indeterminate or
insecure case causes other TLS validation to occur and I'm not doing
DANE, so I can be extra carefull.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 1 Dec 2011 10:10:25 +0000

If the validation state is not secure - it MUST be a matter of local policy what to do. You cannot dictate how to handle that failure only that it is an insecure connection. The application behavior may be to fall back use an insecure connection in which case you may as well go ahead and use the insecure TLS protected connection

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Antoin Verschuren
Sent: Thursday, December 01, 2011 3:26 PM
To: [email-masked]
Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application)

+1

I hope though that implementers will warn me when the indeterminate or insecure case causes other TLS validation to occur and I'm not doing DANE, so I can be extra carefull.

- --
Antoin Verschuren

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970 mailto:[email-masked]  xmpp:[email-masked] http://www.sidn.nl/ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJO108yAAoJEDqHrM883AgniN4H/iFCisW9IGI/1bfKrFRukIrX
53470G3YqcjiIBbIaM1g9u3mE/q/q5/ko5T07ekL6BEDFOmHi8i01kPETgdxoyr7
+YE/ALIJIdQTalwDvOJuaMd7jIshlJWKBXBxz6BQa6AeXWPnGwL+eBVHHEUzygSI
VgHMnb8Y9GFSP+7bwzVdkjytY53AFn+GarDwvigJrfm76NghznJ1MCNhhOiBm9bn
74A7MwCE7rbx3Sqf8iVjqHOwUKDB3lY2o+hIuVhe9xA/ZdtAjiJ+EvCohH/ICHx1
8PspN78d9nAWHxpOUyUjMtYAeRVgWJEknVyibOvmkGzK0N9JyUorNuJz94U3f0M=
=gUqG
-----END PGP SIGNATURE-----
_______________________________________________
dane mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dane

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Dec 2011 07:58:40 -0500

On Wed, Nov 30, 2011 at 07:55:22PM -0800, Zack Weinberg wrote:
> I don't think DANE should override a local determination that some
> certificate is never to be trusted (explicit blacklist, that is, not
> just default-untrusted).  Can we make sure we allow local policy to do
> that?

Isn't that exactly the sort of thing the MAY (that people seem uneasy
about) permits?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Thu, 1 Dec 2011 14:17:20 +0100

> Isn't that exactly the sort of thing the MAY (that people seem uneasy

if all else fails, ..., RFC 2119, section 5:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

The use of the normative language has 'evolved' over time, though, but
it doesn't seem like MAY was invented to permit "local policy".

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Dec 2011 10:09:17 -0500

> it doesn't seem like MAY was invented to permit "local policy".

I always read that text as _exactly_ permitting local policy, among
other things, particularly when one is specifying how one is to do
something locally.  That is, the MAY in question tells others (from an
interoperability perspective) that you might do something with the
DNSSEC-signed TLSA record, and you might not.  If I'm the site
providing the TLSA record with its DNSSEC signature, you'd be a fool
not to do something with that record, but that's your decision and it
doesn't affect me at all.  From the POV of _inter_operation, the only
things I can rely on are that you might use the TLSA record if it's
valid, you won't do TLS if you can't validate it, and if you get a
bogus record you will nto connect at all.

So for the purposes of this case, I would say that MAY does so permit
the local policy.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 01 Dec 2011 11:00:17 -0500

+1
This captures quite well what I proposed.

	Olafur

Ps: I agree with the change in wording proposed by Peter Koch

On 30/11/2011 16:07, Ondřej Surý wrote:
> In a hope to clear at least some of the confusion, here's the
> text which replaces last paragraph in 4.4, which is NOW:
>
> --old text from -12--
>     records in order to make certificate associations.  If that
>     application receives zero usable certificate associations, it
>     processes TLS in the normal fashion; otherwise, that application
>     attempts to match each certificate association with the TLS server's
>     end entity certificate.  If such a match is found, that application
>     continues the TLS handshake and ignores any remaining certificate
>     associations; otherwise, that application MUST abort the TLS
>     handshake with an "access_denied" error.
> --old text from -12--
>
> which becomes:
>
> --new text--
> Note: Please read whole text and not just bullets.  E.g. in all other
> possible (undefined here) cases the TLSA RRset cannot be used.
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Dec 2011 08:30:06 -0800

On Nov 30, 2011, at 8:03 PM, Richard L. Barnes wrote:

> Do we really need to say anything about this?  

Yes. In many other security WGs, people have argued against MUST language in places where trust is applied. This clarifies that the certificate assertion is available, not mandated at all times.

We could possibly use "SHOULD use except where local policy overrides", but I find that more confusing. Others might want it, however.

> ISTM that local policy can always override.  

Right.

> Keep in mind that DANE validation is a part of the overall certificate acceptance process.  There are already other checks (e.g., name checks) that get applied by the application layer; checking blacklists could be part of that.

Those checks happen during PKIX processing, which starts after the DANE processing. It would be better if we didn't combine the two. For example...

> Besides, if you see the cert and it's on your black-list, why would you go to the trouble of invoking DANE?    

Most applications will do DANE before they start the TLS negotiation, so they won't have the cert in hand. Again, assuming that DANE is being done *while* the TLS handshake is in progress is a bad assumption.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 1 Dec 2011 20:15:09 +0100

So can we use 'can' instead of MAY?

>  on the DNSSEC validation state (as defined in [RFC4033]).

We are asking 'whether X can be used'

>  o A TLSA RRset whose DNSSEC validation state is secure can be used

We are saying: 'Yes, it can be used'.

I may be wrong, but I don't see a need for normative MAY here.

O.

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Dec 2011 14:25:33 -0500

> I may be wrong, but I don't see a need for normative MAY here.

I don't care one way or another.

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Gilmore <[email-masked]>
Date: Thu, 01 Dec 2011 17:37:43 -0800

Is there some reason why we are trying to write the protocol spec for
orgs or apps who have hardwired particular keys to particular names?
Those people may deviate from our spec, and that's fine if that is
what they want.  Most important is what the generic apps and orgs
(99.9% of the net) do.  If they follow our spec, they should deliver
real privacy and authenticity, if the constraints that we define in
our security considerations section are met.

If a client obtains a securely signed TLSA RRSET, and the TLS connection
comes up with a server key that isn't part of that RRSET, generic apps
should terminate hard.  Due to the well known attack surfaces of
pre-DNSSEC TLS, which are known to fail under active attacks seen
today in the real Internet, TLSA "must" cause the TLS connection to
terminate, rather than merely falling back to the insecure method that
will lead the user to think they are secure when they aren't.

In a TLSA-enabled TLS implementation, the only two ways to fall back
to old-TLS, while retaining the security properties that our
committee exists to provide, are if a DNSSEC-secured domain proves that
there are no TLSA records, or if the user tries to contact a domain
that (it can securely determine) is not secured by DNSSEC.

Implementations that want to do otherwise "must" not be compliant
with our spec.

	John

---

From: Peter Koch <[email-masked]>
Date: Sun, 4 Dec 2011 00:07:37 +0100

> We are saying: 'Yes, it can be used'.

in my eyes this is fuzzy wording.

> I may be wrong, but I don't see a need for normative MAY here.

If I read the discussion correctly, "SHOULD" is probably what you're looking for:
"using" the TLSA RR is the recommended way forward and exceptional
circumstances (local policy override) might suggest otherwise.

-Peter

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 6 Dec 2011 10:54:34 +0100

I am fine with Peter's SHOULD, so the full text will be:

>   o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used

So far we have:
+1 Zack, Richard, Bert, Andrew, Paul H., Marco, Warren, Peter, Yoav, JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me

If you have +1ed earlier text, please review this one since the MAY has changed to SHOULD (no need to +1 again if you still agree).

Martin Rex has some objections, so I take it as -1.  Also Eric Osterweil has objected to the badly formatted text in the beginning of this thread; Eric could you please review current proposed text?

Overall we have a very strong consensus, so I would like to end the call by the end of this week (say Friday), so we can wrap this up and move on.

O.

---

From: Scott Schmit <[email-masked]>
Date: Tue, 6 Dec 2011 08:05:28 -0500

On Tue, Dec 06, 2011 at 10:54:34AM +0100, Ondřej Surý wrote:
> So far we have: +1 Zack, Richard, Bert, Andrew, Paul H., Marco,
> Warren, Peter, Yoav, JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me
> 
> If you have +1ed earlier text, please review this one since the MAY
> has changed to SHOULD (no need to +1 again if you still agree).

I don't object to the should. That said, I'd like to clarify the purpose
of the consensus call: is it a consensus on DNSSEC processing only (but
we're being very precise about the language of that processing to make
sure everyone is in agreement), and we can expect that other text in the
section/document will get adjusted to integrate the consensus/text, or
is this more of text replacement consensus, and no other text will be
modified?

If the former, i'm still +1. If the latter, I have to be -1, because
the old paragraph also explained how to process the records once you
know they're secure, which isn't mentioned in the new version. Also,
rereading section 4.4 in its entirety, we'd want to do the check above
before dropping malformed or intelligible records. This would suggest
something like:

["!" used for modifications, ":" for moves, reflows ignored.]

4.4. Use of TLS Certificate Associations in TLS

   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.  The
   matching or chaining MUST be done within the life of the TTL on the
   TLSA record.

   Some specifications for applications that run under TLS, such as
   [RFC2818] for HTTP, require the server's certificate to have a domain
   name that matches the host name expected by the client.  Some
!  specifications such as [RFC6125] detail how to match the identity
[typos:                 ^                                         ^ ]
   given in a PKIX certificate with those expected by the user.

   In order to use one or more TLS certificate associations described in
   this document obtained from the DNS, an application MUST assure that
!  the associations were obtained using DNS protected by DNSSEC.  TLSA
[      ^^^^^^^^^^^^ was "certificates" ]
   records must only be trusted if they were obtained from a trusted
   source.  This could be a localhost DNS resolver answer with the AD
   bit set, an inline validating resolver library primed with the proper
   trust anchors, or obtained from a remote name server to which one has
   a secured channel of communication.

[Inserted this text here, rather than replace the last paragraph:]
!  An application that complies with this document first requests TLSA
!  records in order to make certificate associations.
!
!  Determining whether a TLSA RRset can be used depends
!  on the DNSSEC validation state (as defined in [RFC4033]).
!
!  o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used
!    as a certificate association for TLS.
!
!  o 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
!    or, if the TLS negotiation is already in progress, to cause
!    the connection to be aborted.
!
!  o A TLSA RRset whose DNSSEC validation state is indeterminate or
!    insecure cannot be used for TLS and MUST be marked as unusable.

   If a certificate association contains a certificate usage, selector,
   or matching type that is not understood by the TLS client, that
   certificate association MUST be marked as unusable.  If the
   comparison data for a certificate is malformed, the certificate
   association MUST be marked as unusable.

[Removed the first sentence of the last paragraph, as that's what I
think the above text is really replacing.]
!  If the application receives zero usable certificate associations, it
   processes TLS in the normal fashion; otherwise, that application
   attempts to match each certificate association with the TLS server's
   end entity certificate.

[Moved the first paragraph here to fit into the processing better]
:  Section 2.1 of this document defines the mandatory matching rules for
:  the data from the TLS certificate associations and the certificates
:  received from the TLS server.

   If such a match is found, that application continues the TLS handshake
   and ignores any remaining certificate associations; otherwise, that
   application MUST abort the TLS handshake with an "access_denied"
   error.

Sorry I didn't notice this earlier, but I hope the suggested text helps.

-- 
Scott Schmit

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Dec 2011 07:21:33 -0800

On Dec 6, 2011, at 1:54 AM, Ondřej Surý wrote:

>>  .  . .

Text with "SHOULD" needs to list when the "SHOULD" doesn't apply; otherwise, implementers do not have the guidance they need. Can you (or Peter) fill that in a bit more? If not, can we go back to "MAY"?

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 6 Dec 2011 16:46:12 +0100

> Text with "SHOULD" needs to list when the "SHOULD" doesn't apply; otherwise, implementers do not have the guidance they need. Can you (or Peter) fill that in a bit more? If not, can we go back to "…

Could you provide reference to that requirement?

RFC2119 says:

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
      may exist valid reasons in particular circumstances to ignore a
      particular item, but the full implications must be understood and
      carefully weighed before choosing a different course.

I don't see how is that worse for implementors than:

My understanding is that we need a better text about local policy in any case.
Right now we have this text in the security recommendations:

   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.

I think that Scott's proposal to modify 4.4 fits quite good here.  If we
are still talking about local policy than adding something like

   o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used
     as a certificate association for TLS.  Whether this certificate
     association will be used for TLS is a matter of a local policy.

Or just change (f.e. elaborating on Scott's email)

to

  If such a match is found, that application continues the TLS handshake
  if the local policy allows it and ignores any remaining certificate
  associations; otherwise, that application MUST abort the TLS handshake
  with an "access_denied" error.

**

Anyway the whole "local policy" is also a bit vague.

What can you specify in the local policy:
- to ignore specific certificate association
  (when you receive only this treat as empty)
- to abort on specific certificate association
  (when you match this certificate association abort TLS)

O.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 6 Dec 2011 16:49:36 +0100

> is this more of text replacement consensus, and no other text will be

The former.

This should be aligned with bogus state:

> ! application MUST NOT start TLS or, if the TLS negotiation in already
> ! in progress, to cause the connection to be aborted.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Dec 2011 07:56:51 -0800

> Could you provide reference to that requirement?

A zillion threads in dozens of WGs over the past 20 years where an implementor didn't do what the SHOULD said because they thought they knew better.

>     association will be used for TLS is a matter of a local policy.

That works for me. A more specific way might be:

  o A TLSA RRset whose DNSSEC validation state is secure SHOULD be used
    as a certificate association for TLS unless a local policy would
    prohibit the use of the specific certificate association in the
    secure TLSA RRset.

> Anyway the whole "local policy" is also a bit vague.

Yes, of course. We can never put bounds on all types of local policies.

>  (when you match this certificate association abort TLS)

Are you proposing that we put those restrictions on local policy in the protocol, or simply to list them as examples of local policy?

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 6 Dec 2011 17:08:35 +0100

> A zillion threads in dozens of WGs over the past 20 years where an implementor didn't do what the SHOULD said because they thought they knew better.

Ok :)

>    prohibit the use of the specific certificate association in the

Works for me if it works for you.

> Are you proposing that we put those restrictions on local policy in the protocol, or simply to list them as examples of local policy?

More of questions than examples or anything else...  in any case not the restrictions.  But I am fine with listing examples, since it could cut down the creativity if we list the sane ones.

O.

---

From: Peter Koch <[email-masked]>
Date: Tue, 6 Dec 2011 17:10:20 +0100

> A zillion threads in dozens of WGs over the past 20 years where an implementor didn't do what the SHOULD said because they thought they knew better.

in general some ambiguity is a feature of "SHOULD" over "MUST", while at the
same time giving guidance is probably a good idea.  To that extent I think you,
Paul, are on the right track, without furthering discussion about the formalities
or not of a general requirement.  In this particular case, we have an idea
what would qualify for a "SHOULD" escape, so to preserve some of the discussion
on this list, it's useful to state a reason.

The guidance to the implementor then is, however, to allow for local overrides
rather than not implementing the "use" at all - which would render the whole
effort useless.

>     prohibit the use of the specific certificate association in the

This second version gives more guidance, although one could now argue that
the "unless" makes the exemption list complete and would actually even justify
a "MUST". I'll refrain from being this "one".

-Peter

---

From: SM <[email-masked]>
Date: Tue, 06 Dec 2011 08:26:08 -0800

At 07:56 06-12-2011, Paul Hoffman wrote:
>Are you proposing that we put those restrictions on local policy in 
>the protocol, or simply to list them as examples of local policy?

Restricting local policy is akin to censorship. :-)  It's better to 
provide guidance, e.g. informative examples and leave it to the 
implementor to decide.

Regards,
-sm

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 6 Dec 2011 11:44:51 -0800

-1

I believe that if the policy statement needs to be made, then it should be made in a different location and the MAY needs to be a MUST.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Surý
> Sent: Tuesday, December 06, 2011 1:55 AM
> To: Eric Osterweil
> Cc: IETF DANE WG list
> Subject: [dane] Call for DNSSEC validation states ending soon (Was: RFC2119
> MAY (Was: Call for consensus on level of DNSSEC support))
> 
> 
> > On Thu, Dec 01, 2011 at 08:15:09PM +0100, Ond??ej Sur  wrote:
> >
> +1 Zack, Richard, Bert, Andrew, Paul H., Marco, Warren, Peter, Yoav,
> +JimC, Paul W., Scott, Jakob, Antoin, Olafur, /me
> 
> If you have +1ed earlier text, please review this one since the MAY has
> changed to SHOULD (no need to +1 again if you still agree).
> 
> Martin Rex has some objections, so I take it as -1.  Also Eric Osterweil has
> objected to the badly formatted text in the beginning of this thread; Eric
> could you please review current proposed text?
> 
> Overall we have a very strong consensus, so I would like to end the call by
> the end of this week (say Friday), so we can wrap this up and move on.
> 
> O.
> --
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: Scott Schmit <[email-masked]>
Date: Tue, 6 Dec 2011 20:04:07 -0500

> > ! in progress, to cause the connection to be aborted.

The reason I didn't was because at the point you're matching the TLSA RR
to the certificate recieved from TLS, you--by definition--have already
started the TLS negotiation.

-- 
Scott Schmit