Subject: [dane] Text in S 4.4

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Oct 2011 17:37:40 -0700

S 4.4 reads in part:

   An application that complies with this document first requests TLSA
   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.

I'm not sure this is the right answer.

I see three issues here:

1. Should there be a mandatory fail here.
2. Should that fail be expressed as a TLS alert.
3. Should that alert be access denied.

Taking these in order.
1. It's not clear to me that this MUST is that useful, since after all, one can
just process DANE records, throw an error up the user and then by
"noncompliant" but still functional. This looks to me like a case of
over-specification of policy rather than mechanism.

2. It's not at all clear to me that this ought to be a TLS alert. It's
not uncommon to have cert name checking (for instance) happen outside
of TLS (especially
if the stack doesn't know better), and this seems like functionality
that naturally
occurs outside of the TLS stack. I note that some TLS stacks don't appear to
allow the application to issue alerts (I just looked at OpenSSL and don't see
such a facilty). So, this seems like an unwise requirement.

3.  It's not obvious to me that "access_denied" is the right alert, at
least based
on this snipped. TLS provides the following alerts for cases where certs are
something other than acceptable:

  bad_certificate
     A certificate was corrupt, contained signatures that did not
     verify correctly, etc.

  unsupported_certificate
     A certificate was of an unsupported type.

  certificate_revoked
     A certificate was revoked by its signer.

 certificate_expired
     A certificate has expired or is not currently valid.

  certificate_unknown
     Some other (unspecified) issue arose in processing the
     certificate, rendering it unacceptable.

  illegal_parameter
     A field in the handshake was out of range or inconsistent with
     other fields.  This message is always fatal.

  unknown_ca
     A valid certificate chain or partial chain was received, but the
     certificate was not accepted because the CA certificate could not
     be located or couldn't be matched with a known, trusted CA.  This
     message is always fatal.

  access_denied
     A valid certificate was received, but when access control was
     applied, the sender decided not to proceed with negotiation.  This
     message is always fatal.

Consider the case where the EE cert doesn't chain anywhere (i.e., wouldn't
pass validation even without DANE). access_denied is clearly not the right
alert. Similarly, if the certificate association in DANE specifies a CA, and
the cert passes PKIX validation but not with a diferent CA, that looks a lot
more like "unknown_ca" or "certificate_unknown". If DANE is going to
specify a specific alert, I suspect it's going to have to be several alerts
and the WG will need to more clearly lay out which ones are needed when.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Oct 2011 04:15:25 +0200 (MEST)

> 3. Should that alert be access denied.

I was also confused by that "access_denied":

  http://www.ietf.org/mail-archive/web/dane/current/msg03372.html

and believe that DANE should rather define API-level behaviour here
(and access_denied does not make sense at the API in this situation),
whereas the fatal SSL alert the client should send before closing the
connection when the TLS decides to abort the connection, because of a
failed DANE validation, is a seperate issue.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Oct 2011 04:20:30 +0200 (MEST)

I sent this off to fast (somewhat dazed), it was unclear about
TLS client and application caller, fixed below.

 
 
and believe that DANE should rather define API-level behaviour here
(and access_denied does not make sense at the API in this situation),
whereas the fatal SSL alert the TLS client should send before closing the
connection when the application (DANE/TLS caller) decides to abort the
connection, because of a failed DANE validation, is a seperate issue.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Oct 2011 20:20:22 -0700

> connection, because of a failed DANE validation, is a seperate issue.

Your answer is still not clear to me. Are you saying for #2 "failure should be expressed as both an API-level behavior *and* send a TLS fatal alert", or "failure should be expressed as an API-level behavior and maybe also send a TLS fatal alert", or ...?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 11 Oct 2011 20:28:38 -0700

> 3. Should that alert be access denied.

#1 and #2 are linked in that, if we do not do a "mandatory fail as a fatal TLS alert", we would need to design a DANE API. We haven't done that yet, and maybe we need to, but currently we can get away with using the TLS signaling mechanism because we use fatal for #1 and TLS gives us a way to fail in a well-defined fashion. If we stay with the TLS alert, an application will still know why the error happened so it can log it or tell the user; there is just no standardized mechanism for that.

For #3, if we still go with a TLS fatal alert, we can specify "in case X, use alert Xa, but in case Y, use alert Ya", although the only value for that is to give the application some extra debugging information that it might log or tell the user. Note that neither the application nor the user can actually change anything by knowing the difference between X and Y, but people here might think it is valuable to know these things.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Oct 2011 05:43:47 +0200 (MEST)

Paul Hoffman wrote:
> #1 and #2 are linked in that, if we do not do a "mandatory fail as
> a fatal TLS alert", we would need to design a DANE API.

It is IMO quite inappropriate to talk about an SSL alert there.
We NEED to define API semantics instead!  Defining a real DANE API
is unnecessary.  TLS does the same in a few places (creating requirements
for the API between TLS and the calling application, without actually
defining an API).

>
> We haven't done that yet, and maybe we need to, but currently we can
> get away with using the TLS signaling mechanism because we use fatal
> for #1 and TLS gives us a way to fail in a well-defined fashion.

I'm sorry, I can't follow your line of thought here.

If you are think of "TLS signaling mechanism" in terms of SSL alerts
here, that is pretty useless.  That signaling mechanism is for
communication with the peer only.

But what we need here is a semantics how the DANE client reports a DANE
validation failure at the local API to the application caller, because
the application caller MUST decide (per TLS spec!) whether to abort the
connection or to ignore the DANE validation failure and continue.
There is *NO* mandatory to abort for PKIX failure (which often happen
due to the use of self-signed server certs or server certs issued by
organizational CAs.) and their neither ought to be any mandatory
to abort DANE validation failure either.  Having it fail by default
is sufficient.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Oct 2011 05:47:48 +0200 (MEST)

Paul Hoffman wrote:
> Your answer is still not clear to me. Are you saying for
> #2 "failure should be expressed as both an API-level behavior
> *and* send a TLS fatal alert", or "failure should be expressed
> as an API-level behavior and maybe also send a TLS fatal alert", or ...?

DANE must specify the semantics that needs to be exposed to the
calling app here.  mentioning which SSL alert should be send if the
calling app decides to abort the connection due to a DANE validation
failure would be OK.  For a TLS client that is validating a server
certificate, "bad_certificate" would be OK.  "access_denied" would
looks quite misplaced.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Oct 2011 21:37:18 -0700

On Tue, Oct 11, 2011 at 8:28 PM, Paul Hoffman <[email-masked]> wrote:
> #1 and #2 are linked in that, if we do not do a "mandatory fail as a fatal TLS alert", we would need to design a DANE API.

I'm not sure that this is true. For instance, you could say "MUST
terminate the connection." Why does that require
an alert. For that matter, why can't you just say "MUST be regarded as
suspect and SHOULD terminate the
connection.

-Ekr

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 11 Oct 2011 22:03:02 -0700

> suspect and SHOULD terminate the

In the current draft of my rewrite-for-clarity of DANE, I used very
similar wording.  I think it is entirely appropriate to stay away from
specifics of *how* the client terminates the connection and how the
failure is communicated from library to application software.

(I have "MUST terminate the connection", but let's not restart that
argument here.)

zw

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Oct 2011 08:10:55 -0700

> suspect and SHOULD terminate the

OK, I thought that #2 was a question about "DANE API" versus "do it in TLS". So that I'm not speaking for you, are you saying that #2 is about "TLS alert" versus "terminate connection"?

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Oct 2011 08:27:58 -0700

> OK, I thought that #2 was a question about "DANE API" versus "do it in TLS". So that I'm not speaking for you, are you saying that #2 is about "TLS alert" versus "terminate connection"?

I'm not sure I understand the question. The current text requires that
the connection be terminated
with a fatal TLS alert. I think it's an open question whether that
should be the requirement as opposed
to simply requiring that the application not proceed with the
connection and leave the manner
unspecified.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Wed, 12 Oct 2011 18:34:49 +0200 (MEST)

> (I have "MUST terminate the connection", but let's not restart that

Wedlocking the possibility to enable TLS on a server to the DNS admin
is just as alien and inappropriate as wedlocking it to customers of
commercial CAs.

The decision to abort a connection in case of a DANE validation of
the TLS server certificate needs to be an rfc2119-style "SHOULD"
directed at the user/consumer(!) of the technology "TLS", rather than
the implementor (of DANE application utility functions for a TLS software
distribution).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Oct 2011 12:40:27 -0400

+1 to EKR

This spec is unacceptable to me unless this is changed

Trying to redefine the semantics of TLS and PKIX is futile and childish. It
is not going to happen regardless of how many people say they agree in the
WG because the test is IETF consensus. And that is not going to be driven by
a narrow clique with zero implementation support.

DANE is becoming an obstacle to addressing the problems that it seeks to
address.

There are now other initiatives underway in other forums.

On Wed, Oct 12, 2011 at 11:27 AM, Eric Rescorla <[email-masked]> wrote:

> >>> #1 and #2 are linked in that, if we do not do a "mandatory fail as a
> fatal TLS alert", we would need to design a DANE API.
> >>
> > OK, I thought that #2 was a question about "DANE API" versus "do it in
> TLS". So that I'm not speaking for you, are you saying that #2 is about "TLS
> alert" versus "terminate connection"?
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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