Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Benjamin Kaduk <> Wed, 13 July 2016 00:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56A4012D0E1 for <>; Tue, 12 Jul 2016 17:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.988
X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D3k9sgPTwHTo for <>; Tue, 12 Jul 2016 17:41:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3ACC712D541 for <>; Tue, 12 Jul 2016 17:41:03 -0700 (PDT)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id B140F4336DF; Wed, 13 Jul 2016 00:41:02 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 88C1C4336D8; Wed, 13 Jul 2016 00:41:02 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1468370462; bh=EMLE3HfVeEbeY9CQiJm3SUKKeByTMyAp0XPE0vnnxj0=; l=4577; h=To:References:Cc:From:Date:In-Reply-To:From; b=I+zviFpfrFue8n5TqLgK/CcbVSHwk7FNb2JBl8lNPIwlSioR3IMx01SHS//Zz08Vk UIhVgpODy5/0El/a0bC17q5kJBQma2UORZYEbupRXHuHqJTHBJgv8rq7RVAMWnOT3U 8g4bAkFxfS/90pMVfe71qBRDe36aaK6xVJ/z0Ixw=
Received: from [] ( []) by (Postfix) with ESMTP id 496841FC9B; Wed, 13 Jul 2016 00:41:02 +0000 (GMT)
To: Ilari Liusvaara <>
References: <> <> <> <>
From: Benjamin Kaduk <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 12 Jul 2016 19:41:02 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jul 2016 00:41:06 -0000

On 07/12/2016 04:07 PM, Ilari Liusvaara wrote:
> On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote:
>> On 07/11/2016 11:16 PM, Ilari Liusvaara wrote:
>> Requiring filtering would prevent the client from learning when the
>> server supports new schemes, but having the server not filter would
>> likely end up with the server "always" sending a big pile of stuff even
>> if the client has no idea that those schemes even exist.  So, on the
>> balance, I would go with filtering.
> What would the client do with unknown groups anyway? Dump a message
> to log?

Basically.  One could contrive an example where the client software knew
about something but didn't normally send it, but that seems too
contrived to care about.

>>> Good luck with that...
>> It would be good to not repeat the mistake that is the 5-minute replay
>> window in Kerberos.  (So, shall we make "small tolerance" a concrete
>> value or otherwise give guidance?  5 seconds?  4xRTT? other?
>> But, IIRC, this check does not require absolute time agreement between
>> peers, only that their clocks advance at a similar rate.  If your clock
>> steps because you slept your laptop and you have to fall back to a full
>> handshake, oh well.
> In one piece of code I wrote, I pulled +-15s maximum (config can have
> tighter limits) out of thin air...
> And, actually, since failing 0-RTT time check is just 1-RTT delay
> (since in proper implementations it is not a fatal error).

Right, so we can be relatively stringent in our guidance.

>>>> #### Replay Properties {#replay-time}
>>>> There are several potential sources of error that make an exact
>>>> measurement of time difficult.  Variations in client and server clocks
>>>> are likely to be minimal, outside of gross time corrections.  Network
>>>> propagation delays are most likely causes of a mismatch in legitimate
>>>> values for elapsed time.  Both the NewSessionTicket and ClientHello
>>>> messages might be retransmitted and therefore delayed, which might be
>>>> hidden by TCP.
>>> I don't think variations in clocks are minimal...
>> Just to check: you mean the rate at which clocks advance, and not the
>> absolute number reported as the time?
> Correct. I should check the computers I have for what the tickrate
> approximately is (one curious observation: rebooting computer changes
> the tickrate(!)). I think I estimated 140ms/day drift for one of
> those (the others can be way worse). 
> However, the rate of change of the rate (2nd derivate of time reported
> relative to "true time" (one can for all practical purposes ignore
> SR and GR here)) should be small.

Hmm, I would expect this second derivative to be sensitive to things
like the temperature of the oscillator (and thus not always small).

>>> I wonder what 95% timeskew interval per day is...
>>> (Oh, and have fun with leap seconds!)
>> It only matters how big the skew is relative to the acceptance window
>> and how long the ticket is valid for.  Which brings us back to what the
>> acceptance window is measured in...
> IIRC, maximum ticket validity is 7 days (but for some crappier clocks,
> that can be lots of drift).
> But likely TCP delays and such can cause bigger errors than slightly-
> bad clocks.

Hence my question about whether some multiple of (estimated) RTT would
be reasonable.

>> You would have an explicit whitelist of all (including encrypted)
>> extensions for the server, so that it chokes when a client starts
>> sending a new one?  Or just that it would not be considered for further
>> processing [and potential inclusion in ServerHello]?
> The opposite way: I would have client choke if server sends it extension
> outside those lists (TLS 1.3 clients are already supposed to choke if
> server sends them extension they don't know about, this is only extending
> it to per-messages lists).

That certainly makes sense.  I thought you also wanted a whitelist for
the server to use, and wasn't sure how that would work.

>>> This seems really obsolete. The timers have not been 18.2Hz for years, and
>>> applications running on operating systems damn better use OS services for
>>> random numbers, given that anything else is fraught with peril.
>> Sadly, there is a vocal minority of software implementors that insist
>> that the OS service is too slow and write their own.  But I agree this
>> section needs some work; I may be able to contribute some text.
> I think "SHOULD" would be suitable.