Minutes IETF98: tls
minutes-98-tls-00

TLS WG - IETF 98
Chairs: Joe Salowey
        Sean Turner
Minutes: Jim Schaad
Tuesday, March 28, 2017
9:00-11:30 (CDT)

TLS1.3 (30min) - EKR
  https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
  https://github.com/tlswg/tls13-spec

  PR #768- proposed to drop the item
  - No response in the room to object.

  PR #762 - short headers - proposed to drop the item
  - No response from the room

  Non-X.509 Certificates
           Hannes - raw public key in cached info used for IoT
                EKR - that should be the easiest to fix.
                        Send me a paragraph on how to use it would be easiest
                Victor - Remember discussions say cache_info should just work.
                DKG - open pgp cert implemention is probably deprecating

  Post handshake client auth
           Hannes - think browser use case - problem w/ IoT
                EKR - Expect to remove from DTLS
                        size of memory is the same as for HRR
                Andre - ok w/ extension
                MT - W/ should make sure small devices are happy.
                Carl - makes sense for server to know who does it support
                EKR - room consensus is to send the extension to opt out.

        Tero - the strings seem tobe somewhat random - is there/should there be
        a plan?
                Might be nice if they are shorter also if a table existe of
                them. The name of the secret and the string name are not always
                consistent
        EKR - should not be an issue to make things more consistent

        Not expecting a new WG last call as no big technical changes so far.
        Expect implementations to camp on 18 for while and then jump forward

DTLS1.3 (30min)
  https://datatracker.ietf.org/doc/draft-rescorla-tls-dtls13/

  ACK - structure
          MT - should not ack handshake messages - because we just process them
                        follow the quick style - include a list of records
                        received.
                Hannes - w/mesh networks - kept timers short
                        right direction - need to think about approach more
                Ian - don't need timestamp unles need super accurate time.
                EKR - why wait lots of round trips to get any feedback
                MT - new content type so not in transcript.
        ACK - which epoch for encryption
                MT - quck position is either one
                Adam - does it need to be encrypt?
                Ben - Epochs are cheap - give them their own.
                DKG - the more in the clear - the greater the linkability and
                traffic analysis Adam - probably can infer conent anyway. EKR -
                suggest do an ack of everything and see what happens.

        Key Upate
        Shrink Packet Header
                MT - hello is in long form already - therefore would have two
                header types anyway IAN - two bytes for the sequence is fine,
                one is very iffy. MT - this is currently 1.5 bytes

   Connection ID
           Christian - Add new requirement - need to look at privacy at just
           one layer
                        privacy event to change all identifiers at same time
                EKR - worried about both intended and unintended transition
                events Eric - token buckets work well w/ load balances as well
                Scott - Random idea for improving token buckets; server has
                static key $K$; for a particular client, server generates a
                random $R$, and gives the client R, and E(R).  When the client
                sends a packet to the server, it picks a value i, and sends the
                server E(R) and i; it then uses Hash(H II i) to encrypt Adam -
                public key encrypt identifier - server only needs to decrypt
                when it does not recognize
                        Have idea to make it not expensive to client
                DKG - Tethering case of laptop to phone would be one where
                client is not aware of phone transitions as internal address
                remains the same as it comes from the phone Hannes - want case
                where this is lightweight Ian - Sufficently costly - might be
                easier to not send connection idea much of the time
                        Do support adding to transport.  New for every packet
                        is going to be too expensive

        Handshake Message Transcript
                Ben- rather not changeit as 1.2 needs to still be supported -
                so cross-version is a problem.


A DANE Record and DNSSEC Authentication Change Extension for TLS (15min) -
Melinda
  https://github.com/tlswg/dnssec-chain-extension
  https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

  DKG - Need to deal w/ SRV records so the server would not know the client
  path.
          client may need to add this info
        MT - final name is still the same, server does not know how you got
        there PHB - Problem is DNS does not distinguish between hosts and
        services.  May want IAB to look at this. EKR - Worried that the rules
        do not create an unabigous list for correct evaluation.
                Either don't need to know about breaks, or breaks are explicit.
        ADAM - original text must moved forward - move more towards the TLS
        cert chaining - give starting point and then all of the data
                and move foward from there might be a better paradymn
        EKR - Should we request a more formal review from the DNS world?


Certificate Compression (15min) - Victor
  https://datatracker.ietf.org/doc/draft-ghedini-tls-certificate-compression/

  EKR - Are these ECDSA or RSA certs? - mostly 2048 byte keys
          Point compression would also remove 32 bytes in certs. 32 octets on
          the key
        Adam - just switch to Ed25519 - same effect
        EKR - suggesting entire certificate - what happens if you add SCT and
        OCSP responses. Ryan - Many responders adding certs into the OCSP
        response - Victor - these are now part of certificate messages - so
        this would be covered. MT- How often is this useful w/ cached info
                Pre-seeding w/ OID values might be useful
        Victor - resumption does not give amplification problems.
                Premade dictionaries are under considerations
                Need to hand assemble it, can't just use current data set as it
                might be biased Primarly worried about first time talking to
                server and not second time - can do resumption in many cases
                there
        Victor -
                If response to long then do HRR
        Adam - Big when given the number of sub-hosts that websites use today -
        200 connections times 1 K EKR - May want to require client support for
        quic Victor - some concerns about compression w/ expansion and code
        Jana - could apply to things like pass tokens? Ian - Harder to get
        resumption on mobile devices - so benifit there Hannes - push cache
        info again -

        Sean - looking for hum for adoption
                Hum to adopt - good strong hum
                Hum to not adopt - crickets


Delegated Credentials (15min) - Subodh
  https://datatracker.ietf.org/doc/draft-rescorla-tls-subcerts/

  EKR - notes on structure of the TLD protocol version string
  Ben- need table of all of these strings
  Adam - This is injected - may want to length prefix it
  DKG - length prefix and cert type
  Richard - reason not to use EKU?
  Adam - ask CA which is easier to do
  Rich - Are any CAs going to support?
  Suboh - not yet
  Ryan - EKU policy flow down may be problimatic
  Adam - one time not two - only 32-bits
  Subodh - relative to the start time
  MT - what about clock skew on clients - this can be a problem.
          Can only do this if the client has done something to get a "fresh"
          time recently
        EKR - reduce the end point time, but not starting clock skew
        MT - reverse clock skew is to make things last longer and also made an
        argument about not-before being an issue as well Sanjay - how is the
        re-issue done S - this is just a server side issue - no changes on
        clients PHB - issue short certs? S - don't use short certs rather than
        going back to CA can be an issue. DKG - increase of the CT logs for the
        CA

        Piotr - 7 days may be too long - given this is untrusted site
        S - This is a max that is enforce by clients.  Can be lower
        EKR - Attacker would put in the cert for forging
        Yoav - The shorter the time, the worst the clock skew problems are
        Erik - knowing rough time from the client might help shorten this.

        spt -
                Hum to adopt - good hum
                Hum to not adopt - a couple of people
        Rich - Not sure that a real problem is being solved because of the
        exposure of keys


Disposition of additional drafts discussed on list (15 min) - SPT

 - Exported Authenticators in TLS
     draft-sullivan-tls-exported-authenticator

     read draft - ~ 10
     Support adoption - mod hum
     Unsupport adoption - crickets

 - TLS 1.2 Update for Long-term Support
    draft-gutmann-tls-ltss

    read draft - ~10
    Support adoption - small hum
    Unsupport adoption - mod hum
    JLS - asking if published by different stream
    EKR - want correct warnings

 - TLS Server Identity Pinning with Tickets
     draft-sheffer-tls-pinning-ticket

     read draft - few
     support adoption - small hum
     unsupport adoption - about the same