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

From: Stephen Schultze <[email-masked]>
Date: Thu, 28 Oct 2010 13:11:56 -0400

draft-hoffman-keys-linkage-from-dns-03:

"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."

This leaves it up to the client how to deal with the relationship  
between KIDNS and PKIX validation results.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Oct 2010 10:31:21 -0700

At 1:11 PM -0400 10/28/10, 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."
>
>This leaves it up to the client how to deal with the relationship between KIDNS and PKIX validation results.

RFC 2119 language is used for two reasons: interoperability and security.

The first of your two changes makes no sense: if there are no usable certificate associations, then there is no new information for TLS. If an implementer has chosen not to follow the TLS semantics, there is nothing that this protocol has to offer.

Can you say how you think your second change improves either interoperability or security?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Oct 2010 22:14:19 +0100

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

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.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Oct 2010 14:52:53 -0700

Thank you for being explicit!

>  slope PHB is raising (from time to time:-)

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

>  were compromised) would need to be considered

If a DNS management node were compromised, all bets are off anyway. I guess we thought that was obvious, but we should say that in the Security Considerations.

>  problematic e.g. where an LDAP query for a CRL was running

Those are no different in this document than in normal TLS, are they? That is, what does this document change in TLS that would add such a corner case? That would be important to analyze.

>  really be left to the TLS WG

It should be done in coordination with the TLS WG, if this WG is formed and this is the way that the WG wants to go.

>have to figure out answers to the above.

Fully agree. Please fill in any of the above after the WG is formed and if this is the direction that the WG goes.

--Paul Hoffman, Director
--VPN Consortium

---

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 11:05:50 -0400

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 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.

"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.

> 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…

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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 11:28:57 -0400

Lets think about 'client makes a choice'

What it sounds like to me is that people are suggesting that it is up to the
client to decide what semantics that the domain name holder intended when
they published the record.

That cannot possibly work.

The publisher of the record has to have sole control of what the semantics
of the record are.

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

We cannot address this 'Phill wants one thing', 'others want another' by
deciding that client can interpret the same set of bits in different ways.

We have to have different bits for the two purposes.

I want to have a clean separation because the only way I can see support for
draft-hoffman being feasible is if either the site operates its own PKI and
DNS or the CA operates both the DNS and the certs for the site.

I know what everyone here (myself included) would prefer the first. I would
much rather be teaching people how to run their DNS CA infrastructure at
$800 per person per day through my private consulting business or selling
them training videos. But most people just want this to be something they
just sign a cheque for and forget.

On Sat, Oct 30, 2010 at 11:05 AM, Steve Schultze <[email-masked]> wrote:

> 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).
>
> 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 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.
>
> [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.
>
> > 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)?
>
> 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.
>
> > "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 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."
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 11:42:30 -0400

On Oct 30, 2010, at 11:28 AM, Phillip Hallam-Baker wrote:
> What it sounds like to me is that people are suggesting that it is up to the client to decide what semantics that the domain name holder intended when they published the record.

What is being suggested is that the domain name holder has the semantics to say, "this is the fingerprint of the certificate I will use." 

> The publisher of the record has to have sole control of what the semantics of the record are.

And they do, presuming they are articulating what I stated above.

> 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.

(There may be other things that the domain holder can state in DNS, along the lines of what you have suggested elsewhere, which I think are equally subject to client discretion in the same fashion.)

This is parallel to what we have today with the PKIX/CA model.  Servers present certs which the client decides to trust or not, based on its root cert store, customized trust bits, and user override.  This is a feature because it allows clients with different trust preferences to operate in a way that respects those.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 30 Oct 2010 17:19:57 +0100

On 30 October 2010 16:05, Steve Schultze <[email-masked]> wrote:
> What effect does this have on the MUST vs. MAY suggestions I made to the draft-hoffman-keys-linkage-from-dns-03 text?

I have temporarily given up on trying to stay up-to-date with the
various I-Ds until the dust on chartering settles so I can't currently
answer that.

>  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.
>

Surely not - in this case the client sees DNS failures, rather than a
lack of results and so should squawk about that problem.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 30 Oct 2010 17:21:34 +0100

> The only role that the client can play is to choose to respect those

Exactly, though it could also be that the semantics even if respected
give the client choice about how to react.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 13:03:10 -0400

On Sat, Oct 30, 2010 at 11:42 AM, Steve Schultze <[email-masked]> wrote:

> > What it sounds like to me is that people are suggesting that it is up to
> the client to decide what semantics that the domain name holder intended
> when they published the record.
>
> What is being suggested is that the domain name holder has the semantics to
> say, "this is the fingerprint of the certificate I will use."

Which I have no problem with.

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

We cannot have interoperability unless the clients all have a precise
agreement on the intended semantics. The person (or robot) who publishes the
name in the domain needs to understand precisely how clients will react and
plan for the most restrictive case.

> 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.

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.

> (There may be other things that the domain holder can state in DNS, along
> the lines of what you have suggested elsewhere, which I think are equally
> subject to client discretion in the same fashion.)
>
> This is parallel to what we have today with the PKIX/CA model.  Servers
> present certs which the client decides to trust or not, based on its root
> cert store, customized trust bits, and user override.  This is a feature
> because it allows clients with different trust preferences to operate in a
> way that respects those.

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.

Specifying standards for specifying local security policy is hard and
possibly unnecessary. SAML specifies attributes for Authentication,
Authentication and Attributes, all of which provide inputs to security
policy but does not specify how those inputs are to be processed.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 30 Oct 2010 18:16:10 +0100

On 30 October 2010 18:03, Phillip Hallam-Baker <[email-masked]> wrote:
>> What is being suggested is that the domain name holder has the semantics
>> to say, "this is the fingerprint of the certificate I will use."
>

You do agree that the holder should have the _option_ to say that, right?

---

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 13:50:45 -0400

> 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.

---

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 13:58:20 -0400

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:
> 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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 13:58:53 -0400

Yes, the holder should have the option.

But it does need to be an option and not something that is automatically
assumed.

And it has to be something that is considered explicitly in the design.

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 30 Oct 2010 14:20:40 -0400

On Sat, 2010-10-30 at 13:50 -0400, Steve Schultze wrote:
> >> 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.
> > 
> 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.

DNSSEC was specifically designed to address this concern (see RFC 4033
section 5).  The client can require either a valid DNSSEC response or a
proof that the target zone is not using DNSSEC, in which case the client
behaves as if the zone contains no KIDNS information.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 14:24:12 -0400

I am fine with this as an option.

But I think that making it useful and scalable requires us to provide more
than just a flag.

What we are proposing here is an aspect of security policy. Which gets us
into territory that is generally considered 'difficult' and every security
AD that I have ever discussed this with has expressed extreme skepticism as
to whether a WG can get to closure if it addresses security policy. The term
'rat hole' is used.

I think that we have to divide the security policy into two parts. The first
part is providing inputs to security policy, the second part is security
policy processing.

I think we can point to a lot of experience in defining standards for
presenting information in a form that can be used as input to security
policy processing. We have many proof points for being able to get to
closure (DKIM, SAML, etc.)

The second half, security policy processing is where it is very difficult to
get agreement on in my view. That is the place that we could not address
usefully in SAML, it is also a minefield for IPR.

If we can agree on a mechanism for specifying 'my valid keys look like X', I
think we can certainly agree on 'I always offer SSL on SMTP'.

On Sat, Oct 30, 2010 at 1:58 PM, Steve Schultze <[email-masked]> wrote:

> +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.
>
>> And in my version this is the case.  The client decides whether a
>> validated KIDNS record is sufficient or necessary.
>>
>
> 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.
>
> 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.
>

---

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 15:04:04 -0400

On Oct 30, 2010, at 2:20 PM, Matt McCutchen wrote:
> section 5).  

Ah, interesting.  The four states described there is illuminating.

> The client can require either a valid DNSSEC response

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.  They might also allow an "insecure" state plus a validating PKIX cert.  The vulnerability would only manifest itself if the client allowed "indeterminate" state and a validating PKIX cert.  I think that it is just another way of expressing what I was describing.  Presuming the client can know these states, or the default behavior of the client's resolving code prohibits "indeterminate" responses (is this likely?), I think you're right that it solves my problem.  Right?

> or a proof that the target zone is not using DNSSEC

Of course this _also_ requires a valid DNSSEC response in the state of "insecure", per Section 5:
"at some delegation point, signed proof of the non-existence of a DS record"

> in which case the client behaves as if the zone contains no KIDNS information.

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 30 Oct 2010 16:13:29 -0400

On Sat, 2010-10-30 at 15:04 -0400, Steve Schultze 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.

> They might also allow an "insecure" state

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.

> 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.

> 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.

Note that if you use the IANA trust anchor for the root zone, nothing
will be indeterminate.

> I think that it is just another way of expressing what I was
> describing.

I'm not sure what you mean.

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.  For everyone else (signed zones without
KIDNS info, and zones known to be unsigned), the old semantics apply.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 30 Oct 2010 16:29:32 -0400

> But I think that making it useful and scalable requires us to provide more

Can you provide a specific, compelling example?

> 'rat hole' is used. [...]

The flag has a simple and clear semantic, "I authorize this certificate
and only this certificate for use on my TLS server", and is already
useful to folks like me who can't wait to publish a single exclusive
certificate in DNSSEC and no longer be exposed to the likes of Etisalat.
You seem to be saying that we should hold off on standardizing the
exclusivity flag because there are some use cases that require a more
sophisticated scheme, but also that we might never complete such a
scheme.  So what can be the benefit of waiting, compared to
standardizing the flag now?

-- 
Matt

---

From: Steve Schultze <[email-masked]>
Date: Sat, 30 Oct 2010 16:39:24 -0400

Right.

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

Right.

> cannot be faked by a MITM attacker.

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.

> 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.

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 30 Oct 2010 18:23:23 -0400

On Sat, 2010-10-30 at 16:39 -0400, Steve Schultze wrote:
> 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.

Yes, I think it is cleanest to treat DNSSEC as a black box that produces
one of the four security states and build from there.  Here is some
proposed text for Section 3.

-----
To validate the certificate of a TLS server using KIDNS, the client
SHALL perform a DNSSEC query for TLSFP and TLSRQ records at the domain
name of the TLS server.  If a TLSRQ record is returned, the client SHALL
perform a second query based on the certificate actually presented by
the TLS server as described in section 2.2.

If any query cannot be completed or gives a "bogus" result as described
in RFC 4033 section 5, validation MUST fail and the client MUST abort
the TLS handshake (if it has been started) with a "TBD" error.
Otherwise, if any query gives an "insecure" or "indeterminate" result,
KIDNS cannot be used with this TLS server, and the client MAY use an
alternative certificate validation method.

In the remaining case, all queries have given "secure" results.  The
client collects all TLSFP records from the initial query and the second
query if applicable and discards any whose hash types it does not
understand.  If no records remain, KIDNS does not apply and the client
MAY use an alternative method.  Otherwise, if the certificate presented
by the server matches any of the TLSFP records, validation succeeds; if
not, it fails and the client MUST abort the TLS handshake with an
"unknown_ca" error.
-----

Note, I think the proper error when the certificate doesn't match any of
the TLSFP records is "unknown_ca", by analogy to a certificate that
doesn't chain to any PKIX trust anchor.  Based on the description in RFC
5246, I think "access_denied" is for a server to tell a properly
authenticated client that authorization to use the service is denied.

I'm not sure what would be the best error for when the DNSSEC query
fails.

This is still assuming TLSFP is exclusive.  If that were made a flag,
then we would just change the last case (presented certificate doesn't
match any TLSFP) to fall back to the alternative method if the flag is
off.

-- 
Matt

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 31 Oct 2010 02:22:02 +0300

> alternative certificate validation method.

Looking at the list of error codes, the only ones that I think could apply
would be codes 80(internal_error) and 90(user_canceled).

-Ilari

---

From: James Cloos <[email-masked]>
Date: Sat, 30 Oct 2010 20:07:18 -0400

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

MM> Yes, I think it is cleanest to treat DNSSEC as a black box that
MM> produces one of the four security states and build from there.
MM> Here is some proposed text for Section 3. ...

That seems to sum up what I'd like to see from KIDNS:  the possibility
of using dnssec as one's only trust anchor and also the ability to
slowly transition from current practice.  Clients will need to do the
latter anyway; any KIDNS standard should cover that explicitly.  And
the former is a big win, long term, over the status quo.

The only possible issue is the question of whether the client should
perform queries for names like www.example.com. or _http._tcp.www.example.com.?

Or both, preferring the more specific if both exist?

The more specifc option permits different certs for, eg, _http._tcp
vs _smtp._tcp vs _sip._tcp, but also means maintaining probably
identical RRs for eg _sip._tcp, _sip._udp and _sip._sctp.

I can see how each might be perceived as necessary, but also how each
might be perceived as undesirable.

(Incidently, in the more-specific case, would the CA for a given RHS's
smime certs be sought at _smime.example.org. or _smime._???.example.org?)

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

---

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 20:28:52 -0400

> 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 creat…

Actually, a MITM who is blocking DNSSEC-validated DNS results is detectable and (IMO) evidence that Something Bad(tm) is happening, and that you should take your ball and go home.... 

Also, not quite sure that this is the best place to bring this up (but I couldn't find a better place in the thread), but the "client can directly verify that records were validly DNSSEC-signed" has some subtleties -- there are three options (although I could have forgotten some):

1: The client just blindly trusts the AD bit (a bit set by the recursive resolver to say (basically) "I have done the DNSSEC verification magic and this is all authenticated data, trust me...."). I'm assuming that everyone here agrees that this is a horrendous idea.

2: The client performs all of the DNSSEC verification itself -- I'm assuming again that everyone here agrees that (from a security standpoint) this is good.

3: The client trusts a response with the AD bit set but ONLY if it has received this response over some sort of "secure" channel that provides authentication of the transport and validation that you are talking to the correct recursive resolver, and the client has some reason to trust the resolver. An example of this would be a VPN (or SIG(0)) to a corporate or contracted resolver operator. To me, while still much much better than option 1, it is not actually a *good* idea -- I would like to know what the list thinks though....

W

---

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 20:30:02 -0400

W

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 31 Oct 2010 03:01:46 +0200

> Or both, preferring the more specific if both exist?

If the lookups are done after resolving indirection by SRV, one could
get along with optional port numbers and protocols (as in, UDP, TCP,
SCTP...).

Basically, a way to limit some TLSFP record to just some (protocol,port)
pairs and then the client would remove the entries that have wrong ports
just like entries that have unknown hash function.

This would also allow the "assure SMTP but not yet HTTP" case (by putting
an entry that covers just the SMTP ports)...

But of course that plan wouldn't work as-is if TLSFP lookups would have
to be done before SRV for some reason...

-Ilari

---

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 21:02:20 -0400

> perform queries for names like www.example.com. or _http._tcp.www.example.com.?

This is another question that has been repeatedly raised (partly in the guise of "if you post a record for your webserver it will break mail").
I (no hats) was against the _selector_ idea as I feel that all records related to a thingie (technical term) should exist at the same level (

foo.example.com         IN   A     192.0.2.1
		        IN   BAR     42
                        IN   KIDNS  54690765349763590
), but this is an elegance viewpoint and enough folk have pointed out that this is a needed feature that I'm open to it as an idea....

Another option (which has some (IMO) of the elegance retained, but probably has scalability and leakage issues) is 
foo.example.com     IN A 192.0.2.1
                    IN KIDNS 443 545254634563546354
                    IN KIDNS 993 435245243523452345
                    IN KIDNS 5222 23452345435234545
) -- basically, have the records for foo.example.com (or just exmaple.com) all at the same level, but have the ports included in the response.

> Or both, preferring the more specific if both exist?

Oooh, that's interesting -- to be honest I hadn't thought of that... One huge consideration is minimizing the number of DNS lookups needed to make all the magic happen -- if this system requires lots of lookups, the browser folk will be unwilling to implement as the user experience will be horrendous....

> might be perceived as undesirable.

Yes, both are (IMO) sub-optimal -- my *personal* view of the world involves having unique names for each service (www.example.com, imap.exmaple.com, jabber.example.com) which sidesteps this issue, but enough folk have raised this issue that it needs to be addressed....

As for exactly how (ports in the response, selectors, something else), that is something that we (with input from DNS folk) need to discuss and come to agreement on....

W

---

From: Warren Kumari <[email-masked]>
Date: Sat, 30 Oct 2010 21:18:53 -0400

[ Replying to myself ] 

Apologies to the list, I have just reinstalled a machine for bringing to the meeting and forgot to turn off the "Rich Text with Random Markups and Embedded Garbage" knob in my MUA before replying...

While on the topic of list etiquette and similar things, I just wanted to thank everyone for playing nicely on this thread -- I feel that we are beginning to make progress again and are (hopefully) starting to see each others points again...

W

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 31 Oct 2010 03:37:35 +0200

On Sat, Oct 30, 2010 at 09:02:20PM -0400, Warren Kumari wrote:
> This is another question that has been repeatedly raised (partly in the guise
> of "if you post a record for your webserver it will break mail").

> ) -- basically, have the records for foo.example.com (or just exmaple.com)
> all at the same level, but have the ports included in the response.

Or allow multiple ports per entry (and also "all ports"?). Multi-port
responses could be useful for example for covering webserver supporting
upgrades (TCP80/TCP433) or SMTP server supporting upgrades
(TCP25/TCP465/TCP587).

Oh, and sometimes TCP X and UDP X are not the same service (usually those
are). But I think all cases are some legacy services that aren't going
to support KIDNS anyway... So just going by port number and forgetting
the proto is likely feasible...

Designing wire format for that is not difficult. Getting sane master
format notation might be...

Also, this doesn't solve the service leakage issues.

> Oooh, that's interesting -- to be honest I hadn't thought of that...
>
> One huge consideration is minimizing the number of DNS lookups needed
> to make all the magic happen -- if this system requires lots of
> lookups, the browser folk will be unwilling to implement as the user
> experience will be horrendous....

What's the likely amount of stuff in those _<serv>._<prot>.<domain>
spaces? Little enough to make issuing QCLASS * requests feasible?

Being able to QCLASS * it could also get other possibly usable
stuff (like secure service discovery[1] data, but that's a seperate
topic...)

[1] Inform client that secure service exists and how to connect to
it. 

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 30 Oct 2010 21:48:41 -0400

> Can you provide a specific, compelling example?

We have multiple protocols in use at most sites on a given domain.

The easiest way to get to critical mass in my view is to enable sites to
deploy for SMTP, IMAP, POP and other protocols where SSL is used but the
clients do not make much use of the CA infrastructure and there is no use of
EV.

To make that practical it has to be possible to have statements of the form
'only trust these certs for protocol X'.

The other reason for wanting something other than a flag is that managing
public keys on a large scale is time consuming and requires infrastructure.
That infrastructure already exists for X.509/PKIX, many if not most
enterprises who would be possible early adopters of this type of management
scheme already have an X.509/PKIX infrastructure deployed.

So for those domains it is going to be much easier to publish a statement
'all valid certs fall under this hierarchy' than 'all valid certs have a
fingerprint'.

I think we need to offer both options.

> standardizing the flag now?

No, I am saying that it has been very difficult to get anything that falls
under the 'security policy' bracket accepted as a WG charter item because
security policy is a notorious rat hole.

What we are proposing is a set of protocol specific security assertions and
not a security policy processing mechanism.

So what I am saying is that I think we can craft a very precise statement
that allows us to do exactly what we would like to do without triggering
rodent dwelling concerns.

---

From: James Cloos <[email-masked]>
Date: Sun, 31 Oct 2010 00:51:32 -0400

>>>>> "IL" == Ilari Liusvaara <[email-masked]> writes:

IL> If the lookups are done after resolving indirection by SRV, one
IL> could get along with optional port numbers and protocols (as in,
IL> UDP, TCP, SCTP...).

I do like the idea of using SRV or NAPTR RRs.  Of course, if you are
going to resolve _sip._tcp.example.com. IN SRV, then it makes sense to
also resolve _sip._tcp.example.com. IN TLSFP.  Maybe it would even be
better to just resolve _sip._tcp.example.com. IN ANY and expect both
in the same reply.  (Is that, with the dnssec overhead, still small
enough for a udp packet?)

IL> Basically, a way to limit some TLSFP record to just some (protocol,port)
IL> pairs and then the client would remove the entries that have wrong ports
IL> just like entries that have unknown hash function.

Makes sense.

IL> This would also allow the "assure SMTP but not yet HTTP" case (by putting
IL> an entry that covers just the SMTP ports)...

IL> But of course that plan wouldn't work as-is if TLSFP lookups would have
IL> to be done before SRV for some reason...

Unless the TLSFP lookup is for the same name as the SRV lookup, rather
than having to be for the result of the SRV lookup.

If I have '_sip._tcp.b.net. 3600 IN SRV 0 0 5060 a.b.net.' and someone
wants to talk to sip:[email-masked], should they expect the TLS cert to cover
b.net or a.b.net?

-JimC

---

From: James Cloos <[email-masked]>
Date: Sun, 31 Oct 2010 00:53:54 -0400

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> One huge consideration is minimizing the number of DNS lookups
WK> needed to make all the magic happen -- if this system requires lots
WK> of lookups, the browser folk will be unwilling to implement as the
WK> user experience will be horrendous....

Agreed.  That was why I posed the 'either/or but use the most specific'
as a question.

-JimC

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 31 Oct 2010 12:40:02 -0400

+1

I think that the key to doing this effectively and efficiently is to look
carefully at SRV, NAPTR and URI while we do this.

Prefix records have some pretty complicated limitations. But I think they
are necessary in this case and I think we can avoid all of the problems that
they entail.

On Sun, Oct 31, 2010 at 12:51 AM, James Cloos <[email-masked]> wrote:

> wants to talk to sip:[email-masked] <[email-masked]>, should they expect the TLS
> cert to cover
> b.net or a.b.net?
>
> -JimC
> --

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 31 Oct 2010 13:38:58 -0400

On Sat, 2010-10-30 at 21:48 -0400, Phillip Hallam-Baker wrote:
> The easiest way to get to critical mass in my view is to enable sites
> to deploy for SMTP, IMAP, POP and other protocols where SSL is used
> but the clients do not make much use of the CA infrastructure
> and there is no use of EV.

Umm, all the protocols use the CA infrastructure to make boolean
accept/reject decisions for certificates.  I guess you mean other use of
the certificate information?

Sure.  But I'd argue the same is true of non-EV web sites: I haven't
seen any meaningful use made of the certificate information there.
Browsers will show you the certificate under which the main HTML page
was received, but that tells you nothing about any other acceptable
certificates floating around that might allow others to tamper with the
page under the same-origin policy.

> To make that practical it has to be possible to have statements of the
> form 'only trust these certs for protocol X'.

Or simply make the statement "trust this cert" specific to the protocol
by placing the record at the SRVName.  That seems more elegant to me.

> The other reason for wanting something other than a flag is that
> managing public keys on a large scale is time consuming and requires
> infrastructure. That infrastructure already exists for X.509/PKIX,
> many if not most enterprises who would be possible early adopters of
> this type of management scheme already have an X.509/PKIX
> infrastructure deployed.
> 
> So for those domains it is going to be much easier to publish a
> statement 'all valid certs fall under this hierarchy' than 'all valid
> certs have a fingerprint'.

Good point.  This is probably true of my university, which just made a
deal with a public CA to provide all their certificates.

Will it work to accept a presented certificate that either matches or
chains up to a TLSFP certificate?  Then one could publish the hash of
the end-entity certificate or some intermediate or root certificate,
possibly modified (and re-signed, the client doesn't care about the
signature anyway) to apply whatever extra PKIX-y restrictions the
software might support.  Any certificates the client can't be assumed to
have and the server doesn't send can be published in unassured CERT
records.

> No, I am saying that it has been very difficult to get anything that
> falls under the 'security policy' bracket accepted as a WG charter
> item because security policy is a notorious rat hole.
> 
> What we are proposing is a set of protocol specific security
> assertions and not a security policy processing mechanism.
> 
> So what I am saying is that I think we can craft a very precise
> statement that allows us to do exactly what we would like to do
> without triggering rodent dwelling concerns.

Good.

-- 
Matt