Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 28 Oct 2010 17:17:48 -0500 (GMT-05:00)

Stephen and all,

-----Original Message-----
>From: Stephen Farrell <[email-masked]>
>Sent: Oct 28, 2010 4:14 PM
>To: Paul Hoffman <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] PKIX/KIDNS validation results and	draft-hoffman-keys-linkage-from-dns
>
>
>Having now caught up with the many recent messages, I'd also
>be a bit concerned about the impact of:
>
>> "If a match between the certificate association(s) and the 
>> server's end entity certificate in TLS is not found, the
>> TLS client MUST abort the handshake with an "access_denied" error."
>
>The concerns I have about it would include:
>
>- I'm not really sure if that same rule would be appropriate
>  for all applications that use TLS, nor for all deployments
>  of each protocol using TLS - basically the policy slippery
>  slope PHB is raising (from time to time:-)

yeah this is a valid concern, but we do need to be explicit here.

>- I think the security implications (e.g. potential for it
>  being a DoS vector e.g. if some DNS management nodes
>  were compromised) would need to be considered

Absolutely.

>- We'd need to think about whether any corner cases might be
>  problematic e.g. where an LDAP query for a CRL was running
>  over TLS or something

Agreed here as well for what i would consider obvious and
perhaps significant reasons.  As such the relevant discussions
regarding this should be cooridinated with the LDAP WG accordingly.
How that is to be effected may be problamatic.

>- I'm not sure what RFCs would be being UPDATED by an
>  RFC saying that, nor whether something like that should
>  really be left to the TLS WG

Good point.  I'm not sure either.  But just leaving it to the
TLS WG without close coordination would seem to be a bit 
unwieldy to me.

>
>It could be that folks have already thought through some
>or all of that, and that that MUST is the right thing to
>do, but that's not clear to me at this stage, so I do think
>that a kidns WG (which I think is worth forming) would really
>have to figure out answers to the above.

FWIW and going out on a limb here, the kidns WG would seem to be
the most logical place to centeralize the discussion on your above
reasonable concerns/considerations.  
>
>S.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 30 Oct 2010 11:28:49 -0500 (GMT-05:00)

Steve and all,

-----Original Message-----
>From: Steve Schultze <[email-masked]>
>Sent: Oct 30, 2010 10:05 AM
>To: [email-masked]
>Ben, I'm porting your comment below into this thread for the sake of subject-line clarity (none of this is WG-formation specific, I believe).
>
>On Oct 29, 2010, at 8:33 AM, Ben Laurie wrote:
>> Paul wants client policy to decide whether to trust PKIX, DNSSEC or
>> some mixture of the two. This seems not only reasonable, but
>> unavoidable: clients will implement what suits them, and we are in no
>> position to change that.
>> 
>> Phillip wants the domain in question to be able to state its
>> intentions w.r.t. the policy clients should use. This seems not
>> unreasonable, also. Clients can choose to follow this or not.
>
>What effect does this have on the MUST vs. MAY suggestions I made to the draft-hoffman-keys-linkage-from-dns-03 text?  I believe that what you are saying is that the spec should leave it open to the client how to react to different validation outcome permutations from PKIX and DNSSEC-secured KIDNS.  In that case, the two excerpts I quoted should be MAY, as I suggested.  This also means that I disagree with Paul, who thinks that MUST should be used.

  I prefer MAY over must, but only barely.  I thought Paul H. suggested MAY?
Anyway, MAY covers the corner cases discussed, which is why I only barely
prefer it.  
>
>I would note that, presuming KIDNS only affects client behavior when the client can directly verify that the records were validly DNSSEC-signed (is this everybody's assumption?), using a MUST creates a downgrade attack in which a MITM can force PKIX-only validation by simply blocking DNSSEC-validated DNS results.

Very good point!  And yes to your question from me anyway.
>
>"If the application receives zero usable certificate associations, it [MUST] process TLS in the normal fashion."
>
>We want the client to be able to choose to require DNSSEC-validated KIDNS for all requests, if it wishes.  Otherwise what we're doing offers no greater security than the status quo.

  I agree.
>
>On Oct 28, 2010, at 5:52 PM, Paul Hoffman wrote:
>> Thank you for being explicit!
>> 
>> At 10:14 PM +0100 10/28/10, Stephen Farrell wrote:
>> OK, maybe try being more explicit. For example, if this document was in fact an update to TLS, would you have the same concern? Or, if you want a SHOULD rather than a MUST, what would the specific exceptions be (or are you asking for a typical IETF mushy SHOULD)?
>
>I don't know what Stephen Farrell is arguing for, but I'm arguing for an even more mushy MAY ;)
>
>However, this is a feature because it gives the clients more options... including the option to improve upon the status quo of PKIX security even in the presence of a MITM (our assumed threat model).  It does so without forcing all clients to do this on day one, an impractical requirement.
>
>On Oct 28, 2010, at 1:11 PM, Stephen Schultze wrote:
>> "If the application receives zero usable certificate associations, it process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MUST abort the handshake with an "access_denied" error."
>> 
>> I suggest:
>> 
>> "If the application receives zero usable certificate associations, it MAY process TLS in the normal fashion."
>> "If a match between the certificate association(s) and the server's end entity certificate in TLS is not found, the TLS client MAY abort the handshake with an "access_denied" error."
>
>

Regards,
Jeffrey A. Williams

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 30 Oct 2010 13:19:14 -0500 (GMT-05:00)

Steve and all,

I think we all agree here.  I also think that perhaps there is and has been a language conjugation

problem here.  That being how someone else specifically understands the conjugation of

anothers writing...  But I do think that Phillip is right that the language in draft-hoffman-keys-linkage-from-dns

misses the mark in respect to it's explicitness and as such lends it self to perhaps some interpratation,

which has already been pointed out before and seemingly again here, as to it's lack of clarity in some

respects.

-----Original Message-----
From: Steve Schultze
Sent: Oct 30, 2010 12:58 PM
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:

What I do have a problem with is 'this is the fingerprint of the ONLY certificate(s) I will use".

+1 on Ben's question.  Would you be fine if the semantics allow the holder to specify that it is exclusive?  If so, assume that case in my comments below.

On Oct 30, 2010, at 1:03 PM, Phillip Hallam-Baker wrote:

> The only role that the client can play is to choose to respect those semantics or not.

And in my version this is the case.  The client decides whether a validated KIDNS record is sufficient or necessary.

That is only possible if you have an expectation that every domain that publishes the records will publish them for every certificate and keep them up to date.

What is only possible?  Allowing the client to choose?  I don't understand what you're getting at.  There should be no reason why a client shouldn't be able to say "I will only accept connections when the cert is validated via DNSSEC-KIDNS."  Sure, this means they can't connect to any sites that haven't done that, but that's the point.

If you want to have interoperability every client has to draw the same semantics from a given record. They do not have to react in the same way but they do have to interpret the intention of the domain holder in the same way.

I don't see how we disagree.  If all that is needed is to have a flag such that the holder can indicate exclusivity, then let's do that and we all agree.

In the PKIX model and the OpenPGP model the certificates have the exact same semantics for every relying party.

Different relying parties may react differently because the local site policy is different. In some cases a client may be allowed to act on a certificate with only a partial understanding of those semantics., in others the critical bit is set to force a client to ignore a cert it does not fully understand.

Again, presuming a "yes" answer to Ben's question I think we all agree.

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 30 Oct 2010 13:26:36 -0500 (GMT-05:00)

Steve and all,

-----Original Message-----
>From: Steve Schultze <[email-masked]>
>Sent: Oct 30, 2010 12:50 PM
>To: [email-masked]
>On Oct 30, 2010, at 12:19 PM, Ben Laurie wrote:
>> Surely not - in this case the client sees DNS failures, rather than a
>> lack of results and so should squawk about that problem.
>
>There would only be DNS failures if the MITM were blocking responses altogether, rather than returning bogus responses containing no KIDNS (non-DNSSEC-validated, of course).  Unless you assumed that a client would always bail unless it got a validated DNSSEC response, which is not viable to mandate... especially on day one.

  Good reiterated point, and agreed.  Especially that we do not now, nor
can I ever invision that we can ever will have absolute trust that ALL DNSSEC responses that fail or not, are properly/accurately validated although they may be "authoritatively".

Regards,
Jeffrey A. Williams

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sat, 30 Oct 2010 15:54:15 -0500 (GMT-05:00)

-----Original Message-----
From: Steve Schultze
Sent: Oct 30, 2010 3:39 PM
To: [email-masked]
Subject: Re: [keyassure] PKIX/KIDNS validation results and draft-hoffman-keys-linkage-from-dns

On Oct 30, 2010, at 4:13 PM, Matt McCutchen wrote:

Ok, and I am suggesting the client should be allowed to do that in our

spec.  In the language of RFC 4033, it seems that the client would

require  "secure" state plus a valid KIDNS record.

Right.

Or a "secure" denial of existence of an exclusive KIDNS record.  Signed
zones don't necessarily use exclusive KIDNS.  People would be up in arms
if signing their zone suddenly broke all their TLS servers.

Right.

They might also allow an "insecure" state plus a validating PKIX cert.

Right, that is the idea for a backward-compatible client.  "Secure"
zones that opt in to exclusive KIDNS get the presumed security benefits,
everyone else's traditional PKIX certificates continue to work.

Right.

The vulnerability would only manifest itself if the client allowed

"indeterminate" state and a validating PKIX cert.

As I read it, "indeterminate" means the zone is not within the scope of
any of the configured trust anchors.  This is basically equivalent to
"insecure": in both cases, the client knows that, with respect to its
trust anchor configuration, the zone is not signed.  This condition
cannot be faked by a MITM attacker.

Right,

Unless the trust anchor was the culprit OR the Trust anchor had itself been compermised in some

way, and/or the CA Cert Database had been corrupted accordingly.

Yes, "indeterminate" == "insecure" if the client requires DNSSEC validation. But that would require a MUST NOT in place of the current (implied) MUST in draft-hoffman-keys-linkage-from-dns:

...or maybe that's not actually the right place because it presumes that the response is already validated by DNSSEC:

"The DNSSEC signature MUST be validated on all responses in order to assure the proof of origin of the data."

What the current draft does not say is what the client MUST or MAY do if the client is not able to request, perform, or verify DNSSEC validation at all.  The answer will affect the viability of my MITM scenario.

DNSSEC guarantees that if the client queries a zone that is signed (with
respect to its trust anchor configuration), it either gets an
authenticated answer or fails.  We can build upon this property to
distribute KIDNS info in signed zones and know that KIDNS-aware clients
will not proceed without it.

It's not clear to me, at least in the draft-hoffman-keys-linkage-from-dns draft, that we can "know that KIDNS-aware clients

will not proceed without it."  I don't see any explicit statement to this effect.  I encourage Paul or the others to chime in as to whether this was their intent.

Good point and I agree.  Diliniating the intent is important here.

Regards,

Jeffrey A. Williams