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

[Ilari Liusvaara <[e-mail]>]

On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote:
> On 07/11/2016 11:16 PM, Ilari Liusvaara wrote:
> > Isn't this the true ciphersuite used on this connection, "resumption"
> > or not? Otherwise you can get into all sorts of crazy situations that
> > WILL be sources of implementation bugs.
> 
> It probably ought to be, yes.

If the field is allowed to contain some ciphersuite with wrong key exchange
type, it takes sniffing extensions from ServerHello and EncryptedExtensions
to figure out what the actual ciphersuite is. And knowing the key exchange
type is rather important in not getting hit by SMACK.
 
> > The idea that it isn't true ciphersuite brings me bad flashbacks about
> > TLS 1.2 ticket "maybe resume" craziness (except this would be even
> > worse).
>
> I feel like we had discussed what the resumption ciphersuite should be
> previously, but I don't seem to be able to find it in my mail archives.

AFAIK, the ciphersuite with the same protection and PRF, but some PSK
or GDHE-PSK key exchange type.

There is well-defined function from (kextype,protection,prfhash) into
ciphersuite (or that no such ciphersuite exists).

> 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?
 
> >> [[TODO: Recommendation about what the client offers.
> >> Presumably which integer DH groups and which curves.]]
> > Bit crazy algorithm: If you haven't heard of this server before,
> > pick smallest you support, if you have, pick the one it selected
> > the last time.
> 
> It does make it clear that things are only as secure as the weakest
> algorithm they will accept ... but stateless clients will also always
> get that weakest link.  (Okay, "smallest" does not necessarily equal
> "weakest", but still.)  With guidance on not supporting silly things,
> this algorithm does not seem too crazy...

Well, what client accepts is separate question to its speculative
guesses for performance improvement. And for the first, there is
supported_groups. key_share is not meant to be xmas tree!


> > 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).
 
> > Oh, still trial decryption... Got it. 
> 
> I had managed to previously forget how we ended up deciding on trial
> decryption, but it basically was dkg commenting in the room at Buenos
> Aires "are we writing a security protocol or a protocol that is
> convenient to implement?" [with respect to the privacy/leakage from
> having the alert or other signal be unencrypted].

I thought they had switched to something else, but apparently not...
 
> >
> >> #### 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.
 
> > 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.


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

> > 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.
 
> > I think properties of the exporter should be covered as well:
> 
> I agree (but am unlikely to be able to contribute text).
> 
> -Ben
> 
> > - Is it intended to generate secret data (yes)
> > - Is it intended to generate connection-unique data (yes)
> > - Are values for different labels/contexts intended to be computationally
> >   independent (yes)

Oh, and stick that it stays constant for the duration of the
connection as well...


-Ilari