Subject: [dane] Opening issue #7: Error Handling : What to do when you receive an invalid record

From: Ondřej Surý <[email-masked]>
Date: Mon, 15 Aug 2011 16:47:49 +0200

Hi,

I would like to open next issue on the mailing list:

http://trac.tools.ietf.org/wg/dane/trac/ticket/7

--cut here--
From email from Jim Schaad:
Context -- Issue #7: Error Handling : What to do when you receive an invalid record -- Addressed in Protocol doc ((e.g Section 4.4))

This is not fully addressed in the spec at present. Specifically what to do
with unknown certificate types is not documented. Also I am not sure what
the correct behavior should be for mal-formatted items. I.e. if bytes are
missing or added to the current records. If you use an ASN.1 parser on the
certificate and compare it, rather than byte comparing it then trailing bad
bytes might be ignored.
--cut here--

I might open few more this week based on the traffic.

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 16 Aug 2011 00:17:07 +0300

> http://trac.tools.ietf.org/wg/dane/trac/ticket/7
 
Out of the 4 examples in the ticket itself, the first two just can't
happen (all combinations of reference type and certificatie type are
valid and meaningful).

The other two examples are still relevant. SHA-1 is in no more, but
the same can happen with, say SHA-256: 33 byte record (incomplete)
or 35 byte record (excess bytes).

And while what happens with unknown reference types is specified, what
happens with unknown certificate types isn't. I still think those should
be treated as usable-not-matching[1].

[1] Consider a _9418.tcp.foo.example only having one entry for type 4
certificate (unknown) referenced by type 1 (SHA-256, known).

You connect to server and request TLS...

Case I: You got the right server:

The likely answer to ClientHello is:

ALERT TLS 1.0 FATAL HANDSHAKE_FAILURE

... As the server lacks certificate recognizable to client.

Case II: You got some wrong server:

You might very well get X.509 certificate... Except that it is
unlikely that type 4 is anything related to X.509... Fall back
to legacy vailidation or reject the server?

-Ilari

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 15 Aug 2011 14:57:40 -0700

This is about the case where a TLSA record has a valid DNSSEC
signature but is incomprehensible to the client, yes?  I have not had
a chance to read the latest draft, but would suggest these semantics:

The client has received N (>=1) TLSA records in response to its query,
all of which have valid DNSSEC signatures.  Discard from this set all
records which are incomprehensible, ill-formed, or semantically
invalid.  If any TLSA records remain after this step, proceed to try
to match them against the TLS certificate chain.  But if *no* TLSA
records remain, fail hard.

Rationale: Server operators should be able to deploy new TLSA record
subtypes (most importantly, new hash algorithms) without breaking
legacy client access, by serving both the new records and
legacy-compatible records.  However, if a server operator deploys a
set of TLSA records *all* of which are broken in some way, they should
get a prompt failure.

Note also that if *any* record - TLSA or otherwise - is DNSSEC-bogus,
that should cause a hard failure without even considering the
comprehensibility of the record's contents.

zw

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Aug 2011 15:52:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ilari Liusvaara
> Sent: Monday, August 15, 2011 2:17 PM
> To: Ondrej Surý
> Cc: [email-masked]
> Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you
> receive an invalid record
> 
> On Mon, Aug 15, 2011 at 04:47:49PM +0200, Ondrej Sur  wrote:
> > Hi,
> >
> Out of the 4 examples in the ticket itself, the first two just can't happen (all
> combinations of reference type and certificatie type are valid and
> meaningful).
> 
> The other two examples are still relevant. SHA-1 is in no more, but the same
> can happen with, say SHA-256: 33 byte record (incomplete) or 35 byte record
> (excess bytes).
> 
> happens with unknown certificate types isn't. I still think those should be
> treated as usable-not-matching[1].

I agree that this would be one possible answer - the other answer is that it is not-usable

> ... As the server lacks certificate recognizable to client.

I would not agree with this statement.  While the certificate may not be recognizable, the new item may be a restriction on current X.509 certificates.  For example the new certificate type could be - you must have the following extension in it.  Or it could be the one which I keep wanting which is a non-trust anchor CA certificate.

> You might very well get X.509 certificate... Except that it is unlikely that type 4
> is anything related to X.509... Fall back to legacy vailidation or reject the
> server?
> 
> 
> 
> 
> -Ilari
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 15 Aug 2011 23:34:26 +0100

Conclude that you cannot make any valid inferences from DANE information and
proceed as if it was not there.

That is what is done in DKIM.

On Mon, Aug 15, 2011 at 3:47 PM, Ondřej Surý <[email-masked]> wrote:

> Context -- Issue #7: Error Handling : What to do when you receive an
> invalid record -- Addressed in Protocol doc ((e.g Section 4.4))
>

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Aug 2011 19:40:11 -0700

Make it unusable.

Current:
   If a certificate association contains a reference type that is not
   understood by the TLS client, that certificate association MUST be
   marked as unusable.
Proposed:
   If a certificate association contains a reference type or certificate type that is not
   understood by the TLS client, that certificate association MUST be
   marked as unusable. If an error occurs when comparing using
   reference types that are not exact matches (such as hashes), the
   certificate association MUST be marked as unusable.

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 15 Aug 2011 20:49:35 -0700

> Paul Hoffman
> Sent: Monday, August 15, 2011 7:40 PM
> To: Ondrej Surý
> Cc: [email-masked]
>    If a certificate association contains a reference type or certificate
type that
> is not

If an error occurs when comparing using reference types, the certificate
association MUST be marked as unusable.

-- I don't understand why there is a reason for the 'not exact matches', it
should not matter as long as the comparison is done in the correct manner if
you are comparing either the direct bytes or via a function such as a hash.

--  Note that the statement that it be marked as unusable does not match the
pseudo code in appendix B unless there is a check someplace in the code that
I missed for things which are marked unusable as oppose to a usable but
failed check.

Jim

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Aug 2011 08:10:58 -0700

> you are comparing either the direct bytes or via a function such as a hash.

Good point.
> I missed for things which are marked unusable as oppose to a usable but

The pseudocode in Appendix B is incomplete. We will add the following (or something like it) near the beginning:

// unusable records include unknown certType, unknown certAssoc
//   and erroneous RDATA
strip unusable records
if (no good TLSA record(s) received) {
  fall back to "normal" cert validation
}

Proposed:
  If a certificate association contains a reference type or certificate type that is not
  understood by the TLS client, that certificate association MUST be
  marked as unusable. If an error occurs when comparing, the
  certificate association MUST be marked as unusable.

Does that resolve your concern?

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 17 Aug 2011 14:06:39 -0700

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Wednesday, August 17, 2011 8:11 AM
> To: Jim Schaad
> Cc: DANE WG
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Paul Hoffman
> >> Subject: Re: [dane] Opening issue #7: Error Handling : What to do
> >> when you receive an invalid record
> >>
> >> Make it unusable.
> >>
> >> Current:
> > If an error occurs when comparing using reference types, the
> > -- I don't understand why there is a reason for the 'not exact
> > matches', it should not matter as long as the comparison is done in
> > the correct manner if you are comparing either the direct bytes or via a
> function such as a hash.
> 
> Good point.
> >
> > --  Note that the statement that it be marked as unusable does not
> > match the pseudo code in appendix B unless there is a check someplace
> > in the code that I missed for things which are marked unusable as
> > oppose to a usable but failed check.
> 
type that is
> not

It all looks good except for the last line in the proposed text.  An
comparison failure could be thought of as an error and in that case you do
not want to be marked as unusable.  I think what you meant was:

If the comparison data for a certificate is malformed, the certificate
association MUST be marked as unusable.

Jim

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Aug 2011 15:30:22 -0400

Hi there all,

We would like to call this on Friday at 16:00UTC, but would delay like some additional input.

Is the proposed text (below) acceptable to the WG?

W

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 30 Aug 2011 13:51:12 -0700

Which proposed text are we  looking at, the text from Paul or the text from
Paul with my modification?

Jim

> From: Warren Kumari [mailto:[email-masked]]
> Sent: Tuesday, August 30, 2011 12:30 PM
> To: Jim Schaad
> Cc: Warren Kumari; 'Paul Hoffman'; 'DANE WG'
> We would like to call this on Friday at 16:00UTC, but would delay like
some
> additional input.
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Paul Hoffman
> >>> match the pseudo code in appendix B unless there is a check
> >>> someplace in the code that I missed for things which are marked
> >>> unusable as oppose to a usable but failed check.
> >>
> >> The pseudocode in Appendix B is incomplete. We will add the following
> >> (or something like it) near the beginning:
> >>
> >> if (no good TLSA record(s) received) {  fall back to "normal" cert
> >> validation }
> >>
> >> Proposed:
> > comparison failure could be thought of as an error and in that case
> > you do not want to be marked as unusable.  I think what you meant was:
> >

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Aug 2011 16:25:14 -0400

> Paul with my modification?

Sorry, I really should have been more clear -- the text from Paul WITH your modification.

W

---

From: [email-masked]
Date: Wed, 31 Aug 2011 14:37:22 +0000

> >>> association MUST be marked as unusable.

	This text looks good to me.

/bill