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

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Apr 2017 13:47:08 -0700

Thanks for your comments.

> 1.2. Major Differences from TLS 1.2
>  It is very hard to make use of this section as is. It is organized on
> per-draft, while it would be expected to have the changes of the
> document since TLS 1.2. It contains phrases like "Remove spurious
> requirement to implement "pre_shared_key"." At its current state it is
> not useful to someone familiar with TLS 1.2.

Yes, I agree. This is an action item for me.

> 2. Figure 1 ascii art is a bit awkward (IMHO). "Key Exch" looks like
> bad shortening. Symbols '^' and 'v' were confusing on the first read.
> A suggestion could be to avoid ^v, and define shortened terminology
> upfront and use it on the figures.
>
> One the content, Figure 1 contents are too many to swallow at an
> overview. A suggestion would be to split into two diagrams (preshared
> keys and not).

I agree that this is a bit hard to take in, but I'd like to have
a unified diagram. I'll see what I can do about the shortening.

> A more general note on the section/document, is that although the PKIX
> identity (certificate) is protected from passive adversaries, the PSK
> identity is not. This is a discrepancy in terms of protecting the
> user's identity between PSK and certificate authentication (that should
> warrant .

I agree. I will mention this.

> 4.1.1. HelloRetryRequest how many times can it be re-sent by the
> server? I assume only a single one, but it maybe good to make it
> explicit.

This is forbidden in S 4.1.4.
https://tlswg.github.io/tls13-spec/#hello-retry-request

   If a client receives a second HelloRetryRequest in the same
   connection (i.e., where the ClientHello was itself in response to a
   HelloRetryRequest), it MUST abort the handshake with an
   “unexpected_message” alert.

Does this seem sufficient?

> 4.1.2. It is not defined what a server should do if encountered with a
> ProtocolVersion of TLS 1.3.

https://tlswg.github.io/tls13-spec/#supported-versions says:

   If this extension is not present, servers which are compliant with
   this specification MUST negotiate TLS 1.2 or prior as specified in
   [RFC5246], even if ClientHello.legacy_version is 0x0304 or
   later. Servers MAY abort the handshake upon receiving a ClientHello
   with legacy_version 0x0304 or later.

> 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
> status request. Why not require RFC6961?

Because TLS 1.3 allows you to attach OSCP-stapled responses to each
certificate with status_request, we felt that 6961 was superseded.

> 4.2. the exception for including cookie in HelloRetryRequest seems like
> something that could cause issues in future revisions. Any future
> revision of the protocol would not be able to add such exceptions
> (since they will be rejected by existing clients), and the fact that
> the cookie is there, it indicates that such an exception may be useful.
> A suggestion to address that would be to allow the HelloRetryRequest
> contain any extension or grant an exception to a specific extension
> number range.

Yes, this is an interesting suggestion. I have filed issue:

https://github.com/tlswg/tls13-spec/issues/939

However, as David Benjamin points out, it's not clear how one would
handle this in practice, because HRR is an instruction to the client
to do something, so if it can't parse that then the handshake fails.

> 4.2.5.2. The parameters are informally defined.
> I'd suggest to follow rfc4492bis and use its text as in:
>  https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#section-5.4.1

Good idea.
https://github.com/tlswg/tls13-spec/issues/943

> 4.2.7. There is no guidance on the use of max_early_data_size.
> I'd find it natural to have a recommended minimum value for application
> protocols layered on TLS to take into account. E.g., text like servers
> supporting early_data SHOULD allow at least 1024 bytes of data
> (arbitrary number). Is the 32-bit upper limit intentional?

I think it's just a result of the way the PDU is formatted. I
would be interested in seeing a PR with guidance...

> 4.2.8. This section changes the semantics for pre-shared keys as used
> in any other protocol (including TLS 1.2). With the new text it
> implies, pre-shared keys must be combined with a hash algorithm. Thus
> existing PSK deployments which share keys and would like to upgrade to
> TLS 1.3 cannot do transparently. They would have to fix to a specific
> hash algorithm for their existing PSKs, and make sure they provide that
> information to all the underlying software (which may be different on
> the server and client side). I could find no implementation guideline
> on what to do in the case of pre-existing PSKs in that text.
>
> My recommendation would be to switch the sentence "For externally
> established PSKs, the Hash algorithm MUST be set when the PSK is
> established" to "For externally established PSKs, the Hash algorithm
> MUST be set when the PSK is established, or default to SHA-256". That
> way implementations can cope transparently with an upgrade to TLS 1.3
> for already present PSK keys without requiring an additional RFC
> describing that.

This seems like a good change. I have made it.

> 4.2.8. The overlap of the namespace for usernames to be used in PSK
> authentication, and the namespace for "resumption" does not give a good
> feeling.

Yeah, I can see that perspective. That's part of why we domain
separate in the implementation.

> 4.2.8. Related to the above, it is unclear what obfuscated_ticket_age
> should contain when using PSK authentication (but not resumption).

https://tlswg.github.io/tls13-spec/#pre-shared-key-extension:

    For identities established externally an obfuscated_ticket_age of
    0 SHOULD be used, and servers MUST ignore the value.

> 4.2.8.1. It is not defined what the binder should contain when using
> PSK authentication (but not resumption).

It's intended to be the same (modulo the domain separation in the label).

> 4.2.8.1. If a single binder corresponds to a single identity, the
> parsing and mapping of binders in the PreSharedKeyExtension seems
> unnecessarily complicated. A suggestion is to move the binder inside
> each identity structure:
> struct {
>           opaque identity<1..2^16-1>;
>           uint32 obfuscated_ticket_age;
>           opaque PskBinderEntry<32..255>;
> } PskIdentity;

I did consider that, but it's not possible because you want the
binders to cover the other key identities so that it's not possible
to remove one without detection (unless you reject PSK entirely,
in which case this is detected in the Finished).

> 4.2.8.3. I believe that section can benefit from some improvements.
> >From a first read it is not clear what this section wants to protect
> from. It provides some checks, but it is unclear to me what these
> protect from.
>
> Some more concrete comments on the same section:
> It mentions "see if the value used by the client matches its
> expectations". A question that arises, is what is the recommended
> expectation for a server? Given the text in 4.2.8 that should be a
> week, but the text in 4.2.8 seems to imply that the restriction is
> defined somewhere else, and I would have expected it to be here.
>
> The text recommends: "a server SHOULD measure the round trip time prior
> to sending the NewSessionTicket message". I see two issues here. (1) it
> doesn't mention how to do this measurement --my guess is that this can
> be done in the context of TLS--, and (2) it assumes that round-trips
> are fixed over time. About (1), I ask because the obvious measurement
> time between [server Application Data*] and client [Certificate*] would
> include the processing of the application data by the client.
> On (2), this check will not work as is for mobile clients which will
> have variable round-trips.
>
> The check 'ticket age must be shorter than elapsed time by a round-
> trip', is unclear to me what it intends to protect from.
>
> A clarification: "the actual time elapsed on the server", elapsed since
> when? (I guess since the first message was received).

Thanks. I will try to clean this up. I have filed

> 4.3.2.1. The OID Filters extension on a first look seems quite
> independent and unrelated to everything else in this document (seemed
> quite a distraction that could have been in an appendix as well).

This is a fair point, but it's been in the document a long time,
so I think this would require WG Consensus.

> 4.4.2.1.  OCSP Status and SCT Extensions
> This is a very nice addition to TLS 1.3. Something that I miss as an
> implementer is guidelines on how to determine the (time) validity of an
> OCSP stapled response. Here my point is that OCSP responses have
> several fields optional (e.g., nextUpdate), which make a validation to
> be hand-wavy. It would be nice to have a profile of OCSP responses that
> would be recommended for use in TLS, as well or a recommendation of
> what constitutes a "fresh" response for use in TLS.

Do you have any thoughts on what text we should insert here? I admit
to being not that familiar with the practical matters of OCSP stapling.

> 4.4.2.2., 4.4.2.3.
> I think the reference to RFC5081 should be replaced with RFC5270 which
> obsoletes the former even though not explicitly.

Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion
in Chicago.

> 4.4.3. "RSA signatures MUST use an RSASSA-PSS algorithm". What should a
> client or server do when encounters an non RSA-PSS signature in TLS

> 4.6.3. My comment on this section, is that leaving up to the
> implementer to decide the re-key, would most probably result in the
> implementer delegating that decision to the application. In my
> experience that would mean no re-key in practice for the majority of
> applications. I'd have preferred a one-size fits all approach, where
> re-key is done on decided points.

I can understand that, but we did litigate this extensively, so I think
any change would require WG consensus at this point.

> 5.1. I miss a maximum number of alerts received per session, or some
> other alert limiting mechanism (having CVE-2016-8610 in mind).

All alerts now result in connection termination, so the limit
seems to implicitly be 1.

> 7.5. There is no definition of early_exporter_secret, and it is unclear
> why it is even mentioned. In short how is this supposed to be used, and
> why should implementations consider adding an interface to it?

It is defined in:
https://tlswg.github.io/tls13-spec/#key-schedule

I added some text to explain why you would want it.

> A. Is the described state machine intended to be normative or
> informative? I.e., which takes precedence, this description or the text
> above? (would be nice to clarify)

They are intended to be consistent. I wiould appreciate WG feedback
on this point.

> B.4.
> I believe it was discussed before, but I miss the AES-256-CCM
> ciphersuites. If only one must be defined, it may be better to only
> have the 256-bit variants (at least for the non-mac-truncated version)

Open to WG feedback here as well.

> E. I'd find it natural for this to be the security considerations
> rather than an appendix.
>
>
> G. Quite a long list. Would be nice to have the contributors to TLS 1.3
> separately.

I'd rather not try to draw this distinction in acknowledgements. My
feeling is that people have been doing good work on this back to
SSLv3. I will, however, try to typeset it into two columns.

> Bibliography: There are references to PKCS6 and PKCS7 that are never
> used throughout the text (I guess there are more).

Thanks. We will fix this pre-publication.

-Ekr

On Wed, Mar 29, 2017 at 7:32 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> On Wed, 2017-03-29 at 16:28 +0200, Nikos Mavrogiannopoulos wrote:
>
> > A more general note on the section/document, is that although the
> > PKIX
> > identity (certificate) is protected from passive adversaries, the PSK
> > identity is not. This is a discrepancy in terms of protecting the
> > user's identity between PSK and certificate authentication (that
> > should
> > warrant .
>
> ... an entry in the security considerations.
>
> > 4.2. rfc6961 is standard's track but TLS 1.3 only uses the RFC6066
> > status request. Why not require RFC6961?
>
> Please ignore that. I forgot to delete in my draft.
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 12 Apr 2017 00:25:38 +0300

>    with legacy_version 0x0304 or later.

I think that MAY abort should be removed. client_version field has
always been defined to be tolerant to higher values.
 
> to do something, so if it can't parse that then the handshake fails.

I think if one wanted to have new mandatory HRR extension, one could
just have it sent, resulting older clients blowing up. But those would
not be able to connect anyway.
 
> would be interested in seeing a PR with guidance...

The max_early_data_size looks kinda iffy. I understand the justification
is about buffering for verification, but that kind of buffering AFAICT
destroys the benefits of 0-RTT, so I would just skip 0-RTT if I knew
such buffering would take place.
 
> > have variable round-trips.

The thresholds seem so loose anyway, that I don't see much need to even
try to measure the RTT, one can seemingly just ignore them.

> so I think this would require WG Consensus.

Also, I have no idea of exact contents of that extension (maybe some mail
to this list has those, but that won't do with RFCs), as I can interpret
the thing in multiple ways. 
 
> to being not that familiar with the practical matters of OCSP stapling.

Well, my implementation considers OCSP responses valid to NextUpdate,
and fails handshake if it is absent but OCSP staple is sent.

> Indeed. Also, we are now explicitly prohibiting OpenPGP per discussion

Also, maybe needs some text about possible future Certificate Types
(or are those akin to DNS classes: heavy objects dropped by bad idea
fairy? :-) ). 

Also, client_certificate_type looks to be still CH,EE, which is not
good if any future certificate types might get defined (or even if
just RPK is allowed).
 
> > client or server do when encounters an non RSA-PSS signature in TLS

Well, my implementation just aborts. I have actually seen an TLS 1.3
draft implementation sign with RSA PKCS#1 (it did so if one sent a
ClientHello that only had that and ECDSA and EdDSAs).

> any change would require WG consensus at this point.

Might be a good idea to have suggestion to send one fairly early in the
connection.
 
> Open to WG feedback here as well.

Also, who uses those? It seems like CCM is mostly for things, and those
don't use AES-256, as AES-128 already seems quite much for various IoS.

Also, if one wanted special ciphersuite for things, I think there are
ones that are implementable in smaller space than AES CCM.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Apr 2017 14:53:06 -0700

> always been defined to be tolerant to higher values.

It seems like we are ossifyng that extension point. Otherwise it's very
hard to interpret. But I'm willing to defer if the WG objects.

> not be able to connect anyway.

That's what we have now :)

> the thing in multiple ways.

Hmm.. I did think the text was reasonably clear, but maybe I am in too deep.

> good if any future certificate types might get defined (or even if

Actually, I think this is still right. The reason is that this extension
applies
to the client's entire certificate message, not to each certificate, so it
needs to be negotiated up front.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 21 Apr 2017 16:52:31 +0200

> Does this seem sufficient?

I must have missed it. Yes, it seems fine.

> to being not that familiar with the practical matters of OCSP

My issue with OCSP when used under TLS was how to determine the
validity of the response when the nextUpdate field is missing. I've
added some text for that introducing an (arbitrary) upper limit at:
https://github.com/tlswg/tls13-spec/pull/974

> seems to implicitly be 1.

Nice.

> I added some text to explain why you would want it.

Thanks. There is a typo on that description "is define for use" -> "is
defined for use".

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 22 Apr 2017 07:53:50 -0400

> https://github.com/tlswg/tls13-spec/pull/974

This text looks good to me, but it is is a normative change and we've
been through WGLC so I'd like to hear from a few other people that they're
OK
with it (or have the chairs tell me that silence is consent). David
Benjamin?
Richard Barnes? Ryan Sleevi?

Thanks,
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 22 Apr 2017 15:00:17 +0300

> Richard Barnes? Ryan Sleevi?

I searched what minimum standards for "public" CAs say. The maximum
lifetime there is 10 days (but IIRC some widely-used root program has
lower limit, might have been 7 days)..

Anybody happens to know a CA that doesn't put NextUpdate in? If so,
what's the OCSP issuance frequency?

-Ilari

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 22 Apr 2017 23:42:06 +0200

> what's the OCSP issuance frequency?

The CA Browser baseline requirements have this in 4.9.7:
For the status of Subscriber Certificates: 
  If the CA publishes a CRL, then the CA SHALL update and reissue
  CRLs at least once every seven days, and the value of the
  nextUpdate field MUST NOT be more than ten days beyond the value
  of the thisUpdate field

For the status of Subordinate CA Certificates: 
  The CA SHALL update and reissue CRLs at least (i) once every
  twelve months and (ii) within 24 hours after revoking a
  Subordinate CA Certificate, and the value of the nextUpdate field
  MUST NOT be more than twelve months beyond the value of the
  thisUpdate field.

And in 4.9.10:
For the status of Subscriber Certificates:
  The CA SHALL update in formation provided via an Online
  Certificate Status Protocol at least every four days. OCSP
  responses from this service MUST have a maximum expiration
  time of ten days. 

For the status of Subordinate CA Certificates: 
  The CA SHALL update information provided via an Online
  Certificate Status Protocol at least (i) every twelve months and
  (ii) within 24 hours after revoking a Subordinate CA Certificate. 

So for OCSP of a subordinate CAs there doesn't seem to be any
requirement for a nextUpdate.

Kurt

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 22 Apr 2017 22:01:03 -0400

> requirement for a nextUpdate.

Correct. This is part of the many asynchronicities related to CRLs and OCSP
in the BRs (another example:
https://cabforum.org/pipermail/public/2017-April/010497.html ) for which
I'd love a consistent and normative profile, for which I have a bit of a
normative profile already.

My own $.02, however, is that I'm not keen to see such a profile of CA
behaviour in TLS. It will almost certainly be ignored and/or supplanted.
I'm not sure I understand under what adversarial or threat model this makes
sense for TLS, since an OCSP responder that doesn't provide a nextUpdate
can always have that message replayed to the client even if stapling was
omitted. Or is the suggestion that a server that staples an expired
response = fail the TLS connection, but a server that staples nothing, and
the OCSP responder supplies an expired response = everything OK? If so,
that asymmetry equally seems weird.

Much like the question about whether or not the certificate chain is a 'bag
of certs' or not, i'd rather not see this tackled in TLS, and see an
appropriate profile (either for OCSP and/or within the CA/Browser Forum),
that more consistently defines and addresses the threat model.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 23 Apr 2017 13:34:42 +0300

> <Snip BR rules>

I meant if anyone has seen a OCSP response from "public" CA lately that
lacks NextUpdate.

And the 12 month update interval for intermediates is IMO just crazy,
and won't work properly in TLS 1.3, now that multistaple is pretty much
a baseline feature.

Looking at those rules, 7 day default would still work fine with 4 day
issue frequency. And 7 days also seems to be the limit for various
kinds caching (e.g. tickets, subcerts, etc...) that circumvent
revocation in various drafts and specs.

As for what the TLS library I have written does if OCSP staple lacks
NextUpdate, it outright causes handshake failure and fatal alert.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 23 Apr 2017 12:01:08 -0400

> I meant if anyone has seen a OCSP response from "public" CA lately that

Why would it matter? Are you suggesting we determine what should be part of
TLS based on what CAs are doing? That's going to be sadness all around :)

> and won't work properly in TLS 1.3, now that multistaple is pretty much

I have no desire to support multistaple within Chrome. That it's specified
is great, but I believe multistaple is, for the general _browser_ case,
unnecessary. That's not to say it's not useful in other venues or in
specialized cases, which is the only reason I haven't complained here.

> revocation in various drafts and specs.

Again, that's public CAs. There are more participants in the ecosystem than
that. I don't think it's necessary or appropriate to set an upperbound
based on the Baseline Requirements. For that matter, I don't believe it's
necessary or appropriate to set an upperbound in TLS at all.

> NextUpdate, it outright causes handshake failure and fatal alert.

So far, the preference on our end has been for a TLS library that doesn't
have to have deeply-ingrained knowledge of the PKI, including OCSP, and
instead treat these as separate layers. This PR necessitates that awareness
by force of spec, and as such, makes it either unnecessarily difficult to
implement or simply unlikely to be implemented. Given that stapling
"issues" exist even without stapling, it does seem an unnecessary reach to
include within the spec.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 23 Apr 2017 19:39:27 +0300

> specialized cases, which is the only reason I haven't complained here.

Well, given the 12 month(!!!) uppoer limit on public CAs, supporting
intermediate stapling would be downright harmful.

And that kind of upper limit makes the non-stapled version just
useless.

I imagine browsers have their own CA revocation lists, and don't use
any form of CA-published CRLs nor OCSP. 

WebPKI does not take revocation seriously.

-Ilari

---

From: Kurt Roeckx <[email-masked]>
Date: Sun, 23 Apr 2017 20:18:51 +0200

> specialized cases, which is the only reason I haven't complained here.

I think your general browser case is that the browsers have worked
around it by having a different mechanism to revoke them. I
believe it would be better that browsers didn't have to do this,
so that it worked properly in all cases.

Kurt

---

From: Geoffrey Keating <[email-masked]>
Date: 23 Apr 2017 11:46:32 -0700

> > > https://github.com/tlswg/tls13-spec/pull/974
...
> what's the OCSP issuance frequency?

The definition is:

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.

I think 15 days is much too long.  I would suggest wording it more like:

If the nextUpdate value is omitted, the server SHOULD refresh the
response so that the thisUpdate field is no more than 24 hours in
the past.

and not place any requirement on the client; if the client wants
fresher information than the server provides, it can go fetch it
itself.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 24 Apr 2017 09:58:12 +0200

On Sun, 2017-04-23 at 12:01 -0400, Ryan Sleevi wrote:

> So far, the preference on our end has been for a TLS library that
> doesn't have to have deeply-ingrained knowledge of the PKI, including
> OCSP, and instead treat these as separate layers. This PR
> necessitates that awareness by force of spec, 

That's intentional. 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_. 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).

>  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. 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
 2. the response is valid for a limited amount of time 1, 7, 8, 9, 15
days
 3. the response is valid for an unlimited amount of time (which raises
 the question of why staple at all in that case?)

Without a clarification in the spec, we are going to see
implementations that fail when encountered with such response,
implementations that work fine, and implementations that claim the
response is too old. That would most likely result to ocsp stapling
becoming the thing to disable for things to work.

regards,
Nikos

---

From: Brian Smith <[email-masked]>
Date: Sun, 23 Apr 2017 22:17:58 -1000

Ryan Sleevi <[email-masked]> wrote:

> Correct. This is part of the many asynchronicities related to CRLs and
> OCSP in the BRs (another example: https://cabforum.org/
> pipermail/public/2017-April/010497.html ) for which I'd love a consistent
> and normative profile, for which I have a bit of a normative profile
> already.
>

The TLS 1.3 specification isn't the right place to specify what to do with
OCSP responses that do not have a nextUpdate field.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Apr 2017 13:21:52 +0000

> The TLS 1.3 specification isn't the right place to specify what to do with OCSP responses that do not have a nextUpdate field.

When phrased like this, it seems completely obvious to me that this correct.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 24 Apr 2017 09:26:27 -0400

On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> That's intentional.

And misguided. It violates the layering.

> Not every application is firefox or chrome and thus
> validity time _when the nextUpdate field is missing_.

Not every TLS implementation should be required to process the PKI.

> The reason they

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.

> There is a usability and interoperability issue there.

Not within the spec. Within the profile you've done for your community.

> Given that there

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

That's not an equally valid interpretation. A missing nextUpdate is defined
in the relevant OCSP specs.

>  the question of why staple at all in that case?)

A missing nextU... you get the idea.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 24 Apr 2017 09:27:53 -0700

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 <[email-masked]>
wrote:

> That's not an equally valid interpretation. A missing nextUpdate is
> defined in the relevant OCSP specs.
>
>
> That's not an equally valid interpretation. A missing nextUpdate is
> defined in the relevant OCSP specs.
>
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 25 Apr 2017 11:50:05 +0200

On Mon, 2017-04-24 at 09:26 -0400, Ryan Sleevi wrote:
> 
> 
> On Mon, Apr 24, 2017 at 3:58 AM, Nikos Mavrogiannopoulos <nmav@redhat
> .com> wrote:
> > That's intentional. 
> 

That's a respectable opinion. I disagree.

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

> Not within the spec. Within the profile you've done for your

So you point is that as long as you don't use OCSP responses there is
no interoperability issue. That's very interesting point. More
interestingly you delegate that definition to an application profile. 
Could you refer to such application profiles for TLS which define how
OCSP responses are to be used?

regards,
Nikos

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 25 Apr 2017 13:48:19 -0400

> OCSP responses are to be used?

I would argue that the Web PKI, as practiced by browsers, is one example
that is specific to the (publicly trusted CA) ecosystem. In this profile,
all major implementations but one (Firefox) allow for stapling an expired
response. With the exception of Firefox, when such an expired response is
received, they'll (if configured) go obtain a live response.

In this respect, PCT got it right - the certificate (and additional inputs,
such as OCSP stapling) are inputs to a blackbox which yields a binary
response. So, too, should it be for TLS - because in several major clients,
that's precisely what it's implemented/exposed as. That's not to say you,
for your use case, need to treat it as such. But it highlights the existing
disagreement for which using the spec to 'force' clients to a particular
viewpoint isn't productive, nor does it meaningfully improve security.