Subject: [keyassure] Validation Preferences / Subordinate

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Sep 2010 12:21:06 -0400

http://tools.ietf.org/id/draft-hoffman-keys-linkage-from-dns-01.txt

Has the following text at the start of section 2:

o  The key tag and algorithm fields are both set to zero.

   The format of the TLSFP certificate is a binary record, which MUST be
   in the order defined here, is:

   o  A one-octet value, called "hash type", specifying the type of hash
      algorithm used for the certificate association.  This value has
      the same values as those of the DS RR, as defined in [RFC4034] and
      its successors.

   o  A one-octet value, called "validation preference", specifying the
      preferences for further validation of the certificate in TLS.  A
      certificate association that contains a validation preference
      whose value is 1 indicates that the TLS administrator believes
      that it is sufficient to match the certificate association with
      the hash of certificate received in the TLS negotiation, and that

I do not like this approach for several reasons. First we already have a
perfectly good algorithm field, so lets use it. If we can't for whatever
reason we should have a proper explanation for why not.

The idea of embedding control data in the first bytes of a base64 encoded
string is going to be completely incomprehensible for your typical customer
support staff trying to help someone work out why their web site has stopped
working. This approach is going to cause them to warn customers to shut this
mechanism off for good and not risk touching it.

There are two approaches to the algorithmID I see as being justifiable. The
first is to use the existing Algorithm ID field. It is what it is for. We
may of course need to specify a value for SHA256 in the cert algorithms
registry as some DNS server implementations may assume that all CERT
algorithm IDs come from that registry. But that is what it is for.

The other approach would be to prepend the existing ASN.1 algorithm OIDs to
the digest value.

I have several problems with the term 'validation preference'. One big one
is that some people have an unstated expectation that CERT assurances are
going to be somehow exclusive so that conclusions can be drawn from the lack
of an assurance record. That is a very major change to the semantics. of
CERT and I do not agree with that mode of expression.

I am all for the idea of developing a means of using the DNS to express
limitations on the trust path processing for a domain. But if we are going
to do that it has to be an explicit charter item and not an undocumented
side effect of a new set of semantics that have been glom-ed onto an
existing record.

Any DNS-based mechanism for expressing restrictions on the roots of trust to
be used with a domain has to be independent of the PKI mechanism used. If
someone has an enterprise PKI under which all their SSL certs are issued,
they should be able to express that semantic without having to deploy the
KEYASSURE proposal. Suggesting doing so is to build research on research.

Besides that, I don't like the term 'validation preferences'. These are not
really preferences, they are requirements that the party giving the
assurance expects relying parties to respect. The semantics being described
are really saying that the DNSSEC assurance is in addition to the normal
cert assurance process. So don't trust this cert unless the cert also passes
the corresponding PKIX path math and revocation checks.

The uses I would see for this would be to get a better binding to a domain
name with a wildcard certificate and possibly to enable some other DNS based
mechanism that allows explicit statements concerning the acceptable trust
roots/mechanisms to be specified for a domain.

Here is what I have at this point, it is not exactly great but I think it is
rather more precise:

The Key Tag field is used to specify assurance options as follows:

0None1Subordinate

If the key tag field is set to the value 1, the key assurance provided by
the CERT resource record is subordinate to that provided by the certificate
data. If this value is specified RELYING Parties SHOULD NOT rely on the
assurance provided by the corresponding CERT record unless the certificate
data meets the normal validation criteria in its own right.

The subordinate bit would be specified in the previous example as follows.

example.com     CERT ASSURE 0 SHA256
                KR1L0GbocaIOOim1+qdHtOSrDcOsGiI2NCcxuX2/Tqc

No assurance is given for the equivalent certificate data unless a valid
PKIX certificate chain can be established for the original certificate to a
trusted root that passes all the normal revocation checkin mechanisms.

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Sep 2010 09:59:02 -0700

>http://tools.ietf.org/id/draft-hoffman-keys-linkage-from-dns-01.txt

Note that the draft was updated last week, as we said on the list. A more universal URL that will always get you the current version is <http://tools.ietf.org/id/draft-hoffman-keys-linkage-from-dns>.

>I do not like this approach for several reasons. First we already have a perfectly good algorithm field, so lets use it. If we can't for whatever reason we should have a proper explanation for why not.

The "perfectly good" algorithm field from RFC 4389 is for signature algorithms, not hash algorithms. We  say clearly in this document that it what we are using is a hash algorithm. (The examples in your draft, which also use hashes like we do, are incorrect.)

>The idea of embedding control data in the first bytes of a base64 encoded string is going to be completely incomprehensible for your typical customer support staff trying to help someone work out why their web site has stopped working. This approach is going to cause them to warn customers to shut this mechanism off for good and not risk touching it.

Is your proposal to abandon the existing CERT record because of this problem?

>There are two approaches to the algorithmID I see as being justifiable. The first is to use the existing Algorithm ID field. It is what it is for. We may of course need to specify a value for SHA256 in the cert algorithms registry as some DNS server implementations may assume that all CERT algorithm IDs come from that registry. But that is what it is for.

See above; you are proposing to change the semantics of the CERT RRtype for this proposal, which others might think is a bad idea.

>The other approach would be to prepend the existing ASN.1 algorithm OIDs to the digest value.

You may feel that parsing such a OID-preended-to-digest structure is easier to use than a one-byte field whose values are already defined in an IANA registry; others might disagree.

>I have several problems with the term 'validation preference'. One big one is that some people have an unstated expectation that CERT assurances are going to be somehow exclusive so that conclusions can be drawn from the lack of an assurance record. That is a very major change to the semantics. of CERT and I do not agree with that mode of expression.

Neither do I: that's why we made validation preference explicitly a preference.

>I am all for the idea of developing a means of using the DNS to express limitations on the trust path processing for a domain. But if we are going to do that it has to be an explicit charter item and not an undocumented side effect of a new set of semantics that have been glom-ed onto an existing record.

You brought up a possible protocol feature that we talk about at length in the draft; I am confused by what you mean by "undocumented". Yes, it is not documented in your or Simon's draft, but that's because we aren't a WG and therefore don't have a WG draft yet.

I disagree that this needs to be in the charter because it is not clear whether or not the WG will want this protocol feature, if it will want different ones, and so on. I certainly don't consider the feature inherent to what we are proposing.

>Any DNS-based mechanism for expressing restrictions on the roots of trust to be used with a domain has to be independent of the PKI mechanism used. If someone has an enterprise PKI under which all their SSL certs are issued, they should be able to express that semantic without having to deploy the KEYASSURE proposal. Suggesting doing so is to build research on research.

That is why we did not suggest that. Instead, we gave the DNS owner a way of stating a preference. Is there a word better than "preference" that we could use to indicate that this is a preference, not a "restriction" or "limitation" or the other words you use above?

>Besides that, I don't like the term 'validation preferences'. These are not really preferences, they are requirements that the party giving the assurance expects relying parties to respect.

No, they're not. Please don't accuse us of lying, Phill. Our draft says exactly what it means.

>The semantics being described are really saying that the DNSSEC assurance is in addition to the normal cert assurance process. So don't trust this cert unless the cert also passes the corresponding PKIX path math and revocation checks.

No, that's not what it says at all. It says exactly what it means.

>The uses I would see for this would be to get a better binding to a domain name with a wildcard certificate and possibly to enable some other DNS based mechanism that allows explicit statements concerning the acceptable trust roots/mechanisms to be specified for a domain.

The wildcard-certificate use case is a reasonable one that would work with what has been proposed by all three drafts, I believe. The second is possible, but not ones that we have considered for our draft.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Sep 2010 13:41:31 -0400

Paul,

It is really difficult to discuss anything with you when you start accusing
me of accusing you of lying when I have done no such thing. Please calm
down.

First off, I don;t think that your draft is remotely as readable as you
imagine. I find it pretty opaque. And I think I probably have a better
understanding of the subject matter than you can expect of the average
reader.

Secondly, I suggest that before you reply to any message you do the writer
the courtesy of reading it through to the end first. Fisking is a pretty
unproductive approach.

The reason I think that the charter has to explicitly state the scope of the
work is because that is what a charter is for. You cannot charter a group on
the basis that it is going to develop a key assurance scheme and then adopt
a working group item that is a policy proposal.

Either the group will have a charter that explicitly states that the group
will consider policy and/or selection of roots of trust or the group will
have one that explicitly states that it will not consider them and rules
them out of scope.

On Mon, Sep 20, 2010 at 12:59 PM, Paul Hoffman <[email-masked]>wrote:

> Note that the draft was updated last week, as we said on the list. A more
> universal URL that will always get you the current version is <
> http://tools.ietf.org/id/draft-hoffman-keys-linkage-from-dns>.
>
> The "perfectly good" algorithm field from RFC 4389 is for signature
> algorithms, not hash algorithms. We  say clearly in this document that it
> what we are using is a hash algorithm. (The examples in your draft, which
> also use hashes like we do, are incorrect.)
>
> >There are two approaches to the algorithmID I see as being justifiable.
> The first is to use the existing Algorithm ID field. It is what it is for.
> We may of course need to specify a value for SHA256 in the cert algorithms
> See above; you are proposing to change the semantics of the CERT RRtype for
> this proposal, which others might think is a bad idea.
>
> You may feel that parsing such a OID-preended-to-digest structure is easier
> to use than a one-byte field whose values are already defined in an IANA
> registry; others might disagree.
>
> You brought up a possible protocol feature that we talk about at length in
> the draft; I am confused by what you mean by "undocumented". Yes, it is not
> documented in your or Simon's draft, but that's because we aren't a WG and
> therefore don't have a WG draft yet.
>
> I disagree that this needs to be in the charter because it is not clear
> whether or not the WG will want this protocol feature, if it will want
> different ones, and so on. I certainly don't consider the feature inherent
> to what we are proposing.
>
> >Any DNS-based mechanism for expressing restrictions on the roots of trust
> to be used with a domain has to be independent of the PKI mechanism used. If
> That is why we did not suggest that. Instead, we gave the DNS owner a way
> of stating a preference. Is there a word better than "preference" that we
> could use to indicate that this is a preference, not a "restriction" or
> "limitation" or the other words you use above?
>
> >Besides that, I don't like the term 'validation preferences'. These are
> not really preferences, they are requirements that the party giving the
> assurance expects relying parties to respect.
>
> >The semantics being described are really saying that the DNSSEC assurance
> is in addition to the normal cert assurance process. So don't trust this
> cert unless the cert also passes the corresponding PKIX path math and
> revocation checks.
>
> The wildcard-certificate use case is a reasonable one that would work with
> what has been proposed by all three drafts, I believe. The second is
> possible, but not ones that we have considered for our draft.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 20 Sep 2010 22:58:13 +0200

> I have several problems with the term 'validation preference'. One big one is that some people have an unstated expectation that CERT assurances are going to be somehow exclusive so that conclusion…

We should keep in mind that the use case we are trying to address is where one:

- have started to deploy DNSSEC-assisted key assurance, and
- use classic (CA-issued) domain validation certificates for legacy clients, and
- want to short-circuit full PKIX validation (and thus skip OCSP and whatnot)

The 'validation preference' flag (when set) enables this.

> Here is what I have at this point, it is not exactly great but I think it is rather more precise:
> 
> 0
> None
> 1
> Subordinate
> If the key tag field is set to the value 1, the key assurance provided by the CERT resource record is subordinate to that provided by the certificate data. If this value is specified RELYING Parties SHOULD NOT rely on the assurance provided by the corresponding CERT record unless the certificate data meets the normal validation criteria in its own right.

Reading your suggested text above, I interpret your 'subordinate flag' as just the inverse of our 'validation preference'. The words may be slightly different, but the effect is the very same.

In my use case above I would set 'subordinate flag' to 0 and have the same effect, would you agree?

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Sep 2010 17:21:56 -0400

I agree that the mechanisms are intended to be equivalent. What I was trying
to do was to get to a bit more precision.

I don't like calling something a preference because that sounds like it is
something that isn't going to make any difference and therefore can
(should?) be ignored. Having milk in coffee is a preference. If it is only a
preference then it is best got rid of because it is only adding
non-determinism to the client. The whole point of a standards process is to
remove choices that don't make any difference.

Setting or clearing this bit is actually going to trigger the execution of
different code paths in the clients written the way we would want them to be
written.

The reason I choose 0 for standalone and 1 for subordinate is that the
standalone client requires less code than the one that also has to do the
native mode processing.

I think we actually have three possible values -

* Standalone
* SHOULD validate the original path math
* MUST validate the original path math

Again it is a bit hard to judge these without knowing what the application
is. If we are talking about turning on STARTTLS in an SMTP connection and
the alternative is to accept the same data en-clair, then the bar is really,
really low. I cannot think of any circumstance in which I would want the
connection to be refused (unless there was a possible resource starvation
attack).

If on the other hand we are looking at a situation where the user has asked
for security or there is a policy statement somewhere that says 'always use
security', then we can be a lot more precise about where the bar is.

On Mon, Sep 20, 2010 at 4:58 PM, Jakob Schlyter <[email-masked]> wrote:

> > I have several problems with the term 'validation preference'. One big
> one is that some people have an unstated expectation that CERT assurances
> are going to be somehow exclusive so that conclusions can be drawn from the
> lack of an assurance record. That is a very major change to the semantics.
> of CERT and I do not agree with that mode of expression.
>
> Reading your suggested text above, I interpret your 'subordinate flag' as
> just the inverse of our 'validation preference'. The words may be slightly
> different, but the effect is the very same.
>

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 21 Sep 2010 09:41:05 +0200

On 20 sep 2010, at 23.21, Phillip Hallam-Baker wrote:

> I agree that the mechanisms are intended to be equivalent. What I was trying to do was to get to a bit more precision. 

Good - I'm happy to see we are in agreement.

> Setting or clearing this bit is actually going to trigger the execution of different code paths in the clients written the way we would want them to be written.

Yes, but we should keep in mind that the client can always override whatever is set, just as clients today override OCSP and CRL processing.

> The reason I choose 0 for standalone and 1 for subordinate is that the standalone client requires less code than the one that also has to do the native mode processing.
> 

For the easy of use (and interpretation of implementors and users), I suggest we really try to merge the SHOULD and MUST into one and make it so either the key assurance published in DNS is enough, or it is not.

	jakob

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 21 Sep 2010 11:22:28 -0400

> For the easy of use (and interpretation of implementors and users), I
> suggest we really try to merge the SHOULD and MUST into one and make
it
> so either the key assurance published in DNS is enough, or it is not.

Perhaps the meanings should be "Feel Free to try additional validation
if you like" and "Don't bother trying additional validation because you
can't access the validation evidence anyway".

Otherwise, why does a client need a second indication from the admin
(i.e., this flag) that the key should be accepted?  The admin has
already indicated the key should be accepted by putting the key there.
The client will decide whether or not the key assurance obtained from
DNS is enough and carry on as it chooses.  *If* there is to be something
other than the key association then why not make it a declarative
statement with evidence that can be optionally retrieved and checked (to
spare the client from retrieving everything from the source)?  

The flag is of no value when a self-signed certificate is in use.  The
client will know whether or not the certificate is self-signed (without
a flag) and will know whether or not it matches the key association.  It
will then decide to accept or deny without further processing.  The flag
offers nothing in this scenario.

The flag is of limited utility when a non-self-signed certificate is in
use.  A permissive client will accept the cert outright if the key
association matches.  A non-permissive client will perform the entire
bit of extra work.  The only case where the flag seems useful is where
the server cert is issued off of some internal CA.  

If the flag were replaced by a time and a link to (or blob containing)
some evidence (maybe an SCVP DPD response), a permissive client could
still accept the cert outright if the key association matches.  A
non-permissive client could download the information as a collection and
verify it without needing to fetch it all from the various sources.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Sep 2010 08:50:01 -0700

>can't access the validation evidence anyway".

The second could be reworded as "If you try additional validation, don't be surprised if it fails because you probably can't access the validation evidence anyway".

>the server cert is issued off of some internal CA. 

But that is an important scenario that we should consider. An organization that has many internal servers and wants to have internal control for their certs should be able to stand up their own CA, not have the devices using self-signed certs. This is a feature of Microsoft Server that people really like.

Can the semantics of the flag be changed to support this scenario better?

>verify it without needing to fetch it all from the various sources. 

In some ways, this is creating a "OCSP/SCVP over DNS" protocol. That might be interesting, but I think it is a different work item from "associate this cert with this domain name over DNS".

--Paul Hoffman, Director
--VPN Consortium

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 21 Sep 2010 12:04:31 -0400

<snip>
> The second could be reworded as "If you try additional validation,
> don't be surprised if it fails because you probably can't access the
> validation evidence anyway".

Right.  Much better.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 21 Sep 2010 21:09:35 +0200

> the server cert is issued off of some internal CA.  

The flag will be very useful in case you want to do DNSSEC-assisted key assurance in combination with a traditional PKIX certification, like EV. In that use case, the key assurance will provide important exclusion (no other certs are acceptable for the host) whereas the PKIX certification will provide stronger authentication of the key holder.

	jakob

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 21 Sep 2010 15:52:46 -0400

> The flag will be very useful in case you want to do DNSSEC-assisted
key
> assurance in combination with a traditional PKIX certification, like
> EV. In that use case, the key assurance will provide important
> exclusion (no other certs are acceptable for the host) whereas the
PKIX
> certification will provide stronger authentication of the key holder.

Why is the flag useful if I want to do traditional PKIX certification
path processing?  I still decide whether or not to do additional
processing independent of the flag.  If the flag is 1 it may still be my
*preference* to attempt validation.  As noted, I can sort of see value
in using the flag to indicate when certification path processing is
likely to fail (due to inaccessible resources) but even that just moves
the problem.  How do clients who can access the resources know to
perform validation?  

I think a flag-like value that provides some evidence that the
certificate is valid would be better, but don't disagree with Paul's
characterization that this strays into SCVP over DNS.  This could
function like a flag for clients that are not inclined to do additional
processing, and could provide additional benefit to clients that are
inclined to do additional processing.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 21 Sep 2010 22:00:18 +0200

On 21 sep 2010, at 21.52, Carl Wallace wrote:

> path processing?

the flag is useful when you want to signal to the TLS client that further validation is not needed. this will save time and resources for the client (see my use case posted in <[email-masked]>).

	jakob

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 21 Sep 2010 16:12:00 -0400

> -----Original Message-----
> From: Jakob Schlyter [mailto:[email-masked]]
> Sent: Tuesday, September 21, 2010 4:00 PM
> To: Carl Wallace
> Cc: Phillip Hallam-Baker; [email-masked]
> Subject: Re: [keyassure] Validation Preferences / Subordinate
> 
> the flag is useful when you want to signal to the TLS client that
> further validation is not needed. this will save time and resources
for
> the client (see my use case posted in <517D0949-42F2-4E59-BBB1-
> [email-masked]>).

Since the value is just a preference, I'd rather see some evidence
provided to help the client, but given current mechanism we're more or
less just discussing different verbiage (i.e., the current
sufficient/insufficient language vs. available/unavailable).  I think
some clients will be permissive and some won't, flag notwithstanding.
Hence the flag providing little value.

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 21 Sep 2010 22:14:57 +0200

> Hence the flag providing little value.

I believe we need some mechanism to tell the permissive client that there is more information (like EV) available if it continues with PKIX validation. I agree with you that a non-permissive client will ignore the flag anyway (and continue their quest for final trust).

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Sep 2010 17:13:11 -0400

On Tue, Sep 21, 2010 at 3:09 PM, Jakob Schlyter <[email-masked]> wrote:

> The flag will be very useful in case you want to do DNSSEC-assisted key
> assurance in combination with a traditional PKIX certification, like EV. In
> that use case, the key assurance will provide important exclusion (no other
> certs are acceptable for the host) whereas the PKIX certification will
> provide stronger authentication of the key holder.
>

I really do not accept that an assurance delivered via CERT should be
exclusive.

The text in section 3 of the Hofman et. al. draft does not make these
semantics explicit. I think that such semantics in a CERT record would be a
terrible idea.

If we are going to define semantics of that type we need to consider other
mechanisms for defining the allowable trust roots for a domain.

We can get the assignments for the CERT record certificate types to do key
assurance without even creating a working group. Attempting to use the CERT
record to implicitly establish a root of trust for a domain is a very
different issue.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Sep 2010 14:49:44 -0700

At 5:13 PM -0400 9/21/10, Phillip Hallam-Baker wrote:
>I really do not accept that an assurance delivered via CERT should be exclusive.
>
>
>The text in section 3 of the Hofman et. al. draft does not make these semantics explicit. I think that such semantics in a CERT record would be a terrible idea.
>
>If we are going to define semantics of that type we need to consider other mechanisms for defining the allowable trust roots for a domain.
>
>We can get the assignments for the CERT record certificate types to do key assurance without even creating a working group. Attempting to use the CERT record to implicitly establish a root of trust for a domain is a very different issue. 

Phill has said this before, and has said that having such a "root of trust" should be explicitly excluded from the charter.

Please discuss so that we can close out work on the charter.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Wed, 22 Sep 2010 00:04:33 +0100

> If we are going to define semantics of that type we need to consider other mechanisms for defining the allowable trust roots for a domain.

There are three gaps that need to be filled:

1. Use the DNS as another x.509 trust anchor.
2. Assert that a service requires TLS.
3. Prevent tinpot CAs from claiming to authenticate a service.

You want 3 to be out of scope.

If you allow CERT records to identify a certificate that (transitively) signs the service's certificate, rather than just the service's certificate(s) directly, then you have a fair way of defining the allowable trust anchors, and of addressing the many-certificate problem.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 22 Sep 2010 07:29:34 -0400

> I believe we need some mechanism to tell the permissive client that
> there is more information (like EV) available if it continues with
PKIX
> validation. I agree with you that a non-permissive client will ignore
> the flag anyway (and continue their quest for final trust).

You have cited EV as a motivator for this flag several times.
Certificates have an EV indicator already (in the certificate policies
extension) - no flag necessary for this.

---

From: "Carl Wallace" <[email-masked]>
Date: Fri, 24 Sep 2010 10:25:21 -0400

for
> the client (see my use case posted in <517D0949-42F2-4E59-BBB1-

The flag is more likely to waste time and resources than save time and
resources.  Assume my client is configured to require EV (or whatever)
for sites that are important to me and be permissive for everything else
(i.e., process key association and advice from DNS per the draft).  If I
am willing to accept just a key association match for everything else,
then each time the flag indicates validation should be performed I will
waste time and resources.  For sites that are important to me, I guess
it could save me time by failing without even attempting validation
(possibly resulting in failure where success may have been possible).
This is inconsistent with its stated purpose though.