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

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Sep 2011 14:37:51 -0400

On Aug 30, 2011, at 3:30 PM, Warren Kumari wrote:

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

And we are calling this this...

While we only got one explicit LGTM (Thanks Bill!) the text is the result of discussions on the list, and so we are calling consensus on the text from Paul, with Jim's modification.

Thanks,
W

> W
> 
> 
> On Aug 17, 2011, at 5:06 PM, Jim Schaad wrote:
> 
>> 
>> 
>>> -----Original Message-----
>>> From: Paul Hoffman [mailto:[email-masked]]
>>> Sent: Wednesday, August 17, 2011 8:11 AM
>>> To: Jim Schaad
>>> Cc: DANE WG
>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do when you
>>> receive an invalid record
>>> 
>>> 
>>> On Aug 15, 2011, at 8:49 PM, Jim Schaad wrote:
>>> 
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>> Of Paul Hoffman
>>>>> Sent: Monday, August 15, 2011 7:40 PM
>>>>> To: Ondrej Surý
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [dane] Opening issue #7: Error Handling : What to do
>>>>> when you receive an invalid record
>>>>> 
>>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>> 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?
>> 
>> 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
>> 
>>> 
>>> --Paul Hoffman
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>> 
>