Subject: Re: [TLS] draft-ietf-tls-cached-info-14

From: Rob Stradling <[email-masked]>
Date: Mon, 08 Apr 2013 14:08:36 +0100

On 29/03/13 18:34, Hannes Tschofenig wrote:
> Hi Rob,
>
> I worked on a document update and the current snapshot can be found here:
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt
>
> Let me know if that fits your needs.

Hi Hannes.  You propose treating the entire CertificateStatus message as 
a single CachedObject, but I'd like to propose a finer-grained approach: 
treat each OCSP Response as a separate CachedObject.  Here's why...
   - A number of browsers/OSes already implement OCSP Response caches, 
and I think it'd make sense for these caches to be reusable in the 
context of Cached-Info.
   - It's common for OCSP Responses for Intermediate certificates to be 
valid for much longer than OCSP Responses for End-entity certificates. 
Also, it's common for clients to encounter multiple End-entity 
certificates issued by the same Intermediate certificate.  For these 
reasons, it will often be the case that a client has already cached the 
OCSP Response for the Intermediate(s) and will therefore only need the 
server to send the OCSP Response for the End-entity certificate.

Your draft already permits clients to send multiple CachedObject 
attributes of the same CachedInformationType, so I don't see any issues 
with the client->server part of my approach.

For the server->client part, the Multi-Stapling draft [1] already allows 
some of the OCSP Responses to be omitted...
   "Individual elements of the list MAY have a length of 0 (zero) bytes"
...although the rest of that sentence is problematic w.r.t. my approach:
   ", if the server does not have the OCSP response for that particular
    certificate stored, in which case, the client MUST act as if a
    response was not received for that particular certificate."

Also, the following paragraph in the Cached-Info draft is problematic 
w.r.t. my approach:
   "The server MUST NOT include more than one fingerprint for a single
    information element, i.e., at maximum only one CachedObject structure
    per replaced information is provided."

I realize that time is running out to get changes made to the 
Multi-Stapling draft before publication as an RFC, and I realize that my 
approach would make the Cached-Info draft more complicated.  However, I 
think it'd be worth the effort.

What does anybody else think?

[1] 
http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/

> Ciao
> Hannes
>
> On Mar 28, 2013, at 11:23 PM, Rob Stradling wrote:
>
>> On 28/03/13 18:41, Hannes Tschofenig wrote:
>>> Hi Sean,
>>>
>>> It addresses all open issues we had at the IETF meeting.
>>>
>>> It does not yet contain the text for adding the OCSP response caching, as suggested by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html).
>>> I could propose some text by tomorrow since I believe it is useful functionality.
>>
>> Hannes,
>>
>> For Multi-Stapling, there will be cases where a TLS client has previously seen the OCSP Response(s) for the Intermediate(s) but not yet seen the OCSP Response for the End-entity cert.
>>
>> It would be useful in such cases if Cached-Info would enable the TLS server to only have to send the OCSP Response(s) that the TLS client hasn't previously cached.
>>
>>> Ciao
>>> Hannes
>>>
>>> On Mar 28, 2013, at 7:21 PM, Sean Turner wrote:
>>>
>>>> Does this version address all known outstanding issues?
>>>>
>>>> spt
>>>>
>>>> On 3/28/13 3:29 AM, Hannes Tschofenig wrote:
>>>>> Hi all,
>>>>>
>>>>> I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting.
>>>>>
>>>>> The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html).
>>>>>
>>>>> Ciao
>>>>> Hannes

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 08 Apr 2013 15:58:08 +0200

> server to send the OCSP Response for the End-entity certificate.

I am opposed to mixing in content sent by other servers, because it could  
be a privacy violation since it would leak information about which CAs are  
used by the sites the user have visited. The information might change  
relatively often, but it could still leak information to the other sites.

Also, the number of entries in the list sent in the Client Hello could  
quickly become relatively large, since a client could easily encounter  
dozens of intermediate CAs in a session.

The only way something like this would work without becoming a security  
problem is that the client would first know that the server is using the  
same intermediate CA as one or more other servers it have visited, which  
means that the server must send the entire response anyway, so there is no  
saving of bytes on the wire.

Optimizing storage on the client is a separate matter, best left to the  
implementers.

IMO the Cached Info extension can *only* concern itself with information  
received from the current server, *never* what has been received by  
another server. It might be that this should be spelled out in the spec,  
perhaps in the security considerations, at least.

In a worst case scenario such a multi-server caching concept could lead to  
a "TLS Cached Info" super cookie that can be used to track a user across  
multiple unrelated websites, which is conceivable in the case of  
multi-stapling (and server certificates, too). How: In addition to the  
chained website certificates add a separate certificate among the  
certificates sent to the client, which is configured for OCSP. Since the  
multi-stapling system is linked to the sequence of certificates in the  
Server Certificate message, not the actual certificate chain being  
validated, the extra OCSP response could be used to uniquely identify the  
user, at least for the current session. Doing so might be computationally  
expensive, if the extra entry is signed, but since it is for a certificate  
that is not validated .... why should it be signed?

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Rob Stradling <[email-masked]>
Date: Mon, 08 Apr 2013 20:52:45 +0100

On 08/04/13 14:58, Yngve N. Pettersen wrote:
<snip>
> I am opposed to mixing in content sent by other servers,  because it
> could be a privacy violation since it would leak information about which
> CAs are used by the sites the user have visited. The information might
> change relatively often, but it could still leak information to the
> other sites.

Hi Yngve.  I need to clarify what I was proposing...

> dozens of intermediate CAs in a session.

I didn't mean that the client would send CachedObjects for every 
Intermediate certificate that it has previously encountered.  Rather, I 
meant that the client would only send CachedObjects for Intermediate 
certificates that it has good reason to believe are "relevant" for this 
connection.

> means that the server must send the entire response anyway, so there is
> no saving of bytes on the wire.

Agreed, but only for the client's first ever visit to a site.  My 
proposal attempts to save bytes on the wire for subsequent full 
handshakes to the same site (for as long as the same End-entity 
certificate is used).

> perhaps in the security considerations, at least.

When the client sends the ClientHello for a full handshake, it has not 
yet authenticated that "the current server" is indeed the same server 
from which it previously retrieved certain information.  All the client 
has done so far is a (potentially insecure) DNS lookup.

And anyway, I was only envisaging that clients would send CachedObjects 
of OCSP Responses that have "been received by another server" in cases 
where it would be safe to do so.
Example:
   - Client visits https://www.google.com and https://mail.google.com, 
each for the first time ever, and caches the certificate chains and OCSP 
Responses for the End-entity and Intermediate certs.  Client observes 
that the same "Google Internet Authority" Intermediate is used in both 
cases.
   - A while later, client performs another full handshake to 
https://www.google.com and gets back a different OCSP Response (with a 
more recent thisUpdate value) for the same Intermediate cert.
   - A while later, client performs another full handshake to 
https://mail.google.com.  It sends the CachedObject for the Intermediate 
OCSP Response that https://www.google.com just returned, because it 
knows that this OCSP Response is relevant for the Intermediate cert that 
https://mail.google.com used last time the client connected to it, and 
because this OCSP Response is the freshest one that the client has 
available.

<snip>

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Mon, 08 Apr 2013 22:07:02 +0200

I was primarily reacting to this in your post:

>> certificatesissued by the same Intermediate certificate.  For these  
>> reasons, it will
>> often be the case that a client has already cached the OCSP Response for
>> the Intermediate(s) and will therefore only need the server to send the 
>> OCSP Response for the End-entity certificate.

> where it would be safe to do so.

s/safe/"safe"/

> because this OCSP Response is the freshest one that the client has  

What about www.co.uk and bank.co.uk?

Such things get complicated very fast, which is why we had to develop the  
public suffix list.

Please, let us stay way, way, *way* out of that particular thorny area.

-- 
Sincerely,
Yngve N. Pettersen

---

From: Rob Stradling <[email-masked]>
Date: Tue, 09 Apr 2013 20:07:53 +0100

On 08/04/13 21:07, Yngve N. Pettersen wrote:
<snip>
>> each for the first time ever, and caches the certificate chains and
>> OCSP Responses for the End-entity and Intermediate certs.  Client
>> observes that the same "Google Internet Authority" Intermediate is
>> used in both cases.
>> https://mail.google.com.  It sends the CachedObject for the
>> Intermediate OCSP Response that https://www.google.com just returned,
>> because it knows that this OCSP Response is relevant for the
>> Intermediate cert that https://mail.google.com used last time the
>> client connected to it, and because this OCSP Response is the freshest
>> one that the client has available.
>
> Such things get complicated very fast, which is why we had to develop
> the public suffix list.
>

If the End-entity certs at https://www.co.uk and https://bank.co.uk are 
both issued by the same Intermediate, then what's the problem?
Why are the domain names even relevant when deciding whether or not it's 
"safe" for the client to send an Intermediate cert's OCSP Response that 
a different server provided?

I agree that my proposal should be rejected _if_ the consensus is that 
it adds too much extra complexity.  But IMHO the more bytes on the wire 
we can save, the more chance there is that Multi-Stapling + Cached-Info 
will actually get deployed widely.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 09 Apr 2013 22:59:52 +0200

> a different server provided?

Tip: If domain names are irrelevant, make sure they do not carry meaning  
in the discussion, particularly when combined with the word "safe". Might  
confuse things.

> will actually get deployed widely.

The concept still assumes that server1 and server2 will have same binary  
response R for certificate X at time T, even if the client have previously  
only seen R from server1, and instead seen response S from server2.

If, at time T both R and S are valid, but R is valid longer than S, which  
should be indicated to server2? If both, that means more (unnecessary)  
bytes on the wire, particularly if you have more than 2 servers (e.g. 200)  
with the same (issuer) certificate, each with binary different valid  
responses.

What if the client indicates R to server2 and leaves out S, but server2  
does not have R (and might get response Q if it requested an update)? Most  
likely server2 would then resend response S. Result: unnecessary bytes on  
the wire.

Personally, I think it is better to assume that the OCSP responses kept by  
two servers are different, even if they are signed by the same issuer. It  
might be that servers in different geographical areas connect to different  
OCSP responders which have responses generated at different times (or who  
generate on-the-fly responses).

As mentioned above, the potential problems becomes even more pronounced if  
you are dealing with hundreds or thousands of servers (as we would likely  
do with servers using Comodo issued certificates, for example).

My advice: Keep cache lists for each server separate from the lists used  
for other servers. That does not mean that the client cannot optimize  
storage by combining the storage for each entry in the list, though. There  
is too much chance of guessing wrong about what the server should know  
based on what the client knows.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 9 Apr 2013 15:52:44 -0700

I'm having a basic problem understanding OCSPResponse cachedinfo object and
the need to obtain the latest cert_status from the server.

Why does a TLS client care if it has the same OCSP responses (for server and
any intermediate certificate) as the TLS server, as long as it has some
valid OCSP responses for those certificates? IMO, all the client cares about
is the fact that it can build a valid status checked path to the locally
configured trust anchor.

So the only thing that the client needs to tell the server is the list of
certificates for which it needs the status (either because the status in the
cache expired or because it never got the status from this or other server).
This can be communicated easily through a list of Boolean values. The
position of the value corresponds to the position of certificate in the
certificate chain and the value indicates if the client wants the server to
include the status of corresponding cert.
This makes the cached info object for OCSP responses much smaller compared
to the representation that uses hash and also allows the clients to make use
of locally cached OCSP responses irrespective of where they came from.

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yngve N. Pettersen
> Sent: Tuesday, April 09, 2013 2:00 PM
> To: Rob Stradling
> Cc: [email-masked]
> Subject: Re: [TLS] draft-ietf-tls-cached-info-14
> 
> >>>    - Client visits https://www.google.com and
> >>> https://mail.google.com, each for the first time ever, and caches
> >>> the certificate chains and OCSP Responses for the End-entity and
> >>> Intermediate certs.  Client observes that the same "Google Internet
> >>> Authority" Intermediate is used in both cases.
> >>> https://www.google.com and gets back a different OCSP Response
> (with
> >>> a more recent thisUpdate value) for the same Intermediate cert.
> >>> Intermediate OCSP Response that https://www.google.com just
> >>> returned, because it knows that this OCSP Response is relevant for
> >>> the Intermediate cert that https://mail.google.com used last time
> >>> the client connected to it, and because this OCSP Response is the
> >>> freshest one that the client has available.
> >>
> > If the End-entity certs at https://www.co.uk and https://bank.co.uk
> > are both issued by the same Intermediate, then what's the problem?
> > Why are the domain names even relevant when deciding whether or not
> > it's "safe" for the client to send an Intermediate cert's OCSP
> > Response that a different server provided?
> 
in
> the discussion, particularly when combined with the word "safe". Might
> confuse things.
> 
> > it adds too much extra complexity.  But IMHO the more bytes on the
> > wire we can save, the more chance there is that Multi-Stapling +
> > Cached-Info will actually get deployed widely.
> 
only
> seen R from server1, and instead seen response S from server2.
> 
should
> be indicated to server2? If both, that means more (unnecessary) bytes on
> the wire, particularly if you have more than 2 servers (e.g. 200) with the
same
> (issuer) certificate, each with binary different valid responses.
> 
does
> not have R (and might get response Q if it requested an update)? Most
likely
> server2 would then resend response S. Result: unnecessary bytes on the
> wire.
> 
two
> servers are different, even if they are signed by the same issuer. It
might be
> that servers in different geographical areas connect to different OCSP
> responders which have responses generated at different times (or who
> As mentioned above, the potential problems becomes even more
> pronounced if you are dealing with hundreds or thousands of servers (as we
> would likely do with servers using Comodo issued certificates, for
example).
> My advice: Keep cache lists for each server separate from the lists used
for
> other servers. That does not mean that the client cannot optimize storage
by
> combining the storage for each entry in the list, though. There is too
much
> chance of guessing wrong about what the server should know based on what
> the client knows.
> 
> --
> Sincerely,
> Yngve N. Pettersen
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Apr 2013 13:21:13 +0100

On 09/04/13 21:59, Yngve N. Pettersen wrote:
<snip>
> in the discussion, particularly when combined with the word "safe".
> Might confuse things.

Noted.  Thanks.

> response R for certificate X at time T, even if the client have
> previously only seen R from server1, and instead seen response S from
> server2.

Correct.

> If, at time T both R and S are valid, but R is valid longer than S,
> which should be indicated to server2? If both, that means more
> (unnecessary) bytes on the wire, particularly if you have more than 2
> servers (e.g. 200) with the same (issuer) certificate, each with binary
> different valid responses.
>
> does not have R (and might get response Q if it requested an update)?
> Most likely server2 would then resend response S. Result: unnecessary
> bytes on the wire.

I agree that it's possible that R, S, Q and another 200+ variants of an 
Intermediate OCSP Response might all exist, but how likely is this?

These days, CAs are expected to keep Root private keys off-line.  So in 
the typical case of a cert chain involving just 1 Intermediate, it's 
likely that the Intermediate OCSP Responses will have been pregenerated. 
  Therefore, it's likely that each server will pick up exactly the same 
OCSP Response to staple.

But let's stop discussing this point.  I just read Piyush's post and I 
think he's proposed a far better idea.  :-)

<snip>

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Apr 2013 14:41:20 +0100

> of locally cached OCSP responses irrespective of where they came from.

Thanks Piyush.  I think that a "list of Boolean values" for requesting 
cert statuses is a much better idea.  :-)

When you say "The position of the value corresponds to the position of 
certificate in the certificate chain", I presume you're referring to the 
CachedObject(s) of type "certificate_chain" that the client sends.

If a client were to send >1 CachedObjects of type "certificate_chain" 
and >1 "list of Boolean values" CachedObjects, there could be ambiguity 
over which "certificate_chain" is paired with which "list of Boolean 
values".

Would we simply say that the CachedObject(s) of these two types must be 
sent in the same order?
Or would we need to squeeze the "list of Boolean values" into the 
"certificate_chain" CachedObject type somehow?

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 10 Apr 2013 15:53:46 +0200

Hi,

Please keep in mind that the certificate chain sequence can be changed at  
any time. Any mechanism used would need to take that into consideration.

Therefore, such a solution would have to link it to the fingerprint of the  
chain of stapled responses. However, once you provide that information you  
don't need a boolean value to indicate which responses you have and that  
are valid, because the server will already have that information.

It might be conceivable to link the information to the fingerprint of the  
certificate chain and then use the bools, but that would actually require  
(a few) more bytes on the wire than indicating the fingerprint of the  
stapled response list (although: one could get past that by linking the  
stapled list with the entry for cached certificates, but I think that  
would complicate matters more than is necessary to save a few bytes;  
particularly if the client for some reason is not caching the certificate  
chain).

On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling  
<[email-masked]> wrote:

>>> previously
>>> which

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 10 Apr 2013 07:02:10 -0700

> CachedObject(s) of type "certificate_chain" that the client sends.
[Piyush] Correct.

> and >1 "list of Boolean values" CachedObjects, there could be ambiguity
over
> which "certificate_chain" is paired with which "list of Boolean values".
> 

[Piyush] 
Either approach would work (it is just different representation of same
information). However, keeping them separate would be better just because
implementations may want to support caching of certificate_chain and may not
want to support caching of OCSP responses. 
Given that certificate_chain cached object represents a list of certificates
with strict rules on ordering,  ocsp cached object would be a list with same
number of entries and same ordering as those of certificate chain.

---

From: [email-masked] (Martin Rex)
Date: Wed, 10 Apr 2013 16:08:01 +0200 (CEST)

> based on what the client knows.

I agree with Yngve that it would be a terribly bad idea for TLS clients
to announcing hashes of cached OCSP responses from other sources than
a prior TLS handshake with the _exact_same_server_ .

The concept of the caching mechanism is to cache data from a previous
TLS handshake.  Mixing in data from other sources is going to cause
hardly predictable behaviour *AND* is going to leak information that
ought not to be leaked (and may occasionally create a security problem
"side channel").

The only thing that might be acceptable, is a means for the client to
indicate "don't send me that information at all".  The client could
always omit the OCSP response extension (single and multi) from the
TLS ClientHello, if it so desires (e.g. in a renegotiation handshake,
if the client would also abort on a change of the server certificate).

But even then, when the "I already have this information" is the result
of TLS handshakes with another server, the result would be a side channel
leaking information -- so TLS clients need to be careful here!

-Martin

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Apr 2013 15:10:12 +0100

> want to support caching of OCSP responses.

Agreed.

Also, we'd have to state that the number of "list of Boolean values" 
CachedObjects sent by the client MUST be either i) zero or ii) exactly 
the same as the number of "certificate_chain" CachedObject(s).

> number of entries and same ordering as those of certificate chain.

Agreed.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 10 Apr 2013 15:21:47 +0100

On 10/04/13 14:53, Yngve N. Pettersen wrote:
> Hi,
>
> Please keep in mind that the certificate chain sequence can be changed
> at any time. Any mechanism used would need to take that into consideration.

It can be changed at any time on the server side, but we're talking 
about the certificate chain sequence that the client received and cached 
at a particular point in time.

> Therefore, such a solution would have to link it to the fingerprint of
> the chain of stapled responses. However, once you provide that
> information you don't need a boolean value to indicate which responses
> you have and that are valid, because the server will already have that
> information.

Isn't this exactly what Hannes proposed a couple of weeks ago?

> It might be conceivable to link the information to the fingerprint of
> the certificate chain and then use the bools, but that would actually
> require (a few) more bytes on the wire than indicating the fingerprint
> of the stapled response list (although: one could get past that by
> linking the stapled list with the entry for cached certificates, but I
> think that would complicate matters more than is necessary to save a few
> bytes; particularly if the client for some reason is not caching the
> certificate chain).
>
>> certificate in the certificate chain", I presume you're referring to
>> the CachedObject(s) of type "certificate_chain" that the client sends.
>>
>> and >1 "list of Boolean values" CachedObjects, there could be
>> ambiguity over which "certificate_chain" is paired with which "list of
>> Boolean values".
>>
>> Would we simply say that the CachedObject(s) of these two types must
>> be sent in the same order?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 10 Apr 2013 07:45:34 -0700

> any time. Any mechanism used would need to take that into consideration.
[Piyush] Not sure if I understood it correctly. TLS has strict guidelines on
sequence of certificates in the chain. The certificate chain sequence would
change only when the server certificate changes (or in some rare cases when
intermediate CA's certificate rolls over). Right? If that happens than
certificate_list cached object held by the client would become invalid and
consequently any stapled responses associated with the old certificate chain
would also become invalid.

Let's make sure that we are on the same page regarding this before I respond
to your other points below, otherwise we'll get past each other because we
would be working off different set of assumptions.

> Therefore, such a solution would have to link it to the fingerprint of the
chain
> of stapled responses. However, once you provide that information you don't
> need a boolean value to indicate which responses you have and that are
> valid, because the server will already have that information.
(a
> few) more bytes on the wire than indicating the fingerprint of the stapled
> response list (although: one could get past that by linking the stapled
list with
> the entry for cached certificates, but I think that would complicate
matters
> more than is necessary to save a few bytes; particularly if the client for
some
> reason is not caching the certificate chain).
> >> I'm having a basic problem understanding OCSPResponse cachedinfo
> >> object and the need to obtain the latest cert_status from the server.
> >>
> >> Why does a TLS client care if it has the same OCSP responses (for
> >> server and any intermediate certificate) as the TLS server, as long
> >> as it has some valid OCSP responses for those certificates? IMO, all
> >> the client cares about is the fact that it can build a valid status
> >> checked path to the locally configured trust anchor.
> >>
> >> So the only thing that the client needs to tell the server is the
> >> list of certificates for which it needs the status (either because
> >> the status in the cache expired or because it never got the status
> >> from this or other server).
> >> position of the value corresponds to the position of certificate in
> >> the certificate chain and the value indicates if the client wants the
> >> server to include the status of corresponding cert.
> >> This makes the cached info object for OCSP responses much smaller
> >> compared to the representation that uses hash and also allows the
> >> clients to make use of locally cached OCSP responses irrespective of
> >> where they came from.
> >
> > the
> >>> From: [email-masked] [mailto:[email-masked]] On Behalf
> >>> Of Yngve N. Pettersen
> >>>>>> Intermediate certs.  Client observes that the same "Google
> >>>>>> Internet Authority" Intermediate is used in both cases.
> >>>>>> returned, because it knows that this OCSP Response is relevant
> >>>>>> for the Intermediate cert that https://mail.google.com used last
> >>>>>> time the client connected to it, and because this OCSP Response
> >>>>>> is the freshest one that the client has available.
> >>>>>
> >>>>> Such things get complicated very fast, which is why we had to
> >>>>> develop the public suffix list.
> >>>>>
> >>> the discussion, particularly when combined with the word "safe".
> >>> Might confuse things.
> >>>
> >>>> I agree that my proposal should be rejected _if_ the consensus is
> >>>> that it adds too much extra complexity.  But IMHO the more bytes on
> >>>> the wire we can save, the more chance there is that Multi-Stapling
> >>>> + Cached-Info will actually get deployed widely.
> >>>
> >>> The concept still assumes that server1 and server2 will have same
> >>> binary response R for certificate X at time T, even if the client
> >>> have previously
> >> only
> >>> be indicated to server2? If both, that means more (unnecessary)
> >>> bytes on the wire, particularly if you have more than 2 servers
> >>> (e.g. 200) with the
> >> same
> >>> server2 would then resend response S. Result: unnecessary bytes on
> >>> the wire.
> >>>
> >>> that servers in different geographical areas connect to different
> >>> OCSP responders which have responses generated at different times
> >>> (or who generate on-the-fly responses).
> >>>
> >>> pronounced if you are dealing with hundreds or thousands of servers
> >>> (as we would likely do with servers using Comodo issued
> >>> certificates, for
> >> example).
> >>>
> >>> chance of guessing wrong about what the server should know based on
> >>> what the client knows.
> >>>
> >>> --
> >>> Sincerely,
> >>> Yngve N. Pettersen
> >>>

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 10 Apr 2013 17:14:51 +0200

On Wed, 10 Apr 2013 16:45:34 +0200, Piyush Jain <[email-masked]>  
wrote:

>> at

"Chain sequence" was maybe the wrong expression. The point was that the  
server can change to a completely new set of certificates, including an  
unrelated certificate authority.

However, some server can have certificates incorrectly ordered, and that  
might get fixed after a while (or it could get broken).

> would also become invalid.

My point is that the information sent to the server about which resources  
are cached need to connect the resources to what the server have, in such  
a way that if the server configuration changes the server will know that  
it does not have the necessary information.

Since that require providing at least one hash that the server will know  
if it have that information, it could be that the boolean flags are  
unnecessary, because the server should also know that those entries are  
expired  or were missing, etc. based on its own information, if the  
indicated resource is known to the server.

-- 
Sincerely,
Yngve N. Pettersen

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 10 Apr 2013 17:14:48 +0200

> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt

In this case I am talking about the boolean flag proposal and how it would  
indicate to a server which responses it have, and particularly how to  
avoid confusion when/if the certificate chain is updated by the server.

>>>> object and
>>>> server and
>>>> list of
>>>> compared
>>>>>>>> Internet
>>>>> Might
>>>>>> that
>>>>> binary
>>>>> bytes on
>>>>> OCSP
>>>>> (as we
>>>>> what

-- 
Sincerely,
Yngve N. Pettersen

---

From: [email-masked] (Martin Rex)
Date: Wed, 10 Apr 2013 17:27:25 +0200 (CEST)

Piyush Jain wrote:
> sequence of certificates in the chain.

This is the theory.

In theory, theory and practice are the same, in practice, they differ.

Although the SSLv3 and *ALL* TLS specs have always been very clear that
the correct ording of certificates in the TLS Certificate handshake
message is a MUST requirement, as well as that only the self-signed
rootCA cert at the end of the path may be omitted, a number of TLS
implementations are notoriously broken in that they will send arbitrary
garbled paths that may include alien certs and even expired certs in
Certificate handshake messages (rather than telling the server admin
that the configuration is incorrect).
 
Although this is not even mentioned in the TLS spec, a number of
SSL and TLS clients will perform various hacks to accomodate for such
broken TLS server implementations, ranging from simple reordering
of certificate, to the extreme of using only the very first certificate
from the servers TLS Certificate handshake message, throw the remaining
certificates into a large pool of candidate path certificates and
perform a full certificate path discovery.

The latter can lead to seemingly non-deterministic behaviour with some
TLS servers that omit more than the self-signed rootCA cert from the
Certificate handshake message, such as intermediate CA certs, and
the client behaviour changes from handshake failure (untrusted cert)
to successful handshake when that "large pool" of cached certs
coincidentally contains the missing intermediate cert from a prior
TLS handshake with a correctly configured TLS Server whose server
cert was issued by the same (intermediate) CA.

I remember that in march 2001 "https://www.verisign.com" was sending
and expired VeriSign rootCA certificate in the server certificate handshake
message.  When I reported this defect to VeriSign Support, they did
(at least initially) not understand that this indicated (a) a defect
(or at least significant sloppiness) in their server's SSL/TLS
implementation and (b) a server configuration errror.

-Martin

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 10 Apr 2013 09:32:37 -0700

Thanks Martin. That is really interesting information.
More inline.
the
> correct ording of certificates in the TLS Certificate handshake message is
a
> MUST requirement, as well as that only the self-signed rootCA cert at the
> end of the path may be omitted, a number of TLS implementations are
> notoriously broken in that they will send arbitrary garbled paths that may
> include alien certs and even expired certs in Certificate handshake
messages
> (rather than telling the server admin that the configuration is
incorrect).

[Piyush] Isn't it a tacit assumption for TLS cached objects that
certificate_list will be ordered. The question is if the broken
implementations can make use of these proposed extensions effectively and if
not then should we really care.
> 
> Although this is not even mentioned in the TLS spec, a number of SSL and
TLS
> clients will perform various hacks to accomodate for such broken TLS
server
> implementations, ranging from simple reordering of certificate, to the
> extreme of using only the very first certificate from the servers TLS
> Certificate handshake message, throw the remaining certificates into a
large
> pool of candidate path certificates and perform a full certificate path
> discovery.
[Piyush] So what would be the cached representation of such chains? The
original list that the server sent or the corrected ordered list that the
client created?
If it is the former, the client can still indicate the certificates for
which it needs the status through a list of Boolean values. If it is the
latter then server has no way to resolve the certificate_list cached object
and it will need to resend all the information again.
But a bigger question is how to create a spec without agreeing on a basic
set of assumptions. If the practices that you describe are useful, then they
should make their way to the TLS spec. If not we stop taking them into
account while designing new specs.

> The latter can lead to seemingly non-deterministic behaviour with some TLS
> servers that omit more than the self-signed rootCA cert from the
Certificate
> handshake message, such as intermediate CA certs, and the client behaviour
> changes from handshake failure (untrusted cert) to successful handshake
> when that "large pool" of cached certs coincidentally contains the missing
> intermediate cert from a prior TLS handshake with a correctly configured
TLS
> Server whose server cert was issued by the same (intermediate) CA.
>
[Piyush]  A couple of points here:
1) We were basing this discussion assuming that server follows the TLS spec
correctly and provides all the required certificates in the correct order.
It was limited to client using OCSP responses from different sources and was
not about client using intermediate certificates from other sources.
2) Not relevant to the current discussion but still interesting. Why does it
matter whether the client obtained the intermediate certificate from the
same server, a different server, an ldap or http repository as long as it
can build the chain to a trusted root? I appreciate your point about server
not catching the error of it ways right away in case of handshake failure if
some clients are smart enough to perform certificate discovery.
 In fact allowing the server to just send its certificate without any issuer
certificates can actually optimize the TLS handshake if the client delegates
the path validation and discovery to an external DPV server.

> 
> I remember that in march 2001 "https://www.verisign.com" was sending and
> expired VeriSign rootCA certificate in the server certificate handshake
> message.  When I reported this defect to VeriSign Support, they did (at
least
> initially) not understand that this indicated (a) a defect (or at least
significant
> sloppiness) in their server's SSL/TLS implementation and (b) a server
> configuration errror.
> 
Again, this is very interesting information. Delivering root certificate and
that too expired one in TLS handshake is sloppy. I hope that the clients
were not sloppy enough to start using those as trust anchors. :)
Now that you mention it, it is probably a common practice for many x.509
applications. The assumption is that you are providing a bag of certificates
to the peer so that he can select the right ones to build a trusted path to
a pre-configured trust anchor. 
[Piyush]

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 10 Apr 2013 09:34:46 -0700

> unrelated certificate authority.

[Piyush] Agreed. However, this is usually a rare event. And the cached
certificate_list and stapled OCSP responses would become invalid anyway.
> might get fixed after a while (or it could get broken).
[Piyush] It probably does not matter as long as the client is assuming the
same order that it received. Please note that certificate_list cache
representation is a single hash. All the client is saying is that this is
the certificate list (containing certificates a,b,c,d) that I have cached
and btw I don't need the status for "a" and "b" but I need the status for
"c" and "d".
> 
> > sequence of certificates in the chain. The certificate chain sequence
> > would change only when the server certificate changes (or in some rare
> > cases when intermediate CA's certificate rolls over). Right? If that
> > happens than certificate_list cached object held by the client would
> > become invalid and consequently any stapled responses associated with
> > the old certificate chain would also become invalid.
> 
are
> cached need to connect the resources to what the server have, in such a
way
> that if the server configuration changes the server will know that it does
not
> have the necessary information.
> 
[Piyush] That requirement is met. If the server configuration is changed in
the way that you describe above, certificate_list cache becomes invalid and
consequently the OCSP response cache becomes invalid.
In other words the server will send the certificate list again and all the
OCSP responses again. This would be the behavior even when you fingerprint
the OCSP responses.
I think it becomes more intuitive if you think about the actual goal from
client's perspective. Clients need to determine the status of each
certificate in the server certificate chain. They don't need to make sure
that the OCSPResponses that they use to make this determination are in sync
with those on the server.
The way I see it stapled OCSP responses are not resources on the TLS server.
TLS server is just a channel that delivers these responses to the client.

---

From: [email-masked] (Martin Rex)
Date: Wed, 10 Apr 2013 21:10:38 +0200 (CEST)

Piyush Jain wrote:
> > implementations are notoriously broken in that they will send
> > arbitrary garbled paths that may include alien certs and even
> > expired certs in Certificate handshake messages (rather than telling
> > the server admin that the configuration is incorrect).
> 
> implementations can make use of these proposed extensions effectively
> and if not then should we really care.

The TLS caching extension ought to operate *STRICTLY* at the TLS PDU level
(as sent over the wire), everything else will be calling for trouble.

At the PDU level / wire format, the ordering of certificates is implied
by the PDUs being 1-dimensional sequences of octets.  Wether the
certificate_list structure properly forms a certificate chain according
to the TLS specification (section 7.4.2) should better be irrelevant
to the TLS caching extension (KISS principle).

  TLSv1.2:  http://tools.ietf.org/html/rfc5246#page-48
  TLSv1.1:  http://tools.ietf.org/html/rfc4346#page-41
  TLSv1.0:  http://tools.ietf.org/html/rfc2246#page-39
  SSLv3:    http://tools.ietf.org/html/rfc6101#page-28

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

> > TLS clients will perform various hacks to accomodate for such broken TLS
> > server implementations, ranging from simple reordering of certificate,
> > to the extreme of using only the very first certificate from the servers
> > TLS Certificate handshake message, throw the remaining certificates
> > into a large pool of candidate path certificates and perform a full
> > certificate path discovery.
>

Exactly what goes on the wire.  Right when the Server composes the
TLS Certificate handshake message, it ought to compare what it intends
to send certificate_list in the Certificate handshake message with the
hash value conveyed by the client and replace (omit the real) data when
the hash matches.  That is the simple, straight-forward and fail-safe
approach.

> > Certificate handshake message, such as intermediate CA certs, and the
> > client behaviour changes from handshake failure (untrusted cert) to
> > successful handshake when that "large pool" of cached certs

In theory, yes.  Existing TLS implementations could even fix any currently
defective behaviour and sort the certificates prior to composing the
TLS Certificate handshake message without fear of breaking interop,
and to conform to what the TLS spec has always been requiring.

For efficiency, any such certificate sorting and certificate sanity checking
should probably done very early (and therefore just once) during the TLS API
calls through which the TLS certificate chain is provided to the TLS
implementation, rather than at the lowest level of the software stack,
every time when the TLS Certificate PDU is assembled.

> can build the chain to a trusted root?

  http://en.wikipedia.org/wiki/Principle_of_least_surprise

(... unless you are in the fortunate position to charge an arm and a leg
 for support and every individual support request on top of it,
 and want to ensure that your customers can not understand
 nor predict the behaviour of your software without your support's help.)

> 
> I appreciate your point about server not catching the error of it
> ways right away in case of handshake failure if some clients are
> smart enough to perform certificate discovery.

On my personal scorecard of engineering goofs, a full certificate path
discovery during the TLS handshake is pretty broken, adding certs obtained
from other handshake is extremely broken, and the diamond level of
engineering goofs is unattended/non-interactive forward AIA chasing
for missing intermediate CA certs.

> the path validation and discovery to an external DPV server.

Terribly BAD idea.  The correct engineering approach is to use
suitable existing TLS protocol features or TLS extension with the
appropriate semantics for that purpose.

For the Server Certificate (chain) either this one (Trusted CA Indication):
  http://tools.ietf.org/html/rfc3546#section-3.4

or the TLS caching extension under discussion.

For the TLS client certificate, the list of certification_authorities
acceptable to the TLS server can be used for the client to figure out
which path CA certificates it needs to send, and which CA certificates the
client can omit from the client Certificate handshake message.

> that too expired one in TLS handshake is sloppy.

Delivering the rootCA cert in the handshake is perfectly reasonable!

Silently delivering an expired CA cert in the forward certification path
for more than a year after it expired suggests that there are a number
of serious problems with the underlying TLS implementation.

>
> I hope that the clients were not sloppy enough to start using those
> as trust anchors. :)

Actually, I would not count on clients _not_ being that dumb.

The original "modest" warning popup from Browsers about problems with
server certs seems to have been so "harmless" for novice users, that
it seems to have been replace by a "Scary Page" in most Browsers.

On top of that, some clients may allow communication peers to provide
in-band a "renewed" trust-anchor with an extended certificate validity
for any existing, but expired trust-anchor that is already in the
clients posession, causing the certificate path validation to succeed.

Depending on how many old expired trust anchors are still in the trust
anchor store, and how long the client permits that in-band trust anchor
update, there _might_ be a dormant security problem.

> a pre-configured trust anchor. 

I'm pretty sure that there is PKI Software out there which is broken
far beyond my wildest/worst dreams.

For the majority of consumers, convenience seems to be significantly more
important than security, and a lot of vendors and developers not only
catering to such desire but regularly add additional, extremely
questionable "value" on top of that, making it a worst common practice
that users at some point begin to "expect" even from reasonable implementors.

-Martin