Re: [TLS] Minutes from Tuesday (Martin Rex) Tue, 21 October 2014 15:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2CB2F1A8740 for <>; Tue, 21 Oct 2014 08:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ic-7NbE1Cehl for <>; Tue, 21 Oct 2014 08:05:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89EC81A873F for <>; Tue, 21 Oct 2014 08:05:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 116B254D01; Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id E163A41728; Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
Received: by (Postfix, from userid 10159) id DA17C1AEFE; Tue, 21 Oct 2014 17:05:36 +0200 (CEST)
In-Reply-To: <>
To: "Salz, Rich" <>
Date: Tue, 21 Oct 2014 17:05:36 +0200
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Cc: " (" <>
Subject: Re: [TLS] Minutes from Tuesday
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Oct 2014 15:05:45 -0000

Salz, Rich wrote:
> Bodo slides are at   Based on list feedback, going to add some clarifications (no changes to the mechanism).  False start I-D needs to be updated since attacker can force a version; Bodo to do that. Discussion of distinguishing between TCP reset (in FF) and version intolerance. Discussion of when to 'guess' failure is transient or version intolerance. Need to add some guidance to the I-D: mixing SCSV and version-intolerant servers will cause a pain. Sean went through issues raised on mailing list.

The current fallback-scsv is embarrassing.

Rather than aborthing the TLS handshake, the server ought to include
a TLS extension in the ServerHello indicating that he recognized a
potentially inappropriate fallback and otherwise continue the TLS handshake
in the regular fashion, leaving the decision of whether&how to continue
entirely up to those clients who do perform insecure fallbacks.

This would also allow clients (browsers probably) to gather real data
on potentially incorrect fallbacks, rather than have users face random
connection failures.  Connection failures for singular object may
appear easy to identify, but if it affects only small objects within
complex pages, the underlying cause of problems may be hard to identify.

And it would then be a decision of the (fallback-performing) clients
whether and when to start hard-failing, once they've sorted out their
connection management and figured out how to deal with false positives
in their fallback heuristics.