On 07/11/2016 11:16 PM, Ilari Liusvaara wrote:
> On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote:
>> Folks,
>>
>> I've just submitted draft-ietf-tls-tls13-14.txt and it should
>> show up on the draft repository shortly. In the meantime you
>> can find the editor's copy in the usual location at:
>> As usual, comments welcome.
>> -Ekr
> Did a readthrough, here's a bunch of comments (didn't check the
> issues list):
Should we bulk-open issues for these so they don't get lost? I will
only cherry-pick a couple to reply to.
> -----------------------------------------------------------------------
>
>> ### Server Hello
>>
>> cipher_suite
>> : The single cipher suite selected by the server from the list in
>> ClientHello.cipher_suites. For resumed sessions, this field is
>> the value from the state of the session being resumed.
>> [[TODO: interaction with PSK.]]
> 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.
> 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.
>
>> ### Negotiated Groups
>>
>> As of TLS 1.3, servers are permitted to send the "supported_groups"
>> extension to the client. If the server has a group it prefers to the
>> ones in the "key_share" extension but is still willing to accept the
>> ClientHello, it SHOULD send "supported_groups" to update the client's
>> view of its preferences. Clients MUST NOT act upon any information
>> found in "supported_groups" prior to successful completion of the
>> handshake, but MAY use the information learned from a successfully
>> completed handshake to change what groups they offer to a server in
>> subsequent connections.
> Are those supposed to be filtered to be subset of ones client advertised
> or not? E.g. if client didn't indicate support for x448, can the server
> still send x448?
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.
>
>
>> [[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...
>
>> ### Early Data Indication
>>
>> obfuscated_ticket_age
>> : The time since the client learned about the server configuration that it is
>> using, in milliseconds. This value is added modulo 2^32 to with the
>> "ticket_age_add" value that was included with the ticket, see
>> {{NewSessionTicket}}. This addition prevents passive observers from
>> correlating sessions unless tickets are reused. Note: because ticket
>> lifetimes are restricted to a week, 32 bits is enough to represent any
>> plausible age, even in milliseconds.
>
> And the addition also prevents correlating session with its parent,
> even in case of reuse (this was the reason for switching to addition
> from XOR).
>
>> A server MUST validate that the ticket_age is within a small
>> tolerance of the time since the ticket was issued (see {{replay-time}}).
> 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.
> Also, requirement that the server MUST proceed with the handshake and
> reject 0-RTT if that validation fails would be good here...
Definitely.
> 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].
>
>> #### 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?
> 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...
>> ### Encrypted Extensions
>>
>> The same extension types MUST NOT appear in both the ServerHello and
>> EncryptedExtensions. If the same extension appears in both locations,
>> the client MUST rely only on the value in the EncryptedExtensions
>> block. All server-sent extensions other than those explicitly listed
>> in {{server-hello}} or designated in the IANA registry MUST only
>> appear in EncryptedExtensions. Extensions which are designated to
>> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients
>> MUST check EncryptedExtensions for the presence of any forbidden
>> extensions and if any are found MUST terminate the handshake with an
>> "illegal_parameter" alert.
> This seems inconsistent. In implementation, I would write explicit disjoint
> whitelists of extensions for both (and non-whitelisted one is a fatal
> error). Explicit whitelisting is safe even on client side, since the
> extensions are bounded by client-supported ones.
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]?
>
>> ## Random Number Generation and Seeding
>>
>> To estimate the amount of seed material being produced, add the number of
>> bits
>> of unpredictable information in each seed byte. For example, keystroke timing
>> values taken from a PC compatible 18.2 Hz timer provide 1 or 2 secure bits
>> each, even though the total size of the counter value is 16 bits or more.
>> Seeding a 128-bit PRNG would thus require approximately 100 such timer
>> values.
> 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.
>
>> # Overview of Security Properties {#security-analysis}
>>
>> [[TODO: This section is still a WIP and needs a bunch more work.]]
>>
>> A complete security analysis of TLS is outside the scope of this document.
>> In this section, we provide an informal description the desired properties
>> as well as references to more detailed work in the research literature
>> which provides more formal definitions.
>>
>> We cover properties of the handshake separately from those of the record
>> layer.
> 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)
>
>
> (The TLS 1.2 exporter without EMS failed the middle requirement,
> creating security issues in applications that assumed the data was
> connection-unique.
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
