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

[Benjamin Kaduk <[e-mail]>]

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

Sure.

-Ben