Skip to main content

Minutes for TLS at interim-2015-tls-1

Meeting Minutes Transport Layer Security (tls) WG Snapshot
Title Minutes for TLS at interim-2015-tls-1
State Active
Other versions plain text
Last updated 2015-03-18


IETF TLS Interium Meeting - March 10-11, 2015 - 9AM - 5PM
Location: F5 Networks, 401 Elliott Ave W, Seattle, WA
Chairs: Sean Turner, Joe Salowey
Notes: Jim Schaad
Version: 1.0

        Sean Turner
        Hannes Tschofenig
        Martin Thomson
        Daniel Kahn Gillmor
        Andrei Popov
        Andrey Jivsov
        Tod Ouska
        Chris Conton
        John Safranek
        Larry Stefonic
        Hoeteck Wee
        Hugo Krawczyk
        David Holmes
        Richard Barnes
        Jim Schaad
        Adam Langley
        Brian Klisch
        Colin MacCarthaigh
        Rich Saltz
        Eric Rescorla
        Joe Salowey
        J Harper
        Jeroen de Borst
        Brian Hamon

Agenda Bashing
        Hannes - Chached Info
        Also add some time for padding with DKG

Status pages with the chairs

TLS 1.3 Changes
        EKR -
                Review of changes to -04 and -05 drafts
                Only allow duplicate curve representations for existing ones
                and not for new ones Add restirction on a single point format
                to 4492 BIS(?) ---- ACTION Should the list be compete for code
                point in handshake? Open issue for now -
                                Sean no - because would need to do all of the
                                lists anyway.
          Some questions still open about when the hash needs to be included -
          dissusions open with Hugo
                Not all of the backwards compatiblity changes got incorperated
                as some of it is till open issue Pull request 107 finishes
                backwards compatability

Pull Rquestion 107
        Fixing the record version of the client hello
        Mozzilla and Google say - do this and make it strict
        EKR - can we remove the record version or not?
        Need to have all alerts carry it and the client hello
        Prolem with anyone in the middle looking for it
        Alternative - force the record version number to always be (3,1)
        It could be tested in Chrome - but alot of work
        MT - Move to make it fixed to 3.1 in the absence of tests to see if it
        can be removed. AP - send whatever and ignore on receipt - sending 3.1
        ok. What does it send on the server hello ACTION: Change to always send
        3.1 and ignore the value on the receive

        For a 0-RTT mode - server must have some state to prevent replay attacks
         Need to make it consentual for the server
        ** Overview of 0-RTT flow slide
        Question of how much PFS is lost - Adam points out that this is the
        same as is done currently in TLS, but EKR responds with the fact that
        since the key derivication has changed with a different session key and
        master key so that this is not going to be an issue for TLS 1.3 Lose
        PFS on multple resumptions? Have a timestamp in the clear from the
        client - allows for fingerprinting, but this is a requirement to
        release this info to somebody. AP - requires a shared database across
        multiple machines What to do on failure AL - suggests using retry 0 RTT
        mode EKR - Two slides - first one is when the server key is correct but
        the window is out Second slide is the normal case when the key has been
        changed as well Some preference to just have the second case.  It is
        required in any event. DKG - Attack - have sent some data using 0-RTT -
        messed up in the middle (delay or block) - Retry and succeed with full
        handshake - replay (or release) of app data from the first sentence AL
        - This is already done in TLS 1.2 with this for HTTP. EKR - might be
        prevented because the random is part of the replay AL - If attacker
        sends to a new cluster with a different orbit value then cannot be
        prevented. AL - Why did I do the strike register with this attack EKR -
        If use orbit and it is wrong then do a handshake failure - moves it
        back to the appliction layer rather thn the TLS layer ** WHITE BOARD OF
        PROBLEM ** Two cases where this works - non-multi home systems, very
        tight global cache (relly hard to do ), if partioning can be enforced -
        i.e. queries between data centers needed. HTTP has replay in it already
        - so not an issue for that protocol, big issue for other protocols

        Document the mode - make the requirements are known in the RFC.
        State exhaustion attacks are a problem - Close down by narrowing scope
        rather than broaden which is normal DDS attack prevention methods. Need
        to make sure that you don't race the packets to different servers -
        Part of the consistancy definition for the centers

        ACTION - Write down what the mechansim and the security text for
        implementing this feature

        Details of how to do it:

        Problem with cases of not sending application data - client may not do
        it. Other messages are encrypted, but with a key I don't know - how do
        you decide how to skip them. *  Skip until I can decrypt *  Or tag
        which says that I can skip this. *  Have a way of specifying in the
        hello of the length (fails if you want streaming on the app data) * 
        Send one application data packet with all data and one handshake packet
        - can then skip one item.  (AL)

        Suggestion to move all of the handshake messages into a single
        "extension" so that all of the messages are present and you can
        foroward - Break messages on change of encryption and change of
        direction - otherwise it goes into a single message

        Does kill all existing middleware state machines - have died anyway

        Already doing this to some extent for backwards compatability with TLS
        1.2 negotiation

        Client Hello {
           Client Key Share
        }                        ------>
                                             Server Hello {
                                                 Server Key Share
                                             Server Data 2 {
                                               extensions, server cert, cert
                                               verify, cert request, finish
                                                                [ App data]
        Client Data  {
                cert, cert verify, finish
            [App data]


        Client Hello {
           Client Key Share
        { Client Data2 {..., finish}
        [Replayable app data]
                                             Server Hello {
                                                 Server Key Share
                                             Server Data 2 {
                                               extensions, server cert, cert
                                               verify, cert request, finish
                                                                [ App data]

        Issues with encrypting content types - can't figure out what is app
        data in that case. There are some problems with encrypting alerts for
        DTLS - middle boxes can know when things are going away if not

        Every part with consistant cryptographic treatment is batched together.
        Use count of app data messages to skip for 0-RTT fail to the next
        handshake message

        Question of wrapping this together does not change the question of
        co-mingling or using a state machine for TLS 1.3  (EKR)

        If you have a DTLS implemenation that is doing this piecemeal as chucks
        come in, then you are going to have the current state problems [MT]

        Question on what happens if a new message shows up - is this fatal or
        treat like extensions where it is ignored?   Probably should be fatal
        which is 1.2 behavior.

        Question of removing the numbers from the container handshake messages
        except for the client hello - required for bacwards compatability.

        ACTION - Adam will sketch out further to know what the messages are and
        how processing works.

Identifying Cryptographic Parameters (Bhargavan/Pironti)
   EKR - Providing a labeled block with the label reflected by the client
   Question on using the same for PSK - Can you do a 0-RTT fail and negotiate
   if cyrpto suite changes? Reponse - message because need to have proveing alg
   ids which we are trying to eliminate Disadvantage in configuration of the
   client and server needs more data. Would need to have the TLS WG define the
   ids for the PSK suites so back to equivalent of cipher suites. QUIC is
   propsosed as one solution - would need changes to separate the data not
   encrypted from the data encrypted so it becomes more complicated Rather than
   pickling the data - Server gives state number, and the client uses that
   state and value and goes foward assuming that set of state data is correct
   and does a full negotation later if there is a problem. Server still runs
   the negotation algorithm on re-connect and will get the same answer because
   it does not change the algorithm and the client is assumed to supply the
   same input (or equivalent) and the result will end up with the same
   cyrptographic algirthm set. Problem with resumption as the id would need to
   be unique per client because it needs to incude the cipher suite. If config
   id disappears - anounce the result algorithm and preference list - and have
   server verify it is acceptable result. Still need id for the server dh
   share. PROPOSAL - Client sends hello - annouces parameters to use - server
   validates correctness - client indicates a key id - EKR to write up

Padding with DKG - Pull request 142
        Proposal only provides a mechanism for padding or traffic analysis-
        does not say how much or when to pad Two new content types: Padded
        data, Padded handshake EKR - Not padding to block sizes or client hello
        passing F5 devices. In this proposal Padding is being done in the plain
        text block structure EKR - suggest negotate padding in the extesion for
        data -always pad handshake messages EKR - if large records - then two
        bytes is a small overhead - what is the case where you have mixed
        padded and unpadded records where the overhead is large. Can you pad in
        one directonly only - AL - it would be crazy to do this. Benefits
        appear limited to making the client life eaiser by not having both
        methods on send DKG - desire the padding of the data because you are in
        1.3 - server could do it because it knows that the data is sentive and
        the client must be able to receive it. MT - Suggests that extension on
        padding is Opt Out EKR - Updated proposal - allow data padded and data
        unpadded - but handshake is always padded MT - push pack on the size of
        padding_length - make it 8 Can'd do that because it messes with things.
        What is the value of the padding bytes? - OPEN ISSUE: Three proposals -
        discussion appears to be approaching zeros and no verify. OPEN ISSUE -
        can a record consist solely of padding. AL - There are problems with
        having too much padding just like zero length records today.  Need to
        have some limit on the amount of bandwidth used by the TLS stack.
        SUGGESTION - flip the order of fragment and padding in the
        PaddedFrgment structure.

        Policy description - easy policy is pad to a multiple of X bytes
        Discussion of timing attacks based on cache freshness in the server -
        could be fixed by always sending on a timing boundary - but this is not
        an issue for this document.  Timing attack problems are very difficult
        to fix.

        What about the policy descussions - where should they be?
        MT - use somehting similar to what is in the HTTP2 document. - Put it
        into security considerations.

Cached-Info - Hannes
   Slide set displayed
   Question for group: Omission of handshake messages -
                AL - grumpy about this because it moves the world to the state
                machine hell again AL - what if it had multiple cached server
                certificates? - which is chosen by the server. currently only
                allows selection of one certificate by client(?) Quick has this
                built in - common sets of certificates are tagged Move into
                some type of configuration id. EKR - can we move this into 1.3
                and not have for backwards compatability? Does IoT need client
                certificates? Does it need it for 1.2? Digest of the
                ceritifcate message and not the key or the certificate. Use
                SHA-256 for the hash Needs to eliminate the issues of the
                triple-handshake questions. IoT does not need OCSP


DAY #2 - March 11, 2015

        Rich Salz
        Sean Turner
        Jim Schaad
        Martin Thomson
        Hoeteck Wee
        Hugo Krawczyk
        Andrey Jivsov
        Andre Popov
        Eric Rescorla
        Hannes Tschofenig
        Joe Salowey
        Adam Langley
        David Holmes
        Colm MacCarthaigh
        J Harper
        Peter Bowen
        Mike St. Johns (remote)

    1-RTT mode based on signtures, 0-RTT based on shared secret/semi-static DH
    negotiation Recapture concerns expressed in Honolulu about the security
    issues of having a long term DH key that is signing things. Temp compromise
    of a TLS 1.2 server can lead to building a fake TLS 1.3 server beyond the
    acutal compromise of the 1.2 server. Look at the Performance Comparisons
    Some potential issues for use of HMQV for patents.  Both IBM and Certicom
    have them.  IBM has committed to do free usage for TLS (per Hugo). EKR - If
    think could solve into the cases of == or HMQV, then do it and worry about
    other issues later For variabe base - VB DH is about 3 times that of

    Can always put deligation back in later without it being here now.
    Offline will be slower for server than online
    The equality hack - can be done unilterally by the server w/o client
    support - client can detect by doing a comparison of the publics (memcmp)

    Working out details of the equivalent point
    Sig(g^s) deivered under encryption, but g^s is not.
    Issues for 0-RTT that need to supply a new g^s' for the next time.
    Cost of doing RSA for signatures will still dominate the issues.
    In the zero RTT case there are no options - no function for signatures -
    must use the authetiction from the prevsious round trip in moved forward In
    the 0-RTT case could force the server to re-prove key possion - but cost
    does not seem worth while Distinct case of 1-RTT with a cached cert from
    the server - does not need signature signature again use the caached key
    for proof. HMQV cannot encrypt the static key of the server w/o one
    additional expodentiation. MT - Currently no stomache for offline signing
    case - so worse case is the online signing - but should be able to do line
    4 or 5 Hugo - need to make sure that offline signing case can be in the
    protocol even if no need to have it present today. need to have a hole for
    a ECDH certificate for future work. HMQV has different properties for the
    server identity hiding. EKR - I have a hard hat version of line 2 - could
    do the line 4 in about a week - if you don't have tight roll over you kind
    of get from line 2 to line 4 anyway. ACTION - EKR to write up lines 2 and 4
    (+ 0-RTT) for review by the group.
            Remove server cert verify
                        Add signature blob over session hash
                        Add a bit on the performance numbers

    If IP clear on HMQV then can look at if it is worth doing - will require
    changes in terms of what goes forward.

HMQV Disscussion
    K = g^(x(y+es))
    e = H(g^x, g^y)
    for 1-RTT case, server needs to send g^s in the clear or encrypted by g^xy
    If you split the signatures of g^s from g^s and encrypt only the signature
    - less possible information for tracking - less certanty. Possible issue
    w/post authentication Privacy model - linkage between two different entityes
            Discrimiination between two different servers on the same hardware
          Need to look at the implications of SNI encryption and how it
          interacts with this.

         If use g^y=g^s - then send a separate semi-static key and make g^y be
         totally ephemeral.

Update/Rekey - Martin
        Want to protect old traffic from future compromise
        Need to deal with the sync problem - can only force and sync an update
        in one direction Why is there a requirement to make it unidirectional -
                DTLS w/ lossy transmission - is possible problem if a message
                is dropped Force the other side to update it's keys as well
                Allow for force up update for other purposes.
        Why do this in DTLS?  It is a complexity problem.
                Could use epoch change for DTLS if no need for adding
                additional entropy.
        Client auth is going to be more important than this issue because
        exhaustion of IV space is not feasible.

Client Authentication Version of this
        keeping current client auth in the front end is protected
        Rectroactive authetication of request
        HTTP 1.1 problems - AL is willing to say this is dead
        Move to application layer for kick
        How does this interact with resumption?  Server will not remember
        authentication added in stream.  Can stil remember the one at the start
        People are saying that they do not want to deal with new session
        tickets to come mid stream - just the one right after the handshae.
        Need to be able to deliver the ticket immediately after the initial
        handshake. Could use that as the response for TLS session tickets w/
        new authentication Concept is that a new client id will retroactively
        bless all previous keying material.

        EKR - Moving to towards saying that we should do this - does just what
        AP needs -  Can be optional

        Does not roll the traffic keys - make sure that this is not the way to
        do a key roll.  If that is provided needs to be light weight. ACTION -
        AP to do a writup for his cases and also do some work to cleanup the
        certificate request so it is not as large.

        Given that this is decoupled from Update -
        ACTION - make the update mechanism simple and different between TLS and

Key Heirachy/Derivation
        Suggestion is to do HKDF
        In picture - PRF is the extract and PRFH is the expand functions of
        HKDF. Make sure don't use the same secret with two different HKDF hash
        functions. Questions of why the 0 in the picture - response is that
        this is the key and the random values is the data to be hashed. For
        HKDF - all context goes into the expansion and not into the extraction.
        AL - why is the server config not input to the early appliction traffic
        keys? AL - believes that should tie this to SHA-256 for ever. MT - If
        we need to fix then new protocol EKR - configure one PSK and allow it
        to be used with different hash functions - this violates the problem
        ACTION - need a security consideration on this at a minimum Use
        different context values for the three way split at the bottom of the
        picture. Allows for HSM to enforce on some exporting and others not
        Question of where unique comes from Make it just an exporter value For
        PSK w/o DH - put the PSK in for both the static and the ephermal secret
        Consider doing two extrations for the traffic keys rather than overlong
        generation of data and parsing.

        Need to correct the nonce so it is always a counter and has no input
        from the KDFs for the purpose of AED functions. ACTION: fix AES-GCW top
        32bits are 0, 96 bits are counter HUGO - use the same salt value if you
        are makeing multiple calls

MTI cipher suites
        What should the symmetric algorithm be - AES-GCM-128 vs ChaCha/Poly -
        MUST AES-GCM-128 - SHOULD ChaCha/Poly
                        fips requirements
                        IoT - wants to use CCM but there could be a profile to
                        support the environement.
        What should the hash function be - SHA-256
        What should the ECDH be - MUST P-256 - SHOULD 24559
        What should the signature be:
                   certs - MUST ECDSA P-256,  MUST RSA  --- need to be able to
        SHOULDS from CRFG assume they show up in the "near" future

        What to do with the curves currently in the draft.
        Pull the rest of the curves and mark as reserved?
        EKR - normalize - and mark as reserved/obsolete
        Keep - suite B P-384?
        Brainpool curves - some german projects may object to removal

        ACTION: Create a recommended list of algorithms in the TLS 1.3 spec.
        To update the recommended list requires an update to TLS 1.3.
        People can do vanity algoirthm registration but does not hit the
        recommended list.

        Question about ANON_ANON ciphers - do we remove this.
        Only known use is mail servers - may be others.

Signature format/orthaognal negotiation
        need to specify in 1.2 and above signature information
        Cipher suite infrmation either redundant or conflicts
        Remove the signature infomration from the current ciphersuite table -
        move only to the extension Make the removal of signature infomation
        only from new cipher suites Pushing for this was to get PSS signatures
        supported correctly.

        ACTION - Find somebody who is enthausitic and get a proposal from them
        about this. MT will write a pull request on this.

        Should we transition to PSS in 1.3 as well?
        TLS must be able to process both PSS and 1.5 for verification, must use
        pss for online signature creation? Question of hardware support for PSS
        would that be an issue?  Might be true ACTION: Push the idea out and
        see what people are going to think about this