Minutes for TLS at interim-2014-tls-1
minutes-interim-2014-tls-1-3

IETF TLS Working Group Interim Meeting
Dates: May 15-16, 2014
Location: 1899 Wynkoop Street, Suite 600, Denver, CO, USA
Chairs: Joe Salowey, Eric Rescorla, Sean Turner
Note Taker: Jim Schaad
Revision: 1
===========================================================

Attendees
==========================================================
Eric Rescorla
Martin Thomson
Wan-Teh Chang
Sean Turner
Joe Salowey
Daniel Kahn-Gillmor
Hovav Shacham
Steve Checkoway
Rich Salz
Brian Sniffen
Charlie Gero
Erik Nygren
Andrei Popov
Jim Schaad
Andy Lutomirski
Joe Hall
Quynh Dang
Alfredo Pironti
David Holmes
Tom Ritter
Mike St. Johns
Joe Hildebrand
Matt Miller (part of day 2)

Day One (15 May 2014, 9:00 am - 5:00 pm MDT)
===========================================
Review of agenda
* Introductory materials (Note well)
* Agenda bashing -
** Swap the SNI and triple handshake agend

Day 1 Agenda
-----------------
- Get Settled, Administrivia, Agenda
- Encrypt SNI or not
- Fixing Session Resumption (Triple Handshake)
- Client Puzzles
- Discuss Handshake Flows

**** Start with EKR presentation on SNI
Desire to get a strong consensus on where the SNI is going by the end of the
meeting MSTJ (Mike St. Johns) - this is the only thing not used by TLS - Martin
(Martin Thomson) - put them on a wild card server Sean (Sean Turner) - do
nothing not an option MSTJ - proxy setup - put work factor w/ the side the
benefits Alfredo (Alfredo Pironti) - What is fail hard EKR (Eric Rescorla) -
will not connect at all for pre-knowledge fail hard - fail soft - then go
though the full protocol MSTJ - if publish public keys - then a transition
problem EKR - do future pending martin - makes moving servers around harder
MSTJ - talking about inserting a layer 3.5 in the net
     mapping from application/naming to multiple sites on  single IP set
     virtualization of IP addresses - should this be in the stack?
     use multiple ip addresses on single location
     wait until it gets fixed elsewhere
JoeH (Joe Hildebrand) - if TLS 1.3 does not allow similar scenarios as 1.2 then
adoption problems DKG (Daniel Kahn Gilmore) - problems with multiplexing 1.2
and 1.3 on the same port Erik (Erik Nygren) - lack of SNI is blocking some
deployment for TLS

*****  ERIK Nygren presentation
Brian (Brian Sniffen) - most up to date python has SNI
Charlie Gero - active attack look @ SNI to drop connections - DOS attacks
Erik - does really not wnt to entertain dropping SNI
Rich (Rich Salz) - does death of XP help?
Erik - XP is std boogey man - but is only 20%
     android is much bigger problem
DKG-  androids are not being updated
Brian- passive adversary - is generic NSA one -
      ATT will look at DNS and addresses - for advertising
      if used encryption - then they are not passive because they own DNS
JoeH (Joe Hall) - Turkey was blocking DNS requests from some spaces
DKG - we are talking about the intentions of the handshake not the data
brian - timing attacks against hTTP over tls my lead to leak of information on
which page
      can protect secrets but not privacy.
Tom - assuming closed world of pages
    encrypted SNI is trying to protect against closed world
brian - assume attacker knows which systems are on which ip addresses
tom (Tom Ritter) - recap of mail message from today
dkg - questions on TLS padding - why bother if somebody else might leak
alfredo - need to have corporation on the websites on the shared location
     to shape traffic to make things better masked
brian - case of wikipedia - is there a recipe to protect for a single site
tom (Tom Ritter)- miller paper presents way to do this
erik - how do you modify enough content providers to go through the effort to
do this. wtc (Wan-Teh Chang) - examples of sensitive web sites are virtual
hosts?
    confused about the severity of this problem
ekr - not chartered to be tor -
    is there something we can do to make life better -
ekr - on appendix slide - questions
erik - return enough information to clean up -
     rotate to prevent building lookup tables
JoeS (Joe Salowey) - on pictures page -
     does the multiplexor operator (TCP forwarder) need to be protected
Erik - TCP forward would need to deal with protection of the encrypted stream
to know the forwarding material ekr - covers what you need - don't need to have
strong shared key material erik - DNS will cover the requirements for these
cases - don't need to have
     just decrypts sni info to forward.

design discussion from ekr on how a middle box could be configured for
triggering

ekr - first time give up is a way of not doing - then get token back -
    token returned encrypted

***** DKG & Tom slide deck

ekr - client start w/ no info on the server
    gets the data from the dns
    dns middle boxes strip dnssec
    forces you into the posture I want you in
dkg - in the future there will be clients willing to do a lock down if not all
conditions are met erik - want to have a whole picture not build piece meal

ekr - on danish slide - thinking DH group and public
    requires a new decryption (group operation) on each new connection
mstj - guy managing middle box is now managing key material and publishing to
dns

--- question on why if you get dnssec then do 1.2
    cannot distinguish w/ middle box that is stripping all dnssec that kills
    everything
tom - people behind load balancer can leak the information in lots of ways -
    more than just ing the key id as an SNI
brian - customers which are highly sensitive to delays - may be willing to
      leak the SNI information
ekr - why not carry algorithm in message
some agreement is that this consumes bandwidth
ekr - people who remove stuff from the protocol live to regret it
    this is all public info -why not send it

*** BREAK
Andy (Andy Lutomirski)- presentation on ideas - no slides

IP
mask_id
mask_ pubkey
mask_algo
mask_overhead - excess bytes to emit
tls version
hard/soft fail

Enc function: indistinguishable from random and non-malleable
    (intermediate can't monkey and get something that works)

C->S contains hello TLS 1.3, masked hell [ real hello]
                                = mask_id, Enc(maked_pubkey)

front end can deal with start - decrypt and just forward everything else

ekr - only info needed is server group
encryption can be symmetric
return using new serverHelloMask for how the server encrypts back

ekr - this and last presentation seem to be similar - just difference in focus
tom - agreed - just different parts of it
ekr - what is in the finish messages?
dkg - would be nice if there was a MITM for the pre-handshake details
tom - include extension w/ hash of pre-handshake inputs

Discussion on using a key vs a token (previous EKR proposal)
Tom - loses security on multiple clear uses
ekr - discussion on resumption has not happened - leak data then

ekr - the designs appear similar
    complexity of the coordination of key material with the designer
    complexity of crypto in the load balancer
    sync between clients and and load balances
    roll over

erik - use of ip addresses may be problematic for DNSSEC combinations between
ip addresses and dns names hovav (Hovav Shacham) - cannot bind between the
security properties of the balancers and the server
      * if you include info about the balancer info
erik - big difference in the security level -  mask is a good name for what the
balancer has

ekr - proposals are all interconnection w/ DNS
    DNS dependencies needs to not be required
DKG - don't needs DNS for one more RT
DKG - re-handshake - in the case of no info

ekr - should have this ode and allow for a method of doing SNI in the clear as
well. brian - when get a wild card cert - cache this - then use then SNI for
the wild card name If keep info in the browser then can get to zero RT case.

****** Lunch

Sean - AD has sent message with suggestion of hashing the SNI -
room - not much value of just hashing
MSTJ - can we split the SNI out of TLS to some other layer?
     make the client build and encrypted SNI and supply
-- does not deal with the APLN
MSTJ - the SNI needs to be dealt with by non TLS entities - APLN could be
inside of the TLS connection -
     setup key material before doing things
     one possibility is to visit an external side to get the information for
     this and off load ll of the data can be symmetric decryption of the tag
     and then route
tom - leads to most people will send clear and rest will send SNI replacements
    - can allow both non-encrypted and encrypted key id/sni pairs

Discussion on how a nation state will block this
   - block anything with an encrypted SNI
   - block the protocol that gets the SNI
   - country will not allow for TLS 1.3

Discussion of number of EC operations
   - one for the load balancer
   - two or three for the client and server?

Problem is you make the load balance into the world of crypto, auditors,
additional managers DKG - in that case keep an encrypted SNI that is just
simple lookup EKR - problem is where does the client get the data is even bigger
    - problem doing a combined approach is additional complexity with fallback

question of the NIST community using a non-nist curve for this purpose.
          problem with auditor  -- don't go there

Different types of algs for the pre-handshake

ekr - question on what to do if the first DH group is not supported by the
server.

difference between one time sni tokens - and replay detection tokens
    - they have different requirements of security -
    - one needs to just keep some state -  needs to be able to rebuild from the
    token,

EKR - political question - people who deploy the big systems - really excited
about mandatory to use encrypted SNI

brian - mandatory encrypted SNI is a wonderful dream -
      - many big providers stay on 1.2 if too hard
erik - for the case of optional bootstrap from the DNS
     - worry about the fact that at scale people are going to be fine,
     but for small people it might be a real issue
- Fallback to two round trip if it is too complicated
?? - If share info - then can approach a 1RT over time - shared info would be
keys and who you can talk to Return the set of information on a query from the
client can be hit by active attackers - but not passive ones loose one RT only
on first connection - can then cache the info

Discussion of SRV and other types of records

Sean - how do we summarize this?
Erik -
     having an option that allows for optional client hello encryption by
     putting bootstrapping in the DNS appears to have no strong objections
MSTJ - issue of discussions between the dns and http administrators
     - what happens with wrong information?
     - no extra costs for the server if things are not up-to-date
Erik - the complexity is getting so high that leaving things in the clear are
simpler -
     DNS is the only way not to have the layers of security.
MSTJ -
     forget about SNI issues
     Client                             Server
         ---->Ephem Propsed ---->
     <---- Ephem Ack ----

     at the end you have shared secret on both sides - need cipher neg somewhere

      -----CL---->        all of these lines are encrypted
     <---- Sever----

Erik - should the first piece be at the TCP-crypt layer not in TLS
MSTJ - the SNI is not part of the TLS negotiation
     the rest of this does not need the DNS crap in the TLS world
??? - pre-routing stuff is part of routing info
    routing does not appear to be in the proposal - how to you get securely to
    the right virtual server.
brian - where is the consensus

      - should not abandon SNI
      - problem should not require SNI for all 1.3 (YES)
      ---- room pushes back
      - allow encrypted SNI for all who wants it  (YES)
      - require support for encrypted SNI  <server, client> - (NO)
      - allow many round trip encrypted SNI - (??)
      - propose a DNS mech for keys - (??)
      - Support all three of the pictures from Erik's pictures (YES)
         * single name
         * virtual host
         * multiplex router

if join 5 and 6 then needs to deal with complexity

MSTJ - appears to believe that there is a difference between one and two routes
for the pictures

Early adopters - would do 2 RRT for things
MSTJ - is there a caching requirement?
EKR - if out of band mechanism then
May be able to do clear cache on failure rather than TTL
Worry about long term caching may lead to tracking attack - ala beast?
Stored state on the client leaks info about the client

=== Sense of the room ===

1. KEEP SNI - unanimous
7. Keep all 3 SNI modes for 1.3 - YES
** prolonged argument if the middle box is allowed to do crypt or if it must
rout based solely on bit-string match
   * existing topologies
   * only an issue for looking at servers on the same site.
   *
   ekr - browser would do it if saw that it was there and not if not.
2. Require any SNI for TLS 1.3 if start w/ DNS address
   moving the bar forward to get SNI there.
   Consensus - Yes * (needs to have word smithing for MUST/SHOULD wording)
3. Allow encrypted SNI -
   - go to 2 RT if the client has no information about server
   large argument about the fact that SNI needs to be known to route in order
   to do the item - first argument is on the SNI vs client hello
   * Consensus - seems to be Yes but lots of questions about how to do it.
4. Require support for encrypted SNI -
   * TLS modes that do not involve encrypted SNI will exist
   * Can either side force it and on what conditions
   * server can at best hint to the client
   * servers must support both ESNI (encrypted) and plan text SNI and should
   have an announce method to do it. * More useful for client to force server
   than reverse

Working on the whiteboard

Client       Load Balance      Virtual Host       Virtual Server
                MK (to dns)
  |--- {CH}mk---->|
                  |  ----- CH -------|----------------->|
  |<--------SH------------------------------------------|

  |------ UH?---->|
  |<---- MK_pub---|

Only supports passive attacker - allows for MITM for this case

8. clear SNI must not get worse than it is today - YES
6. propose DNS mech - DEFER - see what happens

EKR - recap
  Will defer 4 and 5 until tomorrow

****** BREAK
**** Triple Handshake

Alfredo gives Fast review of the problem

questions:
        what type of extension
        do we do this?

ekr - question on buffering data until the hash is known
    - what is the hash
alfredo - 1.2 use the PRF - for older use the SHA1-MD5 pair
ekr - clients must buffer entire hello for all hashes which are used
wtc - finish message hand shake has worse properties than this
ekr - allows both the client and the server to object arbitrary amounts of data
into the key computation
    - client can add in random weird extensions to have arbitrary data
    - server is more restricted as it just has the server.random
MSJT - has proposal for changing out the functions
     - the current ones have not be analyzed for the way things are used
     - use the 801 KDF functions since they have been analyzed for this type of
     thing
alfredo - Is there a problem for using a smaller number of bytes for the input
to the master secret derivation function? MSJT - does not mix in a positional
value but does it recusively EKR - look for somebody to look at this question
EKR - why se the hash Wtc - because we are already computing H(handshakes) for
the finish message

Sean - will take an action item to get the two questions looked at.

ekr - what is the indicator>
    - use an extension makes more sense
    - do the same thing for 1.3 - should the indicator be echoed?
** from the list
   recommend prevention of resumption and re-negotiation
ekr - no mitigation for channel bindings - some for certificates - client and
auth ** - put in the correct security considerations for what happens if you
don't do it correctly. and what is broken.

Andy - should we make the exporter be at one level removed to deal with the
fact tht some labels are currently restricted.

JoeS - not to make too many changes unless they are within the scope of things
to be fixed

ekr - preference not to fix at this time

erik - question about DTLS is that a question
ekr - it is deterministic already - need to put into this draft

++ CONSENSUS SUMMARY -  In room to adopt the triple handshake fix pending
analysis of the exact construction by cryptographers. Need to solicit that
analysis by at least two people.

**** Client Puzzles

Discussion led by Erik Nygren

Need to do some modeling of how do the different offload methods compare -
     sleep vs puzzle vs throttling vs ?

Look at the cost effectiveness of the botnet for solving the problems vs
     other attacks it could be doing.

Easier to parlellize the wait problem than the client puzzle problem.

++ CONSENSUS SUMMARY  - no real consensus in the room for where to go from
here.  Questions on the value of puzzles versus other rate limiting schemes.

Day Two (16 May 2014, 9:00 am - 2:00 pm MDT)
==============================================

Revised agenda

30 min on padding
return to hand shake

A (Alfredo Pironti) - Padding issues

traffic analysis attacks based on size of message since no padding
stream ciphers are easy - right length
block ciphers - small fuzz but not much
random length padding - not useful if sending id multiple times as padding is
different each time - look at the shortest

propose change function to AEAD(K, AD, P) -->  AEAD(K, AD, P, TargetLength)

TargetLength is policy input from the application
Keep the code in TLS to keep multitude of different methods from appearing
Tradeoffs on bandwidth vs privacy is a function for the application

MSTJ - objecting to any additional bytes in the plain text

JoeS - would it make sense to make this at the context rather than on a send
api? A - Yes it would be cool
  Can hide length of certificate if already encrypting
  Fragments is referring to the TLS fragmentation size

? - What happens if stacked up TLS send records - these can be combined -
Discussion on flushing
A - Currently not helping even if you consolidate - does not change shaping
  - ok to send fragments that are pure paddings - to keep traffic shape
  consistent - HTTP browsers are being proactive about getting http links as
  soon as seen - leaks information about where the link is in the page - even
  w/padding - while good idea to have buffering of n packets - number of
  packets can be part of the size - but no-one would implement it.

EKR - allows for retrofit of current system with ability to have anonymity.

? - what data is to be put into the padding
A - mac is computed on the entire pad + plain text
  - in principle does not matter what the content is could be all zeros
Outside of TLS processing may still be variable based on the length of the data
        this may give a timing channel
Erik - if we look at crossing the pad boundary - if you can do the statistic
analysis to figure out when you are crossing the boundary - then can look at
things A - yes - if attacker can control some data - then it can get length DKG
- does this make it harder for an application to do it's own padding.

EKR - should it mandatory or optional?
    given possible attacks  from the other side + two bytes waste - may want to
    this to be optional

If looking at from a streaming - then will inject padding in the middle since
it is streaming If trying to make all files the same size then would need to
pad at the end needs to be application not TLS based

EKR - we are looking at consuming a large amount of bandwidth - 2 bytes per
records - last night we were talking about killing the version just to save the
two bytes - 2 bytes over tons of records is significant bandwidth

JoeH - would be happy with guidance on how to do this with various protocols -
?? - if in an extension - then could block if is clear
? - SSH changed to encrypt record length headers -
DTLS is leaking record boundaries - so encrypting headers there is waste?
SSH has possible attack based on the fact taht the length is encrypted
EKR - willing to do this as long as cheap
JoeH - started as excited - then went to make the app deal with it.
MSTJ - what about the handshake?
* - some agreement that we need this for the handshake
MSTJ- it is reasonable to have pad handshake but not application
JoeS - needs to be a simple mode for the application to set one parameter and
say go

Debates on when you want to do the interstitial record padding -
Apps sending small data blocks are going to be badder
Going to be a mess for applications to do the full analysis - if simple
parameter - then

Sean - want to ask two questions
1.  Do we want to do padding in TLS as an optional feature?
    * Don't want to necessarily specify API but might be good to give guidance
    * Does not complicate statement machine - two records types?
    * may not be padding all records - might be able to fool adversary into not
    knowing that you are padding on some things * EKR - want to see hard
    proposal if the question is just complexity. Andy, Alfredo - produce
    concrete proposal

2.  Should we do a BCP that gives application guidance on the goodness of
padding
    * Possibly punt this to UTA?

++ CONSENSUS SUMMARY  - general agreement to work on BCP, Alfredo to start. 
Follow up with concrete padding proposals

******* Encrypt SNI

EKR day 2 Slides

 Add back #0 - Encrypt SH always
 Add in #8 - Clear SNI available w/ no penalty

DKG - makes it harder to analyze if going into encrypted mode before finishing
    making it worse.
Andy - variants that don't require a signature
     - triple, double DH

Rich (rich Salz) - is there an issue with the fact that the client certificate
is not in master secret computation Discussion - if it is now from ordering -
Alex -needs to be in if unique is part of the cert EKR - this is basically
false start
    Could separate header keying material from data material
Andy - does the problem exist - because the better protocol make the problem go
away.
     * protect against attacks -
     * if use real DH group - may go away
* slide #3
    Add round trip w/ corrected group if the first hello is not for the server
* Slide #4
  Allow for encryption on client hello

Questions on consistency of the policy data between the two ServerHello messages
Not clear that they need to be the same, not clear that they need to be
consistent. Probably should not require the same for the load balancer case
This says that perhaps the first flight is not hashed in

**** DKG, Tom slides

does it makes sense to have the client send under policy

ekr - this appears to be the necessary complexity to support ESNI
    the fact that the best and worst case scenarios becoming much closer
    are pain?

Questions about what happens if no SNI for the L4 box -

Discussion of where the keys live
supporting existing topologies - where load balance needs some level of access
   * decrypt routing info in initial handshake.

DNS priming is wrong
    - hard failure/soft failure
    - initial hand shake -

If large gyrations to accommodate the fact that DNS data is wrong - EKR is not
willing to do this.

EKR - difference of design - not trying to make the first encipherment part of
the hello - similar to the previous day presentation

for the load balancer case - the balancer shoves the key into the maskSessonKey
slot and sends to back end server - the back end server then it can use the
bytes to do the decryption. Not protected data between the front end and the
back end

David Holmes - balancers can be outside of the centers and thus sending data
across the internet to send the data.  Also balancers currently have not crypto
certification requirements

JoeS - summary

Having an intermediate thing is a realistic deployment - if SNI gets common
enough

Cloud service providers - using the left hand side approach (L4 picture)
Do we support w/o DNS priming or in band
If don't care about ESNI - then guess group wrong is re-transmit of client
hello w/ different key - fewer states than ESNI case

DKG - thinks the cost is worth paying
EKR - no way tot do ESNI w/o priming w/o two DH exchanges
    ESNI in in band then 1) two DH exchanges 2) recognize it the same guy and
    use cached material

DNS primed case and inline has different PFS and active protection properties

If no ESNI - then do you have a DNS priming question -
   only for group

Should encrypt server extensions if client hello not encrypted - yes because of
ALPN selections

zero-rtt needs more DH exchanges to get PFS

Discussion of using a single SNI for a group of items and re-route based on the
HTTP headers to deal with the issue.  Does not work correctly for non HTTP
systems. Get the SNI from DNS -

Looking differences with the client and server implemention complexity -

Discussions on what the inputs to the hash function for key generation of the
master secret is going to be - in the case of primed vs non-primed and how to
prime the inputs would seem to be different.

poll of the room - very slight for no  but almost even

EKR - this argument is only on the in band version of the protocol.  ESNI will
always be able via DNS priming.

query - any problems with making it optional - both sides have to opt in -
      vast majority agrees
One person objecting as wants to reduce number of options.

MSTJ - maybe want to have an ID on privacy considerations for TLS.  This is not
something I want to write.

++ CONSENSUS SUMMARY -
1. Consensus to Keep SNI
2. General Consensus to Require any SNI for TLS 1.3 if start w/ DNS address
(wording and 2118 language needs work) 3. General Consensus to Allow encrypted
SNI (general support, not sure how yet) 4. partial support in room for
Requiring support for encrypted SNI 5. mixed response for multi RT ESNI. 6.
General consensus for DNS priming for ESNI 7. General support for supporting
ESNI in the case of load balancers and directors, but significant push back on
intruding 3rd party into TLS exchange

General consensus for the following modes:
- a 1-RTT no-SNI encryption mode
- a 1-RTT encrypted SNI mode with DNS priming requiring consent from both sides
(server or client can refuse) - a 2-RTT encrypted SNI mode without priming
requiring consent from both sides  (server or client can refuse)

***** Re-negotiation

Reasons to do it:
1) long session nonce
2) get  cert when you did not know it earlier
3) privacy protection on the cert

EKR - claims 3 is covered in the new protocol
  - tell client TLS handshake - app protocol can say re-connect w/ cert (Martin
  draft) -

Andy - should just get rid of the cert-request message as it is just not giving
useful info

Some clients use it to do some filtering, but still inadequate to get a good
selection.

EKR - could do the re-key w/o renegotiation - just  single to crank the PRF.

Poll Matt if need to re-confirm that the entities still hold the key at
re-negotiation time or can just re-key from history.

consensus call to keep re-negotiation -
          Majority  - any objections -
          would like to keep for the cert request
          want to get better filtering questions back as well as deferred.

ALL PEOPLE ACTION - Look for any protocol other than HTTP and w/o a way to get
re-connect to get ID information. (i.e something that delays client auth and
cannot just re-connect.)

++ CONSENSUS SUMMARY - general consensus to remove renegotiation in 1.3 pending
making sure it is not needed for things like client certificate authentication