1.2で暗号路の鍵を更新する場合は、ハンドシェイクをやり直す(再ネゴシエーションする)必要があった。実装の視点からいうと、鍵更新はハンドシェイクに対して同期的だった訳だ。1.3では、サーバやクライアントがハンドシェイクをし直すことなく、いつでも鍵を更新できる。再ネゴシエーションはない。)つまり、鍵更新はハンドシェイクに対して非同期的になった。プログラマーにとっては、腕が試されることになる。1.3の鍵更新メッセージの書式は、以下のように定義されている。KeyUpdate;典型的な使い方はこうだ:AがKeyUpdate(update_requested)を送り、送信側の鍵を更新BはKeyUpdate(update_requested)を受け取ったら受信側の鍵を更新し、KeyUpdate(update_not_requested)を送り、送信側の鍵を更新AがKeyUpdate(update_not_requested)を受け取ったら、受信側の鍵を更新AとBが同時にKeyUpdate(update_requested)を送ってもよく、その場合、単に2回鍵が更新された状態に落ち着く。応答だと解釈していた。受け取ると、エラーにしていた。さんから、一方向の更新も許されるのではないかと指摘を受けた。1.3の実装者が集まるチャンネルに話題を振ったところ許されていない:無視すべき許されていない:エラーにすべき許されているの3つの解釈が出てきて、やはり仕様が曖昧だと分かった。さんが降臨し、「許されている」と言って決着した。2016の25日目の記事です。2016の24日目の記事です。2016の13日目の記事です。山本和彦id:kazu-yamamoto子育て真っ最中のHaskeller。Haskell月別アーカイブはてなブログをはじめよう!kazu-yamamotoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。