On Tue, Jul 12, 2016 at 1:31 PM, Benjamin Kaduk <[email protected]> wrote:
> 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.
>
I opened one giant issue because I haven't gone through this yet
If you want to open individual issues that you think are meritorious that
woul dbe fine
-Ekr
>
> > -----------------------------------------------------------------------
> >
> >> ### 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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
