Q. TLSのmaster secretがデフォルトの48バイトより長くなるの？96バイトぐらい？
A. 違います。
前提
この話が通じるのはTLS1.0～TLS1.2です。TLS1.3は含まれません。
本文
master_secretの算出方式が変わります。
普通のmaster_secretはClientHello.Random, ServerHello.Random, pre_master_secretの3値から算出しますが（拙稿 SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する をご参照ください）、extended master secret拡張が有効なときは、ハンドシェイクのClientHelloからClientKeyExchangeまでの平文パート全体をハッシュし、それとpre_master_secretを元にmaster_secretを算出します。
「平文パート全体」の範囲には、ClientHello.RandomとServerHello.Randomも含まれますので、要はmaster_secretの算出元データとして使われるパラメータの種類が増えるということです。
master_secretが算出されれば、その後のアルゴリズムは普通のTLSと変わりません。
この拡張は必要か？
これはTriple Handshake攻撃の脅威をどう評価するかの問題です。
Triple Handshake攻撃には複数のバリエーションがありますが、公式サイトで述べられている典型的な攻撃例は3段階から成り立っており、その最終段階 (step 3) をよく見ると、実は一部のTLS製品に当時存在していた不具合を突く形で行われているのです。不具合さえなければ、step 2までしか進めませんので、それならTriple Handshake攻撃は大きな脅威ではないと考えることもできます。
しかし将来的に、これを改良した応用的な攻撃法が発見されるかも知れないと考えるなら、やはりRFC7627 (Google翻訳) が必要とも考えられます。
そんなわけで、世の中RFC7627対応は意外と遅く、未対応のクライアントやサーバがまだまだ残っているようです。
この拡張はTriple Handshake対策になるのか？
かつてのCVE-2009-3555脆弱性を受けて、TLS再ネゴシエーションの補強策として登場したRFC5746 (Google翻訳) が、Triple Handshake攻撃にはさっぱり無力だったわけで、ではRFC7627は本当に大丈夫なのか気になるところですよね。
RFC7627は公式サイトの3段階のうち最初 (step 1) に作用し、別のセッションだがmaster_secretは同じ、という状態を作らせないというものです。ClientHello.Random, ServerHello.Random, pre_master_secretに加えてサーバ証明書もmaster_secret算出の元データに使われますので、攻撃サーバAが被害クライアントCに送るサーバ証明書と、被害サーバSが攻撃クライアントAに送るサーバ証明書が一致しなければ、master_secretは同じにならないと、まあそういった理屈です。
。。。どう思います？なんというか、Triple Handshake論文の攻撃シナリオには有効でも、誰かが何か別の応用を思いついたら、あっさり迂回されてしまうんじゃないかという予感がしなくもありませんが、まあ、その時はその時でまた何か考えればいいのでしょう。
リファレンス
E. Rescorla, et al. (2010)
Transport Layer Security (TLS) Renegotiation Indication Extension
https://tools.ietf.org/html/rfc5746 (Google翻訳)
K. Bhargavan, et al. (2015)
Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
https://tools.ietf.org/html/rfc7627 (Google翻訳)
Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS
https://mitls.org/pages/attacks/3SHAKE (Google翻訳)
SSL/TLS（SSL3.0～TLS1.2）のハンドシェイクを復習する
https://qiita.com/n-i-e/items/41673fd16d7bd1189a29