Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt

Hi Dave,

Thanks for correcting my notation. The text in TLS 1.2 and 1.3 is 
confusing and I misunderstood it. This sentence is absolutely opaque to 
me: "The length will be in the form of a number consuming as many bytes 
as required to hold the vector's specified maximum (ceiling) length."

Regards,
	Yaron

On 10/11/2015 11:21 PM, Dave Garrett wrote:
> https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00#section-3
>
> Your notation is incorrect. Please read the section on vectors carefully, as it *is* confusing and the notation is not what is usually assumed. I'll cite the TLS 1.2 spec as it has not changed:
> https://tools.ietf.org/html/rfc5246#section-4.3
>
> For "type name<n..m>;", the range [n,m] is always in _bytes_, not entry count. In particular, note the second example at the end of the vectors section:
>        uint16 longer<0..800>;
>              /* zero to 400 16-bit unsigned integers */
>
> All 3 of your arrays of strings are listed with "<0..1>", which actually notates zero or one byte, not zero or one element. There is no way to explicitly state a range of allowed sizes by entry count with variable length entries, within this notation. Yes, this is not great and yes, this is often misunderstood. You'll have to mandate entry count with a "MUST" in the body of the text.
>
> No, it's probably not going to be changed any time soon, as that would contradict past specifications' notation. Maybe something like "type name<min_bytes..max_bytes>[min_count..max_count];" could work, but that's probably not worth the confusion of introducing a new and more complex notation.
>
> On the actual topic of the proposal, I haven't looked into it in detail yet, but I am glad to see pinning being worked on at the TLS level.
>
>
> Dave
>
>
> On Sunday, October 11, 2015 03:57:38 pm Yaron Sheffer wrote:
>> We have a standard for certificate pinning (RFC 7469), but it is rather
>> hard to use and as a result is rarely deployed. This draft proposes a
>> lightweight alternative that allows TLS clients to authenticate the
>> server they're connecting to, even if a rogue CA can generate fake
>> certificates for that server.
>>
>> The draft is currently TLS 1.3-only, and is based on the previous draft
>> of 1.3 so some minor details may have changed.
>>
>> Comments are of course most welcome.
>>
>> Thanks,
>> 	Yaron
>>
>>
>> -------- Forwarded Message --------
>> Subject: New Version Notification for
>> draft-sheffer-tls-pinning-ticket-00.txt
>> Date: Sun, 11 Oct 2015 12:35:17 -0700
>> From: internet-drafts@ietf.org
>> To: Yaron Sheffer <yaronf.ietf@gmail.com>
>>
>>
>> A new version of I-D, draft-sheffer-tls-pinning-ticket-00.txt
>> has been successfully submitted by Yaron Sheffer and posted to the
>> IETF repository.
>>
>> Name:		draft-sheffer-tls-pinning-ticket
>> Revision:	00
>> Title:		TLS Server Identity Pinning with Tickets
>> Document date:	2015-10-11
>> Group:		Individual Submission
>> Pages:		14
>> URL:
>> https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/
>> Htmlized:
>> https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-00
>>
>>
>> Abstract:
>>      Fake public-key certificates are an ongoing problem for users of TLS.
>>      Several solutions have been proposed, but none is currently in wide
>>      use.  This document proposes to extend TLS with opaque tickets,
>>      similar to those being used for TLS session resumption, as a way to
>>      pin the server's identity.  That is, to ensure the client that it is
>>      connecting to the right server even in the presence of corrupt
>>      certificate authorities and fake certificates.  The main advantage of
>>      this solution is that no manual management actions are required.
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>