Re: [TLS] comments on draft-ietf-tls-tls13-19

I'm reading there as being no consensus to make this change, so I plan not
to absent chair directive.

-Ekr

On Mon, Apr 24, 2017 at 6:26 AM, Ryan Sleevi <ryan-ietftls@sleevi.com>
wrote:

>
>
> On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
> wrote:
>
>>
>> That's intentional.
>
>
> And misguided. It violates the layering.
>
>
>> Not every application is firefox or chrome and thus
>> application writers cannot be expected to set sane defaults for OCSP
>> validity time _when the nextUpdate field is missing_.
>
>
> Not every TLS implementation should be required to process the PKI.
>
>
>> The reason they
>> cannot be expected to do that, is that it is not by way obvious what to
>> do. Ilari's implentation closes the connection, mine sets a limit of 15
>> days, and I guess each and every other one behaves differently. It is
>> the role of the standards to clarify uncertainties for implementers or
>> forbid such options (I'd equally be happy if we have a text that
>> forbids an empty nextUpdate field in OCSP responses to be used in the
>> context of TLS 1.3 ocsp stapling).
>>
>
> Can you point to where the spec supports your behaviours? That is, where
> it's a valid reading of the spec to close the connection or to set a limit
> of 15 days.
>
> The point is that it's not a valid reading of the spec. It is, instead, an
> application profile. And that's great. I don't think anyone would
> realistically be arguing that applications or other specifications cannot
> profile the spec to their needs. While I remain unconvinced that TLS is the
> right thing, what you're describing here is simply a decision you've made
> for your community. That doesn't mean that because you and Ilari have made
> different decisions, that should be imposed on the spec.
>
>
>> >  Given that stapling "issues" exist even without stapling, it does
>> > seem an unnecessary reach to include within the spec.
>>
>> There is a usability and interoperability issue there.
>
>
> Not within the spec. Within the profile you've done for your community.
>
>
>> Given that there
>> is no common interpretation of what the missing nextUpdate field means
>> in terms of validity, there some equally valid interpretations:
>>  1. the response is invalid for use in TLS 1.3
>>
>
> That's not an equally valid interpretation. A missing nextUpdate is
> defined in the relevant OCSP specs.
>
>
>>  2. the response is valid for a limited amount of time 1, 7, 8, 9, 15
>> days
>>
>
> That's not an equally valid interpretation. A missing nextUpdate is
> defined in the relevant OCSP specs.
>
>
>>  3. the response is valid for an unlimited amount of time (which raises
>>  the question of why staple at all in that case?)
>>
>
> A missing nextU... you get the idea.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>