Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

Mohamad Badra <mbadra@gmail.com> Wed, 25 September 2013 21:08 UTC

Return-Path: <mbadra@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3C21F8411 for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 14:08:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntT-NYbqGGrp for <tls@ietfa.amsl.com>; Wed, 25 Sep 2013 14:08:24 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B441621F9C05 for <tls@ietf.org>; Wed, 25 Sep 2013 14:08:04 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id pa12so227097veb.30 for <tls@ietf.org>; Wed, 25 Sep 2013 14:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UW6hIPTuZ0LTtgbyWArxybw3Vo49cZOTL1fZOLOzZwA=; b=iPrUeCDoVjVx1sXRkyWMtnKFsX4dcCbrqXZxzYub60TpNfjsFYiZK8zC5tk1pQFKpu C69J4kZbY2mnDcmy2DaskUHczKk+24wqyblqhQ3GTwJHaXXPT8mRR/ozMp5TdCjOSBII RHaXjjIo5Hwq4lmtCzcYPxsoTKVYnVGtWFXPdMwS85ULRMPLc8HGESmb+hJXGPBRE57I Fwsh+Cgudhe4tSW022xBxNS/RA9g4LX62Gm8ntXZV/BOedqoyZvoUPK+ovG5EwVL2GS8 JZopWIQrL4xSOqQxLEVZySz/iS6zf8P+8lQLtejdkUe8oJ1DOseedLa+LtcNTwZa5e4G nkNw==
MIME-Version: 1.0
X-Received: by 10.220.237.208 with SMTP id kp16mr34844599vcb.4.1380143283879; Wed, 25 Sep 2013 14:08:03 -0700 (PDT)
Received: by 10.221.43.138 with HTTP; Wed, 25 Sep 2013 14:08:03 -0700 (PDT)
In-Reply-To: <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
References: <CADMpkc+3ifDbnSxp9jiiPAKDPxaCWpkKHXTfgygpN3kOXMUFFQ@mail.gmail.com> <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
Date: Thu, 26 Sep 2013 01:08:03 +0400
Message-ID: <CAOhHAXxo3s6bPEj+sUqVrVd+2MUwqgaVd9CRgdZOVi31RHXXNA@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Sep 2013 21:08:25 -0000

On Thu, Sep 26, 2013 at 12:54 AM, Martin Rex <mrex@sap.com> wrote:
> Bodo Moeller wrote:
>> > Instead of particular versions, it seems to me that an indicator of "I
>> >> tried to connect using a higher version than I'm using now but had to
>> >> fall back to this verion" would cover any case now or later.
>> >>
>> >
>> > Indeed that's what I ended up writing down for an Internet Draft.
>> >
>>
>> Now here:
>>
>> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
>
> OH NO, not again!!
>
> Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.
>
> Fatal SSL alerts in particular, are worst of all, because they do often
> do not give any clue, are not ever sent by a number of TLS implementations
> (you just see the connection close/reset), and are hardly/poorly visualized
> or not even accessible on many TLS clients.
>
> If anything, then such a "downgrade protection discovery" signaling
> cihper suites should cause the server to respond with a ServerHelloExtension
> listing the features that the server supports and would be capable
> of processing properly when present in ClientHello, and leave the
> decision, whether to abort the handshake and whether to tell or ask
> the user about any perceived problems first, entirely up to the client.
>
>
> -Martin

[reference] http://www.ietf.org/mail-archive/web/tls/current/msg08892.html