Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-cached-info-13

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 8 Oct 2012 22:19:11 +0000

We have not received many comments on the draft.  If you have reviewed the draft and support its publication please indicate so on the list.   Also, if you have implemented or are planning to implement cached info that would be useful information as well.  

Thanks,

Joe
On Sep 16, 2012, at 9:10 PM, Joseph Salowey (jsalowey) wrote:

> This is an announcement of working group last call for draft-ietf-tls-cached-info-13.   Please send you comments to the TLS list by October 8, 2012.  
> 
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Adam Langley <[email-masked]>
Date: Mon, 8 Oct 2012 18:28:42 -0400

> We have not received many comments on the draft.  If you have reviewed the draft and support its publication please indicate so on the list.   Also, if you have implemented or are planning to imple…

I'm disappointed that we couldn't use FNV1a as the hash function, but
not so disappointed that I think it's a fatal flaw.

So I support its publication. I don't have any current plans to
implement it, but might do the OpenSSL side for fun at some point.

Cheers

AGL

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 8 Oct 2012 22:37:18 +0000

This sounds like a reasonable request.  Does anybody see any issues with adding this support?  This may also be something that we can take care of in draft-ietf-tls-multiple-cert-status-extension. 

Thanks,

Joe
On Sep 17, 2012, at 12:50 AM, Rob Stradling wrote:

> Would it be possible to add support for cached CertificateStatus messages (see RFC 6066 Section 8 "Certificate Status Request") ?
> 
> On 17/09/12 05:10, Joseph Salowey (jsalowey) wrote:
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

---

From: Rob Stradling <[email-masked]>
Date: Tue, 09 Oct 2012 09:19:32 +0100

> This sounds like a reasonable request.  Does anybody see any issues with adding this support?  This may also be something that we can take care of in draft-ietf-tls-multiple-cert-status-extension.

I think it would be better to take care of this in 
draft-ietf-tls-cached-info, because the CertificateStatus message is 
already defined (in RFC6066) and it has nothing to do with "multiple" 
certificate statuses.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Tue, 09 Oct 2012 14:14:22 +0200

Sorry about the delay.

In my opinion, as mentioned during a WG meeting, I think the range (8 bit)  
of the CachedInformationType is too short. While the handshake type may be  
8-bit, the TLS extension enum is 16 bit. My suggestion would be to  
increase the size of this field to 16 bit.

I won't call this a blocker, but in the event that we pass 255 information  
types, a new extension would have to be defined.

One related note, perhaps for future consideration, if a client registers  
cache entries for many items, then the size of this extension on the wire  
could become significant. Should this be handled somehow, for example  
through a shorthand "I sent you a list of entries earlier, with this ID"?  
One point against this is that it would require the server to remember  
what the client have sent, and it might create curious error situations.  
Another is that the extension can max be 64K anyway, which limits both the  
number of items that can be stored and the bits-on-the-wire footprint.

On Mon, 17 Sep 2012 06:10:08 +0200, Joseph Salowey (jsalowey)  
<[email-masked]> wrote:

> This is an announcement of working group last call for  
> draft-ietf-tls-cached-info-13.   Please send you comments to the TLS  
> list by October 8, 2012.
>
>

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************

---

From: Robert Cragie <[email-masked]>
Date: Wed, 17 Oct 2012 23:31:49 +0100

Apologies for the late response and also if this has been discussed 
before and indeed if there is also a solution for this I am unaware of.

I support the principle behind using cached information but the case 
presented in draft-ietf-tls-cached-info-13 is limited and not wholly 
representative of the exchange between "smart objects connected using a 
low power 802.15.4 radio". For mutual authentication in M2M scenarios, 
it could do with being more flexible with regarding to caching 
information on certificate chains which may already be present in the 
devices. For example, given a three chain certificate, the root CA 
certificate will be in place (already covered in RFC 5246) but the 
subordinate CA certificate may well also already be in place in both 
devices wishing to authenticate. In this case, it is only necessary to 
send the respective device certificate itself and it would be useful to 
indicate whether this can be done. The potential savings are greater the 
longer the chain, of course. The cached info principle could be used to 
send fingerprints of the stored certificates (not the whole certificate 
list) between client and server a priori so each side can determine what 
actually needs to be sent in the certificate field itself.

It may be possible to write this up in another supplemental draft which 
uses a different CachedInformationType for this purpose. There may also 
need to be an additional extension type to convey the information in 
ClientHello.

Robert

On 09/10/2012 1:14 PM, Yngve N. Pettersen (Developer Opera Software ASA) 
wrote:
>
> Sorry about the delay.
>
> In my opinion, as mentioned during a WG meeting, I think the range (8 
> bit) of the CachedInformationType is too short. While the handshake 
> type may be 8-bit, the TLS extension enum is 16 bit. My suggestion 
> would be to increase the size of this field to 16 bit.
>
> I won't call this a blocker, but in the event that we pass 255 
> information types, a new extension would have to be defined.
>
> One related note, perhaps for future consideration, if a client 
> registers cache entries for many items, then the size of this 
> extension on the wire could become significant. Should this be handled 
> somehow, for example through a shorthand "I sent you a list of entries 
> earlier, with this ID"? One point against this is that it would 
> require the server to remember what the client have sent, and it might 
> create curious error situations. Another is that the extension can max 
> be 64K anyway, which limits both the number of items that can be 
> stored and the bits-on-the-wire footprint.
>
>
>