From dharkins@lounge.org  Fri Nov  1 12:00:59 2013
Return-Path: <dharkins@lounge.org>
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 1969C21E8547 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 12:00:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.965
X-Spam-Level: 
X-Spam-Status: No, score=-4.965 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 U4UT2DqzVeUY for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 12:00:53 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E2C8021E8279 for <tls@ietf.org>; Fri,  1 Nov 2013 12:00:53 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DF90D10224008; Fri,  1 Nov 2013 12:00:52 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Nov 2013 12:00:53 -0700 (PDT)
Message-ID: <7790984d7cbbba7ed78e84a6ff9253f0.squirrel@www.trepanning.net>
In-Reply-To: <20131031230955.GB32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com>
Date: Fri, 1 Nov 2013 12:00:53 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Nico Williams" <nico@cryptonector.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 19:00:59 -0000

On Thu, October 31, 2013 4:09 pm, Nico Williams wrote:
[snip]
>  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
>    should be sent when needed, if needed.  For example, to derive a
>    session key from an DHE shared secret one does not really need
>    nonces.  This means that counter modes are better, for example, than
>    CBC modes.
>
>    <aside>
>
>    Perry Metzger recently proposed (I'm extrapolating a bit) a
>    random-IV-free CBC-like cipher mode where instead of a nonce one
>    sends a [small] counter which must be encryted to recover the IV
>    for use as the first block in the CBC decryption of the ciphertext.
>    I kinda like this.
>
>    CBC has some advantages over counter modes.  However, for this
>    particular application (TLS and DTLS) it's easy enough to avoid (and
>    detect) counter reuse that counter modes' disadvantages are
>    tolerable.
>
>    </aside>

  In the interest of lessening nonce and IV bytes, especially ones that
are security-critical there is always SIV mode (RFC 5297). That provides
authenticated encryption and only expands the packet by the number of
bits equal to the blocksize of the underlying cipher. You can add a
nonce as additional AAD but it's not necessary and security isn't voided
if such a nonce/counter gets reused. You get a mode that is less fragile,
and doesn't expand the frame as much, at the cost of two passes of the
data.

  I'm not sure about Perry's proposed mode, and I'd be interested in
reading more about it, but SIV has a security proof in the paper by
Rogaway and Shrimpton that defined SIV.

  regards,

  Dan.



From n.mavrogiannopoulos@gmail.com  Fri Nov  1 12:09:43 2013
Return-Path: <n.mavrogiannopoulos@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 4436811E811D for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 12:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 eaOcZvSJ2ZAZ for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 12:09:42 -0700 (PDT)
Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 61C5311E80DE for <tls@ietf.org>; Fri,  1 Nov 2013 12:09:42 -0700 (PDT)
Received: by mail-ee0-f51.google.com with SMTP id d41so2144078eek.24 for <tls@ietf.org>; Fri, 01 Nov 2013 12:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=mEBpZprfE7m5TRbKLqm0hvikprsjQlYuRAq+Nn6gaS0=; b=F6cv3lOkCkiBuOzivuirHeUephts/Ku7YrCNj8am0rJMuc9ypEIjALkjm+kdO0k8a/ RZmEMeTVnJ8RzBAqXt2grOPPXf3uNLVs7D/zGO9n6ROuEuNpTvSkSsP9wPf3LoYoA0m4 0vroHna1dBS3nkOlvsjHIzrQ9nsZ0TcY/pDcrxDWvuTMjTjqJAXQJvoZeX7yclHfo/Ne xvbi7HPGVRv/axdcHLrqjmJ/vGfr63IpZmZgqoIcID+YXF+WOkZauQ4FtQ8HsnfhdK9P bq3f5hkDVOxz3nEiQGrvnhPcamCBtdZX3CSryzYY5YgtLj0AGYVVtM5sZiumXiFCJGHh vfiQ==
X-Received: by 10.14.246.11 with SMTP id p11mr4677366eer.9.1383332981605; Fri, 01 Nov 2013 12:09:41 -0700 (PDT)
Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id a6sm11124766eei.10.2013.11.01.12.09.40 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 12:09:41 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5273FC73.8010303@gnutls.org>
Date: Fri, 01 Nov 2013 20:09:39 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com>
In-Reply-To: <20131031230955.GB32733@gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 19:09:43 -0000

On 11/01/2013 12:09 AM, Nico Williams wrote:
> 
> My list:
> 
>  - It should be deployable, that's first; in particular, it needs to be
>    deployable with ECDH PFS key exchanges.

(unrelated) It would actually be nice to have a wiki for anyone to add
his wish list there.


>  - Renegotiation should be replaced with an NPN-like extension that
>    provides privacy to the TLS client principal name.

I don't think anyone can avoid renegotiation. Since the TLS packet
counters are 64-bit (and more importantly in DTLS 48-bits), one cannot
avoid renegotiation to reset the counters.

(nevertheless, all the practical VPNs I've seen using TLS, don't use
renegotiation, they just re-establish the session).

regards,
Nikos


From rransom.8774@gmail.com  Fri Nov  1 14:21:36 2013
Return-Path: <rransom.8774@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 DB3D111E8160 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:21:36 -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 XQQiFb+ndeBN for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:21:36 -0700 (PDT)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0199111E8155 for <tls@ietf.org>; Fri,  1 Nov 2013 14:21:35 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id ii20so903931qab.17 for <tls@ietf.org>; Fri, 01 Nov 2013 14:21:35 -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=p6/qHxinojm/fOp4dbBvz3i1ANh4Yiq4Ui+TlxZ3JqQ=; b=Cgbos4mOCCoN+VsNMWjC75L6bR8U/9Ccl73+LleQBkWT3DiWI/vCf7GbniLV5FsWTa usznC00S8SdWDDFGDsX8DqkumMW5cpw0UpCTPf2TIrG0oO/RM34wrzib2grvU72Mm/pT GyFX9M9JCXWs05mixK7w7E6bRIXbXB7bn37ICGyGIct3azoRsBwcIEX2rp+KTibBUUkr v2GPjVNmtraQw5+GeP0axG5C51YehQw2n3Yr59c3n0u7F7pr5zSZnl/PhTomJm374+xq NPae+0vnkVkULrHIwg60GaVEz6S5JbK7LWdPQsEdRAmbS7Ec3S96Uvw+FuB7r1/tTGdT Dj/A==
MIME-Version: 1.0
X-Received: by 10.49.61.9 with SMTP id l9mr6750863qer.64.1383340895474; Fri, 01 Nov 2013 14:21:35 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 14:21:35 -0700 (PDT)
In-Reply-To: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com>
Date: Fri, 1 Nov 2013 14:21:35 -0700
Message-ID: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 21:21:37 -0000

On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:

> TLS 1.3 should significantly reduce the number of round trips
> required. To this end I propose the following obviously secure scheme:
> the client sends a point on a curve in ClientHello and the server
> responds with certificates (or some other authentication thing) and a
> point on a curve, so that when the client speaks again, it is with a
> negotiated, authenticated shared secret. Before everyone screams about
> needing one signature per connection, note the server can use a time
> based secret key, so only has to do one exponentiation per client.

This protocol should be designed to allow future extension to use
post-quantum encryption and/or key encapsulation cryptosystems.  (I
don't believe that quantum computers will become a threat, but some PQ
cryptosystems may be faster than ECDH.)

It also needs to either allow session resumption without the
possibility of reusing any key used to encrypt or authenticate
application-level data, or explicitly forbid session resumption.


> Renegotiation should be killed: it serves no purpose.

Renegotiation is a critical feature of TLS, which serves multiple purposes.

* Renegotiation allows rekeying of a session.  This is absolutely
required for any ciphersuite based on a block cipher with a 128-bit or
smaller block, because block cipher modes' security properties degrade
after they are used for more than some number of blocks.

* Applications can also use renegotiation-based rekeying to improve
forward secrecy; for example, the Mixminion specification
(<https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt>,
section 4, line 1040) requires that relay-to-relay TLS connections be
rekeyed using renegotiation every 15 minutes for this purpose.

* A TLS connection can be established by a fully trusted device which
knows a password or other application-layer authorization credential,
authorized to perform some operations using messages within the TLS
connection, and then transferred with the help of renegotiation to a
less trusted device to actually perform those operations.  This is
similar to the preceding use, but to provide 'sideways secrecy' rather
than forward secrecy.

* One version of the Tor 'link protocol' (Tor's term for its outer
TLS-based connection protocol) uses renegotiation to provide secrecy
for the server's certification chain against purely passive attackers.
 The purposes above could be served by applying a one-way function to
the originally derived key material, then discarding the old keys;
this purpose cannot.


Robert Ransom

From nico@cryptonector.com  Fri Nov  1 14:28:50 2013
Return-Path: <nico@cryptonector.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 E5A5011E8184 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level: 
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.283,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 ZVtl1BG-s2MZ for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:28:46 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70311E8166 for <tls@ietf.org>; Fri,  1 Nov 2013 14:28:42 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 0BAAC43806C; Fri,  1 Nov 2013 14:28:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=WUP68dzBS8tCIT UTW07DjuOVMk4=; b=hc75WMOuZ6rt+19u2FStao7GQtG8MZM4z9LRtBr9uXjYlg qKJCvGbo6OUipoudSZNqzVFnWOzdbXA8YBgua+hbX/K80FM8UHYybzitQSTsiSIA sCNIjieEmwC0cE6+ZH6Lra90UU8kqDbmoeY8J9ApJyAhTmZgUrr3QWJQundqY=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 93D2543801C;  Fri,  1 Nov 2013 14:28:40 -0700 (PDT)
Date: Fri, 1 Nov 2013 16:28:37 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robert Ransom <rransom.8774@gmail.com>
Message-ID: <20131101212834.GE32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 21:28:51 -0000

On Fri, Nov 01, 2013 at 02:21:35PM -0700, Robert Ransom wrote:
> On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:
> It also needs to either allow session resumption without the
> possibility of reusing any key used to encrypt or authenticate
> application-level data, or explicitly forbid session resumption.

Sure.

> > Renegotiation should be killed: it serves no purpose.
> 
> Renegotiation is a critical feature of TLS, which serves multiple purposes.
> 
> * Renegotiation allows rekeying of a session.  This is absolutely
> required for any ciphersuite based on a block cipher with a 128-bit or
> smaller block, because block cipher modes' security properties degrade
> after they are used for more than some number of blocks.

This can be done without a synchronous renegotiation by just computing a
new sessionkey every so many bytes/blocks/records (whatever's
appropriate to count for the cipher in use).

> * Applications can also use renegotiation-based rekeying to improve
> forward secrecy; for example, the Mixminion specification
> (<https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt>,
> section 4, line 1040) requires that relay-to-relay TLS connections be
> rekeyed using renegotiation every 15 minutes for this purpose.

Indeed.  Speaking of which, resumption must support PFS rekeying.

> * A TLS connection can be established by a fully trusted device which
> knows a password or other application-layer authorization credential,
> authorized to perform some operations using messages within the TLS
> connection, and then transferred with the help of renegotiation to a
> less trusted device to actually perform those operations.  This is
> similar to the preceding use, but to provide 'sideways secrecy' rather
> than forward secrecy.

As long as there's no MITM...

> * One version of the Tor 'link protocol' (Tor's term for its outer
> TLS-based connection protocol) uses renegotiation to provide secrecy
> for the server's certification chain against purely passive attackers.
>  The purposes above could be served by applying a one-way function to
> the originally derived key material, then discarding the old keys;
> this purpose cannot.

I thought this was no longer in use.

Also:

 * Privacy protection for the user's PSK ID and/or cert and/or other
   identifying data.

   But again, an NPN-style extension should take care of this.

 * Relatedly, the server can request user authentication asynchronously,
   in which case NPN-style extensions don't help.

   I'd be happy to get rid of this: user authentication in such cases
   belongs in the app layer.  However, it may not be feasible to get rid
   of such uses of renegotiation, so it probably has to stay :(

Nico
-- 

From rransom.8774@gmail.com  Fri Nov  1 14:34:49 2013
Return-Path: <rransom.8774@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 D371711E8160 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:34:49 -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 EvWyl8XavyXd for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:34:49 -0700 (PDT)
Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2D811E8143 for <tls@ietf.org>; Fri,  1 Nov 2013 14:34:49 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id hu16so8343qab.18 for <tls@ietf.org>; Fri, 01 Nov 2013 14:34:48 -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=GJgNtNyzVIsV/QHenQHVzCrgWX4D/GzYK7Z0EWeaJDg=; b=v6/7fWleLEUteygh+iVR/UQYAmm2MN9VUzWotg2xeN3ZVDLH6YQrjoDPDRN9z/3veM i28w40mpSwA9vRJaTvhBblusAvWDkSe5DX7Rwywi6YrkMyi5/rud1Xou769ku3uSQJk2 MNoKUjdtMJIdlZrLdZb97MEUlrVWowXrj7dkDT/EA5UZP63zNROE62pf1p0n5zPoIN6g 74sg5q8JUGktts4cS6n80RMcDJ8TJOOt8gTCgwywL0Vs8Ov5QfV15Z2TmFPMeE0Sqa1F zxHc34E3jvbtXp3Wgl2/J0k+A6+8HRo++4we9z3rbvYoiI6Z+hD5UXXTCNfbiUVKCMgS 4v4Q==
MIME-Version: 1.0
X-Received: by 10.229.106.131 with SMTP id x3mr6783455qco.1.1383341688709; Fri, 01 Nov 2013 14:34:48 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 14:34:48 -0700 (PDT)
In-Reply-To: <20131031230955.GB32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com>
Date: Fri, 1 Nov 2013 14:34:48 -0700
Message-ID: <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 21:34:49 -0000

On 10/31/13, Nico Williams <nico@cryptonector.com> wrote:

>  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
>    should be sent when needed, if needed.  For example, to derive a
>    session key from an DHE shared secret one does not really need
>    nonces.  This means that counter modes are better, for example, than
>    CBC modes.

If the server sends a nonce during a DHE/ECDHE key exchange, the
server can safely reuse its DH keypair for multiple clients with no
further design or implementation considerations.  If the server does
not send a nonce, it must keep a replay-detection cache of client DH
public keys for the lifetime of its DH keypair.


Robert Ransom

From rransom.8774@gmail.com  Fri Nov  1 14:37:11 2013
Return-Path: <rransom.8774@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 8F20F11E817E for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:37:11 -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 fY1YDKUcwwgt for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 14:37:11 -0700 (PDT)
Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0630B11E8166 for <tls@ietf.org>; Fri,  1 Nov 2013 14:37:10 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id i13so925509qae.2 for <tls@ietf.org>; Fri, 01 Nov 2013 14:37:10 -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=Izr6d7okiDLrRBulNtHRtvKe5dq3LxoyfUsyDahpAwc=; b=NRDG72+FdWlyD+uiIdDRjtfB98rumIdecruwSKbZJJ976AyuO17qU0Wcod3q4Ywb2E Ijw7QnalawYj7lwFGXX9s9Nj3KZgPDPD3zVRa33idGwUl8zUopfKjRrraOCd6vqYgXYc A+scoNy+51K0gdTOXD0K1/K6sqToHVEYhdymmg4dCaYRNR1GAjFmvHR4T7uLimfALGI2 oTpZKlL4Q7j+D2oIBoPy4MVWFULbneZXl40gZveRdj4xigNZ6S7flLTCNWGNGWhm3dXy RW8Y6TvktlzEbu/DK6dpE68kfmHL3i+8K7Yx67Qh9YG+by6xrfzySeAyFPCkXXR8JKEs kd/w==
MIME-Version: 1.0
X-Received: by 10.224.24.201 with SMTP id w9mr6789997qab.103.1383341830658; Fri, 01 Nov 2013 14:37:10 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 14:37:10 -0700 (PDT)
In-Reply-To: <20131101212834.GE32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <20131101212834.GE32733@gmail.com>
Date: Fri, 1 Nov 2013 14:37:10 -0700
Message-ID: <CABqy+spV1sBH4i7beZzhBnZA+0ePOaDVtvjP1ryPOZEseriRhg@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 21:37:11 -0000

On 11/1/13, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Nov 01, 2013 at 02:21:35PM -0700, Robert Ransom wrote:

>> * One version of the Tor 'link protocol' (Tor's term for its outer
>> TLS-based connection protocol) uses renegotiation to provide secrecy
>> for the server's certification chain against purely passive attackers.
>>  The purposes above could be served by applying a one-way function to
>> the originally derived key material, then discarding the old keys;
>> this purpose cannot.
>
> I thought this was no longer in use.

They're trying to get rid of that protocol version.  I don't know
whether they have succeeded yet.


Robert Ransom

From dharkins@lounge.org  Fri Nov  1 15:38:11 2013
Return-Path: <dharkins@lounge.org>
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 F10D911E80E9 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 15:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.615
X-Spam-Level: 
X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 6B6H6wRRW7Yu for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 15:38:06 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF5F11E8136 for <tls@ietf.org>; Fri,  1 Nov 2013 15:38:06 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D377310224008; Fri,  1 Nov 2013 15:38:05 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Nov 2013 15:38:06 -0700 (PDT)
Message-ID: <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net>
In-Reply-To: <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com>
Date: Fri, 1 Nov 2013 15:38:06 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Robert Ransom" <rransom.8774@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 22:38:12 -0000

On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
> On 10/31/13, Nico Williams <nico@cryptonector.com> wrote:
>
>>  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
>>    should be sent when needed, if needed.  For example, to derive a
>>    session key from an DHE shared secret one does not really need
>>    nonces.  This means that counter modes are better, for example, than
>>    CBC modes.
>
> If the server sends a nonce during a DHE/ECDHE key exchange, the
> server can safely reuse its DH keypair for multiple clients with no
> further design or implementation considerations.

  I don't believe that's true. If the server reuses its ephemeral D-H key
then caveat emptor applies-- it should validate the client's public key,
regardless of whether a nonce is sent or not.

  Dan.




From watsonbladd@gmail.com  Fri Nov  1 15:40:27 2013
Return-Path: <watsonbladd@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 604BE11E80E9 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 15:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ztNHpK36RUBS for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 15:40:26 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E86E111E8110 for <tls@ietf.org>; Fri,  1 Nov 2013 15:40:25 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id x55so117371wes.8 for <tls@ietf.org>; Fri, 01 Nov 2013 15:40:25 -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=bOrdDq8Ki+Zly0FF3+5VBNlJQ6QqP/0nN/7iOSqoP/g=; b=qwwJCSOZ+UFo7jvOchRIwmwl1MDzZS/znJDReaJ2eUK+xqDX/RzLty4LHJFiQVD1Fg +5PE70GwAQnNxeUDR5RCh0eoPBzyelL9O8sM+0a/pGTyxlA2c2LpPkQbMu8sPiidNa9e NCeGxUzSSMbwdIFFEOCZTes7tkOVDsmOow792qAUrj6uMq2ICcnZeUH/VmChlUpnxZYe OYf6UZ1/c0/9ysPPGWyxbbgr0F/qrG+4ssCdB1J6Wkq2S35P12C/GShdi5vIuZrXU0b+ u9SvaYYx1o86vdZJPNDSjJWKAEa8DQIqF8j970Hol3bh9ef6gffbO/B4ThIOzVQa+c58 aOnA==
MIME-Version: 1.0
X-Received: by 10.194.239.40 with SMTP id vp8mr4112322wjc.45.1383345625231; Fri, 01 Nov 2013 15:40:25 -0700 (PDT)
Received: by 10.194.242.131 with HTTP; Fri, 1 Nov 2013 15:40:25 -0700 (PDT)
Received: by 10.194.242.131 with HTTP; Fri, 1 Nov 2013 15:40:25 -0700 (PDT)
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
Date: Fri, 1 Nov 2013 15:40:25 -0700
Message-ID: <CACsn0ck94Gmyr3d6BsaM-Mwf4Qh6zFRv1qAS3bkitrFkFwVOFw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "rransom. 8774" <rransom.8774@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c1b45297f82d04ea2540bc
Cc: tls@ietf.org
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 22:40:27 -0000

--001a11c1b45297f82d04ea2540bc
Content-Type: text/plain; charset=UTF-8

On Nov 1, 2013 2:21 PM, "Robert Ransom" <rransom.8774@gmail.com> wrote:
>
> On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:
>
> > TLS 1.3 should significantly reduce the number of round trips
> > required. To this end I propose the following obviously secure scheme:
> > the client sends a point on a curve in ClientHello and the server
> > responds with certificates (or some other authentication thing) and a
> > point on a curve, so that when the client speaks again, it is with a
> > negotiated, authenticated shared secret. Before everyone screams about
> > needing one signature per connection, note the server can use a time
> > based secret key, so only has to do one exponentiation per client.
>
> This protocol should be designed to allow future extension to use
> post-quantum encryption and/or key encapsulation cryptosystems.  (I
> don't believe that quantum computers will become a threat, but some PQ
> cryptosystems may be faster than ECDH.)
>
The PQ transition involves reworking the PKI as well. We also don't know if
NTRU or something else will win. A proffered version byte to avoid
downgrades could work, but I would not want to commit to the future.
> It also needs to either allow session resumption without the
> possibility of reusing any key used to encrypt or authenticate
> application-level data, or explicitly forbid session resumption.
>
>
> > Renegotiation should be killed: it serves no purpose.
>
> Renegotiation is a critical feature of TLS, which serves multiple
purposes.
>
> * Renegotiation allows rekeying of a session.  This is absolutely
> required for any ciphersuite based on a block cipher with a 128-bit or
> smaller block, because block cipher modes' security properties degrade
> after they are used for more than some number of blocks.
After one zettabyte according to a simple calculation.
>
> * Applications can also use renegotiation-based rekeying to improve
> forward secrecy; for example, the Mixminion specification
> (<
https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
>,
> section 4, line 1040) requires that relay-to-relay TLS connections be
> rekeyed using renegotiation every 15 minutes for this purpose.
If reconnecting is cheap enough that works. Designers need to deal with
connection death anyway.
>
> * A TLS connection can be established by a fully trusted device which
> knows a password or other application-layer authorization credential,
> authorized to perform some operations using messages within the TLS
> connection, and then transferred with the help of renegotiation to a
> less trusted device to actually perform those operations.  This is
> similar to the preceding use, but to provide 'sideways secrecy' rather
> than forward secrecy.
What does renegotiation get here?
The untrusted device can do everything unless it is being monitored by a
trusted device.
>
> * One version of the Tor 'link protocol' (Tor's term for its outer
> TLS-based connection protocol) uses renegotiation to provide secrecy
> for the server's certification chain against purely passive attackers.
>  The purposes above could be served by applying a one-way function to
> the originally derived key material, then discarding the old keys;
> this purpose cannot.
TOR could send a temporary outer signature and an inner proof. I agree this
is a weakness, but CurveCP like mechanisms only work thanks to some known
key.
>
>
> Robert Ransom

--001a11c1b45297f82d04ea2540bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On Nov 1, 2013 2:21 PM, &quot;Robert Ransom&quot; &lt;<a href=3D"mailto:rra=
nsom.8774@gmail.com">rransom.8774@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 10/31/13, Watson Ladd &lt;<a href=3D"mailto:watsonbladd@gmail.com">=
watsonbladd@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; TLS 1.3 should significantly reduce the number of round trips<br>
&gt; &gt; required. To this end I propose the following obviously secure sc=
heme:<br>
&gt; &gt; the client sends a point on a curve in ClientHello and the server=
<br>
&gt; &gt; responds with certificates (or some other authentication thing) a=
nd a<br>
&gt; &gt; point on a curve, so that when the client speaks again, it is wit=
h a<br>
&gt; &gt; negotiated, authenticated shared secret. Before everyone screams =
about<br>
&gt; &gt; needing one signature per connection, note the server can use a t=
ime<br>
&gt; &gt; based secret key, so only has to do one exponentiation per client=
.<br>
&gt;<br>
&gt; This protocol should be designed to allow future extension to use<br>
&gt; post-quantum encryption and/or key encapsulation cryptosystems. =C2=A0=
(I<br>
&gt; don&#39;t believe that quantum computers will become a threat, but som=
e PQ<br>
&gt; cryptosystems may be faster than ECDH.)<br>
&gt;<br>
The PQ transition involves reworking the PKI as well. We also don&#39;t kno=
w if NTRU or something else will win. A proffered version byte to avoid dow=
ngrades could work, but I would not want to commit to the future.<br>
&gt; It also needs to either allow session resumption without the<br>
&gt; possibility of reusing any key used to encrypt or authenticate<br>
&gt; application-level data, or explicitly forbid session resumption.<br>
&gt;<br>
&gt;<br>
&gt; &gt; Renegotiation should be killed: it serves no purpose.<br>
&gt;<br>
&gt; Renegotiation is a critical feature of TLS, which serves multiple purp=
oses.<br>
&gt;<br>
&gt; * Renegotiation allows rekeying of a session. =C2=A0This is absolutely=
<br>
&gt; required for any ciphersuite based on a block cipher with a 128-bit or=
<br>
&gt; smaller block, because block cipher modes&#39; security properties deg=
rade<br>
&gt; after they are used for more than some number of blocks.<br>
After one zettabyte according to a simple calculation.<br>
&gt;<br>
&gt; * Applications can also use renegotiation-based rekeying to improve<br=
>
&gt; forward secrecy; for example, the Mixminion specification<br>
&gt; (&lt;<a href=3D"https://github.com/nmathewson/mixminion-doc/blob/a6612=
12831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt">https://github.co=
m/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/sp=
ec/minion-spec.txt</a>&gt;,<br>

&gt; section 4, line 1040) requires that relay-to-relay TLS connections be<=
br>
&gt; rekeyed using renegotiation every 15 minutes for this purpose.<br>
If reconnecting is cheap enough that works. Designers need to deal with con=
nection death anyway.<br>
&gt;<br>
&gt; * A TLS connection can be established by a fully trusted device which<=
br>
&gt; knows a password or other application-layer authorization credential,<=
br>
&gt; authorized to perform some operations using messages within the TLS<br=
>
&gt; connection, and then transferred with the help of renegotiation to a<b=
r>
&gt; less trusted device to actually perform those operations. =C2=A0This i=
s<br>
&gt; similar to the preceding use, but to provide &#39;sideways secrecy&#39=
; rather<br>
&gt; than forward secrecy.<br>
What does renegotiation get here?<br>
The untrusted device can do everything unless it is being monitored by a tr=
usted device.<br>
&gt;<br>
&gt; * One version of the Tor &#39;link protocol&#39; (Tor&#39;s term for i=
ts outer<br>
&gt; TLS-based connection protocol) uses renegotiation to provide secrecy<b=
r>
&gt; for the server&#39;s certification chain against purely passive attack=
ers.<br>
&gt; =C2=A0The purposes above could be served by applying a one-way functio=
n to<br>
&gt; the originally derived key material, then discarding the old keys;<br>
&gt; this purpose cannot.<br>
TOR could send a temporary outer signature and an inner proof. I agree this=
 is a weakness, but CurveCP like mechanisms only work thanks to some known =
key.<br>
&gt;<br>
&gt;<br>
&gt; Robert Ransom<br>
</p>

--001a11c1b45297f82d04ea2540bc--

From nico@cryptonector.com  Fri Nov  1 16:13:56 2013
Return-Path: <nico@cryptonector.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 9499611E80E9 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.239
X-Spam-Level: 
X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 DkeElPxuaD4J for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:13:51 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0790C11E8136 for <tls@ietf.org>; Fri,  1 Nov 2013 16:13:48 -0700 (PDT)
Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 32DF32005D107; Fri,  1 Nov 2013 16:13:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zx9B0raeZ9ITgJ VlaTMx8FK1ThI=; b=DFBhfb1lJ9XPNlohkRwsxUUDM8C8E3xUZwasF2rn5Y9u8f VKwVrZj3sS0ElxJ9XXpC9v8RB7AS4rhsH32oPOQES2CpdugY7X0PY3NPr6Be9Kpj vZfBZ5wNYhRVx997IrfOYuIXHa1DyzUbZH9wTmp/6cVQGCbzNPyyLXRmjjQ4E=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id C1DD02005D109; Fri,  1 Nov 2013 16:13:47 -0700 (PDT)
Date: Fri, 1 Nov 2013 18:13:45 -0500
From: Nico Williams <nico@cryptonector.com>
To: Dan Harkins <dharkins@lounge.org>
Message-ID: <20131101231342.GG32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 23:13:56 -0000

On Fri, Nov 01, 2013 at 03:38:06PM -0700, Dan Harkins wrote:
> On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
> > On 10/31/13, Nico Williams <nico@cryptonector.com> wrote:
> >
> >>  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
> >>    should be sent when needed, if needed.  For example, to derive a
> >>    session key from an DHE shared secret one does not really need
> >>    nonces.  This means that counter modes are better, for example, than
> >>    CBC modes.
> >
> > If the server sends a nonce during a DHE/ECDHE key exchange, the
> > server can safely reuse its DH keypair for multiple clients with no
> > further design or implementation considerations.
> 
>   I don't believe that's true. If the server reuses its ephemeral D-H key
> then caveat emptor applies-- it should validate the client's public key,

Agreed.  A small nonce should suffice for key derivation if either party
reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
nearly as large as 32 bytes, i.e., not enough to suffice for a
Dual_EC-type backdoored RNG attack".  The party reusing a key should
send some such small nonce, possibly a 64-bit nonce.  In any case, the
client ought not be reusing ephemeral DH keys, and any server that does
should be rotating them often (like SSHv1 used to).

> regardless of whether a nonce is sent or not.

For some curves there's no need to validate the client's public key.

Nico
-- 

From rransom.8774@gmail.com  Fri Nov  1 16:34:25 2013
Return-Path: <rransom.8774@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 5D82411E8136 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:34:25 -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 OeUFOxr+-tzs for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:34:24 -0700 (PDT)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC8C11E817B for <tls@ietf.org>; Fri,  1 Nov 2013 16:34:24 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id n9so2884061qcw.1 for <tls@ietf.org>; Fri, 01 Nov 2013 16:34:24 -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=hSTJg9WCOg2/bYvSCfvfP71jDjJdp9R8qwfGzDSpyOw=; b=0VQAptepn3NAJYDPN41NwwyxJAIRyhaoMMUK7XDhMc7U43NW+jxON2HIhP3CjAbWo1 whiqNW3cg6UgdqaU8ma5qFx/uMx08OxZ+zjCaBk3z2Wa9WggNFGfA5oHoT7bUJGSQeDB YXcyLoubWeJIYpH2+dP8nTc33w1mxDCmfo0EjqXbQkU0vV0dVu9JjfdBa/8HN4Pcaixg 2I63YyAvSaO+V8kCtBrRHDco7p/tTPvYjSvEO/EhaXXb+NKuJefo1EemJTB5fN++/no8 2SnLiNbPHH9TDlRGMBppykmoL0HJ1jgKQS8rQYO/IQscrnJ+qSnPXug2+aV+MmWGsolQ rfSw==
MIME-Version: 1.0
X-Received: by 10.49.24.202 with SMTP id w10mr7361625qef.12.1383348864147; Fri, 01 Nov 2013 16:34:24 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 16:34:24 -0700 (PDT)
In-Reply-To: <20131101231342.GG32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com>
Date: Fri, 1 Nov 2013 16:34:24 -0700
Message-ID: <CABqy+sq=qdy1AH6CbHi55y--5svdc5A=upE0zsLsd2c4jZyH4g@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 23:34:25 -0000

On 11/1/13, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Nov 01, 2013 at 03:38:06PM -0700, Dan Harkins wrote:
>> On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
>> > On 10/31/13, Nico Williams <nico@cryptonector.com> wrote:
>> >
>> >>  - Many fewer nonce bytes and random IVs where possible.  Nonce
>> >> payloads
>> >>    should be sent when needed, if needed.  For example, to derive a
>> >>    session key from an DHE shared secret one does not really need
>> >>    nonces.  This means that counter modes are better, for example,
>> >> than
>> >>    CBC modes.
>> >
>> > If the server sends a nonce during a DHE/ECDHE key exchange, the
>> > server can safely reuse its DH keypair for multiple clients with no
>> > further design or implementation considerations.
>>
>>   I don't believe that's true. If the server reuses its ephemeral D-H key
>> then caveat emptor applies-- it should validate the client's public key,
>
> Agreed.  A small nonce should suffice for key derivation if either party
> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
> nearly as large as 32 bytes, i.e., not enough to suffice for a
> Dual_EC-type backdoored RNG attack".  The party reusing a key should
> send some such small nonce, possibly a 64-bit nonce.  In any case, the
> client ought not be reusing ephemeral DH keys, and any server that does
> should be rotating them often (like SSHv1 used to).

The server should be allowed to send up to 32 bytes of nonce.  Some
servers will want to conceal the lifetime of their keypair by
generating nonces using a counter encrypted or hashed with a secret,
using the cheapest encryption or hash function available; this may be
TEA, AES, SHA-256, or something else, depending on the hardware.  Some
servers will want to use a fast RNG to generate nonces.  32 bytes
should be enough to prevent even a random (or hash-derived) nonce from
repeating; anything less than that may not be enough for some servers.


Robert Ransom

From nico@cryptonector.com  Fri Nov  1 16:40:39 2013
Return-Path: <nico@cryptonector.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 D557E11E817D for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.543,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6]
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 oUw0HgavDRdp for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:40:35 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id EBCAE11E8136 for <tls@ietf.org>; Fri,  1 Nov 2013 16:40:34 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 5FE432005D105; Fri,  1 Nov 2013 16:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=m9Ot+IpRn81TFz BJzNlSes5S/As=; b=AdE/8rqiTVW6IQ4FjL3kk/8X0iXZuPHs4UeFkroEZSHccB wKK305iOk66tnLyP8npruNvuafZoXu09oiMEitCyZRQ50a5YAwWdVz5N8WZeAK0W C3OWYtcLzar+THyv75L/XmjPKtkxxkmwfIRUhosTGK4Ub56NEDG6cop972Y3w=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 043A62005D104; Fri,  1 Nov 2013 16:40:33 -0700 (PDT)
Date: Fri, 1 Nov 2013 18:40:31 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robert Ransom <rransom.8774@gmail.com>
Message-ID: <20131101234028.GH32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <CABqy+sq=qdy1AH6CbHi55y--5svdc5A=upE0zsLsd2c4jZyH4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABqy+sq=qdy1AH6CbHi55y--5svdc5A=upE0zsLsd2c4jZyH4g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 23:40:40 -0000

On Fri, Nov 01, 2013 at 04:34:24PM -0700, Robert Ransom wrote:
> The server should be allowed to send up to 32 bytes of nonce.  Some
> servers will want to conceal the lifetime of their keypair by
> generating nonces using a counter encrypted or hashed with a secret,
> using the cheapest encryption or hash function available; this may be
> TEA, AES, SHA-256, or something else, depending on the hardware.  Some
> servers will want to use a fast RNG to generate nonces.  32 bytes
> should be enough to prevent even a random (or hash-derived) nonce from
> repeating; anything less than that may not be enough for some servers.

The point of smaller/fewer nonces is two-fold:

 - if anyone was using 32 bytes of Dual_EC DRBG output before and it
   went unnoticed because, hey, that's what it's there fore, well, now
   it may be more noticeable if they do that sort of thing and spread
   those magic 32 bytes over several nonces

   Yes, this is fighting yesterday's war.  But anyways.

 - less subliminal channel bandwidth (same thing)

   Subliminal channels are very difficult to eliminate.  Merely reducing
   their bandwidth ought to help.  If, for example, there's only a 16
   bytes total of nonces in the handshakes (8 bytes for each of the
   client and server), and the cipher+mode in use doesn't need random
   IVs, then TLS connections would have no subliminal channels
   post-handshake, and hopefully the channel in the handshakes is very
   small (there's still bogus extensions and such to consider, but those
   at least can stand out).

   Worth it?  I think so.

Nico
-- 

From dharkins@lounge.org  Fri Nov  1 17:06:29 2013
Return-Path: <dharkins@lounge.org>
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 9A13311E8136 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 17:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.832
X-Spam-Level: 
X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 624KFzjjfOgT for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 17:06:24 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 74DCC11E8156 for <tls@ietf.org>; Fri,  1 Nov 2013 17:06:24 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DF20D10224008; Fri,  1 Nov 2013 17:06:23 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Nov 2013 17:06:24 -0700 (PDT)
Message-ID: <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net>
In-Reply-To: <20131101231342.GG32733@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com>
Date: Fri, 1 Nov 2013 17:06:24 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Nico Williams" <nico@cryptonector.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 00:06:29 -0000

On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:
> On Fri, Nov 01, 2013 at 03:38:06PM -0700, Dan Harkins wrote:
>> On Fri, November 1, 2013 2:34 pm, Robert Ransom wrote:
>> > On 10/31/13, Nico Williams <nico@cryptonector.com> wrote:
>> >
>> >>  - Many fewer nonce bytes and random IVs where possible.  Nonce
>> payloads
>> >>    should be sent when needed, if needed.  For example, to derive a
>> >>    session key from an DHE shared secret one does not really need
>> >>    nonces.  This means that counter modes are better, for example,
>> than
>> >>    CBC modes.
>> >
>> > If the server sends a nonce during a DHE/ECDHE key exchange, the
>> > server can safely reuse its DH keypair for multiple clients with no
>> > further design or implementation considerations.
>>
>>   I don't believe that's true. If the server reuses its ephemeral D-H
>> key
>> then caveat emptor applies-- it should validate the client's public key,
>
> Agreed.  A small nonce should suffice for key derivation if either party
> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
> nearly as large as 32 bytes, i.e., not enough to suffice for a
> Dual_EC-type backdoored RNG attack".  The party reusing a key should
> send some such small nonce, possibly a 64-bit nonce.  In any case, the
> client ought not be reusing ephemeral DH keys, and any server that does
> should be rotating them often (like SSHv1 used to).

  It has nothing to do with key derivation, it's to prevent a small sub-group
attack. Sending a nonce does not prevent this attack since it's just going to
be another known for the attacker to use when running through the small
sub-group looking the right secret.

>> regardless of whether a nonce is sent or not.
>
> For some curves there's no need to validate the client's public key.

  Which curves would those be?

  Dan.




From rransom.8774@gmail.com  Fri Nov  1 17:26:32 2013
Return-Path: <rransom.8774@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 6879911E810C for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 17:26:32 -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 L1w-xGPrK2Fi for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 17:26:31 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2334F11E814C for <tls@ietf.org>; Fri,  1 Nov 2013 17:26:29 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id k15so973550qaq.19 for <tls@ietf.org>; Fri, 01 Nov 2013 17:26:28 -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=FVWhfqWhUrGKSSErDzVelbtFA/0pd96lxzBM9sVyyfE=; b=I7ABP6r48W264Df9F6nFYpIlTknTavxMQJHWy2Kv4g1Wmjb5Ql8Dvp1Cg4OItfh/js smQTFeuVG1WPRIptyJZAHqSWx4aUSeiBByqLfrUctSiGZ4DiW3ZRLe6Vfn2Chs4Wrg9x nAW4vK/0G+4tx9XsuRkmABepXqdpJN04HvSj75jCGMwpQfYt3uZS9iZW/uAG8z+o0ZKS yyYzyQGVTxmR+RXI09n/nYtazMjDwZk8m+KjzLIzO7qu156ezcRXsOq6/8zGfQzokweW xBZA9aVFMdM/KoJkc5P5WlUHoH0X+AdoNNMy47JFYuqZWTy3JiEx3lZAPSxQM4sgPF94 COFA==
MIME-Version: 1.0
X-Received: by 10.49.61.9 with SMTP id l9mr7460207qer.64.1383351988709; Fri, 01 Nov 2013 17:26:28 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 17:26:28 -0700 (PDT)
In-Reply-To: <CACsn0ck94Gmyr3d6BsaM-Mwf4Qh6zFRv1qAS3bkitrFkFwVOFw@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <CACsn0ck94Gmyr3d6BsaM-Mwf4Qh6zFRv1qAS3bkitrFkFwVOFw@mail.gmail.com>
Date: Fri, 1 Nov 2013 17:26:28 -0700
Message-ID: <CABqy+sqck9S_7za4C++XLUcQHc5X2DSDdrp8M4bKAA-q+gcdwQ@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: tls@ietf.org
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 00:26:32 -0000

On 11/1/13, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Nov 1, 2013 2:21 PM, "Robert Ransom" <rransom.8774@gmail.com> wrote:
>>
>> On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> > TLS 1.3 should significantly reduce the number of round trips
>> > required. To this end I propose the following obviously secure scheme:
>> > the client sends a point on a curve in ClientHello and the server
>> > responds with certificates (or some other authentication thing) and a
>> > point on a curve, so that when the client speaks again, it is with a
>> > negotiated, authenticated shared secret. Before everyone screams about
>> > needing one signature per connection, note the server can use a time
>> > based secret key, so only has to do one exponentiation per client.
>>
>> This protocol should be designed to allow future extension to use
>> post-quantum encryption and/or key encapsulation cryptosystems.  (I
>> don't believe that quantum computers will become a threat, but some PQ
>> cryptosystems may be faster than ECDH.)
>>
> The PQ transition involves reworking the PKI as well. We also don't know if
> NTRU or something else will win. A proffered version byte to avoid
> downgrades could work, but I would not want to commit to the future.

If I believed that a 'PQ transition' would be needed, I would argue
for implementing it *now*.  This is purely for performance purposes,
if PQ cryptosystems turn out to be faster than ECDH in at least some
implementations.

>> It also needs to either allow session resumption without the
>> possibility of reusing any key used to encrypt or authenticate
>> application-level data, or explicitly forbid session resumption.
>>
>>
>> > Renegotiation should be killed: it serves no purpose.
>>
>> Renegotiation is a critical feature of TLS, which serves multiple
> purposes.
>>
>> * Renegotiation allows rekeying of a session.  This is absolutely
>> required for any ciphersuite based on a block cipher with a 128-bit or
>> smaller block, because block cipher modes' security properties degrade
>> after they are used for more than some number of blocks.
> After one zettabyte according to a simple calculation.

For counter mode with a non-GCM-like MAC, yes.  Other modes have other
security bounds.

>> * Applications can also use renegotiation-based rekeying to improve
>> forward secrecy; for example, the Mixminion specification
>> (<
> https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
>>,
>> section 4, line 1040) requires that relay-to-relay TLS connections be
>> rekeyed using renegotiation every 15 minutes for this purpose.
> If reconnecting is cheap enough that works. Designers need to deal with
> connection death anyway.

Reconnecting allows relatively simple network eavesdropping logs (e.g.
logs which contain connection endpoint addresses, start and end time,
and amount of data transferred) to record more information about the
application's behaviour.

Apart from that, applications should not need to cause connection
death in order to obtain forward secrecy.

>> * A TLS connection can be established by a fully trusted device which
>> knows a password or other application-layer authorization credential,
>> authorized to perform some operations using messages within the TLS
>> connection, and then transferred with the help of renegotiation to a
>> less trusted device to actually perform those operations.  This is
>> similar to the preceding use, but to provide 'sideways secrecy' rather
>> than forward secrecy.
> What does renegotiation get here?

Renegotiation can be used to prevent the untrusted device from
decrypting the user's password in order to use it to authorize a later
TLS connection.

> The untrusted device can do everything unless it is being monitored by a
> trusted device.

The untrusted device cannot do anything after the TLS connection is closed.

>> * One version of the Tor 'link protocol' (Tor's term for its outer
>> TLS-based connection protocol) uses renegotiation to provide secrecy
>> for the server's certification chain against purely passive attackers.
>>  The purposes above could be served by applying a one-way function to
>> the originally derived key material, then discarding the old keys;
>> this purpose cannot.
> TOR could send a temporary outer signature and an inner proof.

It's "Tor", not "TOR".

That's what it does now, using a custom authentication protocol with a
custom channel-binding  at the application layer, because the TLS
renegotiation mechanisms available at the time were too problematic.

> I agree this
> is a weakness, but CurveCP like mechanisms only work thanks to some known
> key.

Or the server could send the blob authenticating its (EC)DH public key
inside the (EC)DH secure channel.  (I mentioned this as an application
of renegotiation because you did not specify that server credentials
would be concealed, not because there is no special-purpose hack to
get around the lack of renegotiation.)


I agree that some of the problems that I know renegotiation can solve
can be addressed using other mechanisms.  I don't see the attraction
of designing and implementing a different protocol feature to solve
each problem when a single secure, well-designed renegotiation
protocol would solve all of them at once.


Robert Ransom

From rransom.8774@gmail.com  Fri Nov  1 17:38:17 2013
Return-Path: <rransom.8774@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 0181411E8156 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 17:38:17 -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 1OgPPE4MiyBM for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 17:38:16 -0700 (PDT)
Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3611E8136 for <tls@ietf.org>; Fri,  1 Nov 2013 17:38:16 -0700 (PDT)
Received: by mail-qe0-f52.google.com with SMTP id w7so2994372qeb.39 for <tls@ietf.org>; Fri, 01 Nov 2013 17:38:16 -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=nWksHWp4DOF47Mw5NKsSh1Uj0nmETaVl75fv40DTU4w=; b=li09p/2p+iYmVWnv2KWgFXDc1+EPLSnZrCfrInOaxMWGSii/hZEhYGCbh1cPN4eCN0 iU2xUMk+sm9jEKoqaJ0GmB90hoz8ukigeR35fbm/QShMYy8/FdEluPcY4R0nTxvuw16O u0RiRx3mz3baz8NlIh8rrJMCVqf/NVhwCOcllby/kafaXEza68LvLCjVH+navSLTozEV U5PalOYdBkfWM+7+SEvVc0RV3ExjJYpsJHX+gfdEW6n5U6EyzXagbJv5W8AVrw9Rf+/T rMWXZK60GZh07vnVXsGDoBYZAvv6hc3b8owai+7fjE6Y/sGOHzZtc4iFs3ZF03rN9M2M 0HWQ==
MIME-Version: 1.0
X-Received: by 10.49.25.47 with SMTP id z15mr7389441qef.27.1383352696012; Fri, 01 Nov 2013 17:38:16 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 17:38:15 -0700 (PDT)
In-Reply-To: <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net>
Date: Fri, 1 Nov 2013 17:38:15 -0700
Message-ID: <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 00:38:17 -0000

On 11/1/13, Dan Harkins <dharkins@lounge.org> wrote:
>
>
> On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:

>> Agreed.  A small nonce should suffice for key derivation if either party
>> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
>> nearly as large as 32 bytes, i.e., not enough to suffice for a
>> Dual_EC-type backdoored RNG attack".  The party reusing a key should
>> send some such small nonce, possibly a 64-bit nonce.  In any case, the
>> client ought not be reusing ephemeral DH keys, and any server that does
>> should be rotating them often (like SSHv1 used to).
>
>   It has nothing to do with key derivation, it's to prevent a small
> sub-group
> attack. Sending a nonce does not prevent this attack since it's just going
> to
> be another known for the attacker to use when running through the small
> sub-group looking the right secret.

Small-subgroup attacks are entirely orthogonal to whether a server can
be caused to reuse a session key.  (Reusing a session key destroys the
security properties of many bulk encryption methods, including all
stream ciphers, regardless of whether the server's DH secret key is
disclosed.)

>>> regardless of whether a nonce is sent or not.
>>
>> For some curves there's no need to validate the client's public key.
>
>   Which curves would those be?

Curve25519 ECDH implementations which follow the specification in Dr.
Bernstein's paper do not leak any information about the server's
secret key under any active attack.  They prevent small-subgroup
attacks by using the Montgomery ladder on a curve with a secure
quadratic twist, and by generating all secret keys to be divisible by
8 (the LCM of the orders of small subgroups).


Robert Ransom

From dharkins@lounge.org  Fri Nov  1 19:13:50 2013
Return-Path: <dharkins@lounge.org>
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 33D7011E8142 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 19:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.94
X-Spam-Level: 
X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 DMTIoOgRRqOT for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 19:13:45 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8711E80E7 for <tls@ietf.org>; Fri,  1 Nov 2013 19:13:44 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 873AA10224008; Fri,  1 Nov 2013 19:13:44 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 1 Nov 2013 19:13:44 -0700 (PDT)
Message-ID: <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net>
In-Reply-To: <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com>
Date: Fri, 1 Nov 2013 19:13:44 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Robert Ransom" <rransom.8774@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 02:13:50 -0000

On Fri, November 1, 2013 5:38 pm, Robert Ransom wrote:
> On 11/1/13, Dan Harkins <dharkins@lounge.org> wrote:
>>
>>
>> On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:
>
>>> Agreed.  A small nonce should suffice for key derivation if either
>>> party
>>> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
>>> nearly as large as 32 bytes, i.e., not enough to suffice for a
>>> Dual_EC-type backdoored RNG attack".  The party reusing a key should
>>> send some such small nonce, possibly a 64-bit nonce.  In any case, the
>>> client ought not be reusing ephemeral DH keys, and any server that does
>>> should be rotating them often (like SSHv1 used to).
>>
>>   It has nothing to do with key derivation, it's to prevent a small
>> sub-group
>> attack. Sending a nonce does not prevent this attack since it's just
>> going
>> to
>> be another known for the attacker to use when running through the small
>> sub-group looking the right secret.
>
> Small-subgroup attacks are entirely orthogonal to whether a server can
> be caused to reuse a session key.  (Reusing a session key destroys the
> security properties of many bulk encryption methods, including all
> stream ciphers, regardless of whether the server's DH secret key is
> disclosed.)

  "caused to reuse a session key"? Who said anything about that. My
statement was in response to yours that said:

   "If the server sends a nonce during DHE/ECDHE key exchange, the
    server can safely reuse its DH keypair for multiple clients WITH NO
    FURTHER DESIGN OR IMPLEMENTATION CONSIDERATIONS  (emphasis
    mine)".

Again, if the server decides to reuse its DH key pair with multiple
clients then it needs some implementation considerations, namely it
needs to protect itself against a small sub-group attack. And this is
regardless of whether it sends a nonce or not. It has nothing to do with
key derivation.

  Also, your statement that "[r]eusing a session key destroys the security
properties of...all stream ciphers" leaves a bit of quantification up to
the reader. It's reuse of a session key _and_ a counter/nonce, and that's
only if you are not using SIV mode.

>>>> regardless of whether a nonce is sent or not.
>>>
>>> For some curves there's no need to validate the client's public key.
>>
>>   Which curves would those be?
>
> Curve25519 ECDH implementations which follow the specification in Dr.
> Bernstein's paper do not leak any information about the server's
> secret key under any active attack.  They prevent small-subgroup
> attacks by using the Montgomery ladder on a curve with a secure
> quadratic twist, and by generating all secret keys to be divisible by
> 8 (the LCM of the orders of small subgroups).

  Thanks for the reference. I'll check it out.

  Dan.




From rransom.8774@gmail.com  Fri Nov  1 20:53:15 2013
Return-Path: <rransom.8774@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 161B321E809B for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 20:53:15 -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 KU-DnR4w5E99 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 20:53:14 -0700 (PDT)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CC0A921E8093 for <tls@ietf.org>; Fri,  1 Nov 2013 20:53:13 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id n9so2911071qcw.15 for <tls@ietf.org>; Fri, 01 Nov 2013 20:53:13 -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=YBlUPgkD3qtyjRiwO/HOsw4bTE4vVh3bYjfvRkO752o=; b=GsvuLWBNIiXgkStgcgbnXKFMi3n/R329UJUpy8i2Ox9YHjpk2t3h8lkBN1Vg1r3j2K Vjzb9Q6bXBWkGOHopDo+8ol8w5WFLaelFlGPHwQdKnsWna6Jo25qDzYS6+OStAjhf/q9 x0snnFcSNpGfyMYu1kMBAa8w7QBg7OlARdNHGgxgtSpnz/Wxi0Fbq/5NTm3AlbX365j5 5eWxTp7DtIuhANrD47mTcKm0vR67KQGzHAildAU4PS9Y2eiPnJcjqiRbq5BehtuFQuYz Vfuf48fWLEKaqRgbF8PmrNFPYPmRBeBYJUwPR66SNIntZ51XlNgkhuAY0dEBY+2/ev+k Rmtg==
MIME-Version: 1.0
X-Received: by 10.224.171.196 with SMTP id i4mr8085878qaz.38.1383364393196; Fri, 01 Nov 2013 20:53:13 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Fri, 1 Nov 2013 20:53:13 -0700 (PDT)
In-Reply-To: <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com> <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net>
Date: Fri, 1 Nov 2013 20:53:13 -0700
Message-ID: <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 03:53:15 -0000

On 11/1/13, Dan Harkins <dharkins@lounge.org> wrote:
>
>
> On Fri, November 1, 2013 5:38 pm, Robert Ransom wrote:
>> On 11/1/13, Dan Harkins <dharkins@lounge.org> wrote:
>>>
>>>
>>> On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:
>>
>>>> Agreed.  A small nonce should suffice for key derivation if either
>>>> party
>>>> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
>>>> nearly as large as 32 bytes, i.e., not enough to suffice for a
>>>> Dual_EC-type backdoored RNG attack".  The party reusing a key should
>>>> send some such small nonce, possibly a 64-bit nonce.  In any case, the
>>>> client ought not be reusing ephemeral DH keys, and any server that does
>>>> should be rotating them often (like SSHv1 used to).
>>>
>>>   It has nothing to do with key derivation, it's to prevent a small
>>> sub-group
>>> attack. Sending a nonce does not prevent this attack since it's just
>>> going
>>> to
>>> be another known for the attacker to use when running through the small
>>> sub-group looking the right secret.
>>
>> Small-subgroup attacks are entirely orthogonal to whether a server can
>> be caused to reuse a session key.  (Reusing a session key destroys the
>> security properties of many bulk encryption methods, including all
>> stream ciphers, regardless of whether the server's DH secret key is
>> disclosed.)
>
>   "caused to reuse a session key"? Who said anything about that.

Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
shared secrets in a future version of TLS.  My objection to that
proposal was that servers need to ensure that *something* in the
handshake is fresh, and if that is not a nonce, they will need to
ensure that at least one of the DH keypairs is new.  I thought it was
obvious that the reason for that was to prevent an attacker from
replaying the client DH public key and causing the server to reuse a
session key.  (It was obvious to Nico.)

> My
> statement was in response to yours that said:
>
>    "If the server sends a nonce during DHE/ECDHE key exchange, the
>     server can safely reuse its DH keypair for multiple clients WITH NO
>     FURTHER DESIGN OR IMPLEMENTATION CONSIDERATIONS  (emphasis
>     mine)".
>
> Again, if the server decides to reuse its DH key pair with multiple
> clients then it needs some implementation considerations, namely it
> needs to protect itself against a small sub-group attack. And this is
> regardless of whether it sends a nonce or not. It has nothing to do with
> key derivation.

Sorry.  I forgot that some elliptic-curve groups are meant to be
implemented in such a way that single-use ECDH keypairs appear to
remain safe, but an attacker can obtain the secret portion of an ECDH
keypair if it is used for more than one key exchange.

If the server sends a nonce during DHE/ECDHE key exchange, the server
can safely reuse its DH keypair for multiple clients with no further
*protocol-level* design or implementation constraints.  The
cryptographic primitive still needs to be securely designed and
implemented.

My main point was that if the server does *not* send a nonce, as Nico
suggested, the server needs significant further design,
implementation, and runtime computation to reuse its DH keypair
without reusing session keys.  That further effort may negate the
performance benefits of reusing DH keypairs on the server side, and
may lead implementations to not support (EC)DHE or a hypothetical
future version of TLS.


>   Also, your statement that "[r]eusing a session key destroys the security
> properties of...all stream ciphers" leaves a bit of quantification up to
> the reader. It's reuse of a session key _and_ a counter/nonce, and that's
> only if you are not using SIV mode.

RC4 does not support a counter/nonce.  Adam Langley's proposed
ChaCha/Poly1305 ciphersuites use ChaCha's nonce input for the message
number, not to permit safe reuse of a session key.

GCM mode (which uses AES in counter mode as a stream cipher) may or
may not reuse a nonce.  There's no way to guarantee that a GCM
implementation will not choose to reuse the portion of a nonce that it
generates, especially if it does not know that the key is being
reused, but you do have a point -- GCM can be implemented in such a
way that using a session key twice will not immediately destroy its
security.  (Reusing a session key many times will still eventually
lead to nonce reuse.)

CCM mode (also based on AES in counter mode) may or may not reuse a
nonce.  They cut-and-pasted the text from the GCM RFC that "Each value
of the nonce_explicit MUST be distinct for each distinct invocation of
the GCM encrypt function for any fixed key.", without changing "GCM"
to "CCM", and again without any mention of how this distinctness is to
be guaranteed within a 64-bit field if the implementation does not
know that a key has been reused.  As with GCM, reusing a session key
many times will still lead to nonce reuse in implementations with
limited storage.

SIV mode should be safer under key reuse, but is not used in any TLS
ciphersuite, and is not likely to be useful if future versions of TLS
retain the ServerRandom field (or an equivalent server-provided nonce
in the handshake).

Future stream-cipher-based ciphersuites are likely to be more like the
proposed ChaCha ciphersuite than GCM/CCM.


In any case, for the sake of security, performance, and simplicity,
ciphersuites should be able to rely on the handshake layer to not
generate the same session key twice.


Robert Ransom

From watsonbladd@gmail.com  Fri Nov  1 22:20:05 2013
Return-Path: <watsonbladd@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 B9A1721E80B3 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 22:20:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050,  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 99O0YAvndkGL for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 22:19:59 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 51FAB11E8178 for <tls@ietf.org>; Fri,  1 Nov 2013 22:19:55 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so297375wes.29 for <tls@ietf.org>; Fri, 01 Nov 2013 22:19:54 -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=qfQ12vCYwNFNyxf1eBjqX+AUXAsvX9SnScC3cQ4JTIo=; b=LUpdA52GR3JONXEb8/YzN0E/oFKf7eT6Qcv2R+La3mP0fqryXZAziKDvaBImjNa11w jHQSxxdHpPfKwLa9g81/LRrhS367NpRfhiCoY11lswF3Bnc5G6vHJSUZE07Qz/gMjHQd ZR4eo7YqrIDGi768Bar3A9qPQge7YEGKNTTuLpyKAWiRlYr4WnY4ahN9W+1/1wQ9i/Kq Uv7CFT1VC0fySXYJAzdhtEnzGfSjVtnhDg24VDUO+XmKGsc6+mB0yY1wGDFUSGtiZkod c/PQTRULONlnKy7xLlRXnzdltH0cpjDuvOX1FsCBMn2S/9I9xGX9wH5hXIl1zYGTcD8m vxrw==
MIME-Version: 1.0
X-Received: by 10.180.84.101 with SMTP id x5mr4755633wiy.58.1383369594285; Fri, 01 Nov 2013 22:19:54 -0700 (PDT)
Received: by 10.194.242.131 with HTTP; Fri, 1 Nov 2013 22:19:54 -0700 (PDT)
In-Reply-To: <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com> <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net> <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
Date: Fri, 1 Nov 2013 22:19:54 -0700
Message-ID: <CACsn0cnc39_YKOEP_nMQ3LhsKsjgrsNq6bMe8hMF7kvM+TzUHQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Robert Ransom <rransom.8774@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 05:20:05 -0000

On Fri, Nov 1, 2013 at 8:53 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
> On 11/1/13, Dan Harkins <dharkins@lounge.org> wrote:
>>
>>
>> On Fri, November 1, 2013 5:38 pm, Robert Ransom wrote:
>>> On 11/1/13, Dan Harkins <dharkins@lounge.org> wrote:
>>>>
>>>>
>>>> On Fri, November 1, 2013 4:13 pm, Nico Williams wrote:
>>>
>>>>> Agreed.  A small nonce should suffice for key derivation if either
>>>>> party
>>>>> reuses their supposedly-ephemeral DH keys.  By "small" I mean "not
>>>>> nearly as large as 32 bytes, i.e., not enough to suffice for a
>>>>> Dual_EC-type backdoored RNG attack".  The party reusing a key should
>>>>> send some such small nonce, possibly a 64-bit nonce.  In any case, the
>>>>> client ought not be reusing ephemeral DH keys, and any server that does
>>>>> should be rotating them often (like SSHv1 used to).
Or we could use a RNG with a security reduction to something strong.
What is it about cryptography that causes people to invent unproven solutions
against nonexistent problems?
>>>>
>>>>   It has nothing to do with key derivation, it's to prevent a small
>>>> sub-group
>>>> attack. Sending a nonce does not prevent this attack since it's just
>>>> going
>>>> to
>>>> be another known for the attacker to use when running through the small
>>>> sub-group looking the right secret.
>>>
>>> Small-subgroup attacks are entirely orthogonal to whether a server can
>>> be caused to reuse a session key.  (Reusing a session key destroys the
>>> security properties of many bulk encryption methods, including all
>>> stream ciphers, regardless of whether the server's DH secret key is
>>> disclosed.)
>>
>>   "caused to reuse a session key"? Who said anything about that.
>
> Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
> shared secrets in a future version of TLS.  My objection to that
> proposal was that servers need to ensure that *something* in the
> handshake is fresh, and if that is not a nonce, they will need to
> ensure that at least one of the DH keypairs is new.  I thought it was
> obvious that the reason for that was to prevent an attacker from
> replaying the client DH public key and causing the server to reuse a
> session key.  (It was obvious to Nico.)
>
>> My
>> statement was in response to yours that said:
>>
>>    "If the server sends a nonce during DHE/ECDHE key exchange, the
>>     server can safely reuse its DH keypair for multiple clients WITH NO
>>     FURTHER DESIGN OR IMPLEMENTATION CONSIDERATIONS  (emphasis
>>     mine)".
>>
>> Again, if the server decides to reuse its DH key pair with multiple
>> clients then it needs some implementation considerations, namely it
>> needs to protect itself against a small sub-group attack. And this is
>> regardless of whether it sends a nonce or not. It has nothing to do with
>> key derivation.
>
> Sorry.  I forgot that some elliptic-curve groups are meant to be
> implemented in such a way that single-use ECDH keypairs appear to
> remain safe, but an attacker can obtain the secret portion of an ECDH
> keypair if it is used for more than one key exchange.
Which ones are those? Assuring near-prime order is trivial, as is
checking points are
on the curve. Maybe this explains why some people think it is okay to
skip curve checks.
>
> If the server sends a nonce during DHE/ECDHE key exchange, the server
> can safely reuse its DH keypair for multiple clients with no further
> *protocol-level* design or implementation constraints.  The
> cryptographic primitive still needs to be securely designed and
> implemented.
>
> My main point was that if the server does *not* send a nonce, as Nico
> suggested, the server needs significant further design,
> implementation, and runtime computation to reuse its DH keypair
> without reusing session keys.  That further effort may negate the
> performance benefits of reusing DH keypairs on the server side, and
> may lead implementations to not support (EC)DHE or a hypothetical
> future version of TLS.
Not really: it just needs to blacklist client keys that it has seen
before. The extra
design is trivial, and computation is checking a hash table or Bloom
filter (false positives
have no cost). If you have multiple threads each can have one cache. However,
the cost of a nonce is small.
>
>
>>   Also, your statement that "[r]eusing a session key destroys the security
>> properties of...all stream ciphers" leaves a bit of quantification up to
>> the reader. It's reuse of a session key _and_ a counter/nonce, and that's
>> only if you are not using SIV mode.
>
> RC4 does not support a counter/nonce.  Adam Langley's proposed
> ChaCha/Poly1305 ciphersuites use ChaCha's nonce input for the message
> number, not to permit safe reuse of a session key.
>
> GCM mode (which uses AES in counter mode as a stream cipher) may or
> may not reuse a nonce.  There's no way to guarantee that a GCM
> implementation will not choose to reuse the portion of a nonce that it
> generates, especially if it does not know that the key is being
> reused, but you do have a point -- GCM can be implemented in such a
> way that using a session key twice will not immediately destroy its
> security.  (Reusing a session key many times will still eventually
> lead to nonce reuse.)
>
> CCM mode (also based on AES in counter mode) may or may not reuse a
> nonce.  They cut-and-pasted the text from the GCM RFC that "Each value
> of the nonce_explicit MUST be distinct for each distinct invocation of
> the GCM encrypt function for any fixed key.", without changing "GCM"
> to "CCM", and again without any mention of how this distinctness is to
> be guaranteed within a 64-bit field if the implementation does not
> know that a key has been reused.  As with GCM, reusing a session key
> many times will still lead to nonce reuse in implementations with
> limited storage.
>
> SIV mode should be safer under key reuse, but is not used in any TLS
> ciphersuite, and is not likely to be useful if future versions of TLS
> retain the ServerRandom field (or an equivalent server-provided nonce
> in the handshake).
>
> Future stream-cipher-based ciphersuites are likely to be more like the
> proposed ChaCha ciphersuite than GCM/CCM.
Why are we talking about supporting multiple ciphersuites? We have
strong reductions
to the security of AES for everything we are considering using, or
some similar cipher.
Performance will lead to one clear winner. Options are bad: they
invite incompatibility
and deployment issues, and are a place for bugs to hide. I want to
write TLS 1.3 in an
IOCCC entry ideally. (Well, I would if the success of OpenSSL didn't
ensure people
would use it).

We could parametrize keysize if you really want: give a 128 and 256
option. But no more!
>
>
> In any case, for the sake of security, performance, and simplicity,
> ciphersuites should be able to rely on the handshake layer to not
> generate the same session key twice.
For the sake of all three of those we should have one ciphersuite, one
key negotiation,
one curve, and a security proof.

>
>
> Robert Ransom
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From n.mavrogiannopoulos@gmail.com  Sat Nov  2 00:26:43 2013
Return-Path: <n.mavrogiannopoulos@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 1E62E11E81CC for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 00:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 X+-c0rY-gmrO for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 00:26:42 -0700 (PDT)
Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6946011E81CB for <tls@ietf.org>; Sat,  2 Nov 2013 00:26:41 -0700 (PDT)
Received: by mail-ee0-f54.google.com with SMTP id c50so160314eek.13 for <tls@ietf.org>; Sat, 02 Nov 2013 00:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=Z4EOm8xhfuJQ/c/5a2O60x0ZO/8vuhzIFBPsqy3QYsM=; b=frIKpJwj8Ipo2cHjTUu6axYnKqh/Qmq0sG5A9uTmLtU70pNpoL0GVZknRyUPaUddr0 LZJX+fDT8AQd23SwP9JXDbyNWMctjOGnfrNfN9UzdKtSzQw4I+rZ8fZThkXPw+aoeUn1 NHAz4YNgn+8TaTItIoPopd+Nd8m0R1H9CzmX7l4oOD6oZGAqOLu3FJ+yzxli/ChQa3Hq xvIjDJqJ29YMrZPpLE1KPwWGQQKrSoCC7iSiwHuzqrRlgY3d3rc6XcMsZuXlar1vW+eu 014TRBBfkfVRIL3T9pcZkagxeGCoJzwgR9DqjPZfjMgkGIdVxetaXRS4sdb08ciBdV6l Yqgg==
X-Received: by 10.15.83.9 with SMTP id b9mr6463281eez.34.1383377200578; Sat, 02 Nov 2013 00:26:40 -0700 (PDT)
Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id h45sm17195437eeg.5.2013.11.02.00.26.39 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Nov 2013 00:26:39 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <5274A92A.4030508@gnutls.org>
Date: Sat, 02 Nov 2013 08:26:34 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com>
In-Reply-To: <20131031230955.GB32733@gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [TLS] removal of nonces [was: What would make TLS cryptographically better for TLS 1.3]
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: Sat, 02 Nov 2013 07:26:43 -0000

On 11/01/2013 12:09 AM, Nico Williams wrote:

>  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
>    should be sent when needed, if needed.  For example, to derive a
>    session key from an DHE shared secret one does not really need
>    nonces.

Not really. Nonces are needed even in DHE ciphersuites. The nonces in
TLS make sure that the signatures from both parties are fresh and only
valid for this session (i.e., cannot be taken and re-used in another
session). See how PKINIT Kerberos has issues when used with smart cards,
just because it saved a round-trip by not sending a server nonce.

While one could select a message order in order to avoid using nonces by
using the DH public keys as such and maintain security (i.e., one cannot
save a round-trip), what would that buy? It would just make the TLS
shell weaker that would resemble less of a generic security protocol
with algorithm agility.

regards,
Nikos


From luto@amacapital.net  Fri Nov  1 16:05:11 2013
Return-Path: <luto@amacapital.net>
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 EAA1E11E8153 for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 2605R7qnrYjt for <tls@ietfa.amsl.com>; Fri,  1 Nov 2013 16:05:07 -0700 (PDT)
Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id B93E711E8136 for <tls@ietf.org>; Fri,  1 Nov 2013 16:05:05 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id md4so4862268pbc.16 for <tls@ietf.org>; Fri, 01 Nov 2013 16:05:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b+Le7FeMwHK/wqqyVk5YYAIq02j1fZxCjJoSXg0Dhlw=; b=NrkwMCtrZhB5LHXjZHBP1SwYLDAw25z58gA1aR17TzFLfAz5ZmbPRpy6tSjBfhbMJ5 VVAJitirtdMIyy/xbYFDEjKybdfy+LC/DD1AwJDBW/FpV2sGt6bg0H6f66gUle+J3vTt Et5uN1ECTQyfGSA7jfFLp0ZGKbSJ5cFL+SlK9X2+QJfkdUtxyD7S6P/SJfIMEPS5e6jd ItVNINHuBcVWKE/qPLGA/3YacONfWgXuhd9Ga7MHjKesXDVL01vEVKB/uNnjqntyyzxK s7zBSwaEfabCME83DodbmSCqKmD5bHBK5Pqm84AU4aDzbaJSGgsTy2iyCrdxgA7dp1vb KIgA==
X-Gm-Message-State: ALoCoQmYFrlyQI3v/lK4jwNwhBCsRQO8ck4MVCDEUeTkHUtnIcwSJypla2vcUWWfysQo/mBO1YKn
X-Received: by 10.69.31.203 with SMTP id ko11mr5339489pbd.127.1383347104506; Fri, 01 Nov 2013 16:05:04 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id go4sm13121723pbb.15.2013.11.01.16.05.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 16:05:03 -0700 (PDT)
Message-ID: <5274339D.9090200@mit.edu>
Date: Fri, 01 Nov 2013 16:05:01 -0700
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Robert Ransom <rransom.8774@gmail.com>,  Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 02 Nov 2013 07:02:44 -0700
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Fri, 01 Nov 2013 23:23:22 -0000

On 11/01/2013 02:21 PM, Robert Ransom wrote:
> On 10/31/13, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
>> TLS 1.3 should significantly reduce the number of round trips
>> required. To this end I propose the following obviously secure scheme:
>> the client sends a point on a curve in ClientHello and the server
>> responds with certificates (or some other authentication thing) and a
>> point on a curve, so that when the client speaks again, it is with a
>> negotiated, authenticated shared secret. Before everyone screams about
>> needing one signature per connection, note the server can use a time
>> based secret key, so only has to do one exponentiation per client.
> 
> This protocol should be designed to allow future extension to use
> post-quantum encryption and/or key encapsulation cryptosystems.  (I
> don't believe that quantum computers will become a threat, but some PQ
> cryptosystems may be faster than ECDH.)

I've yet to see one that's remotely competitive in both performance and
message size.  IIRC, the NTRU algorithms have some serious security
questions and the LWE and McEliece-like algorithms have enormous public
keys.

That being said, being ready for quantum computers if and when they show
up is a good idea.  (Note that everything will need to be upgraded to
256-bit security if real quantum computers show up, regardless of
public-key breaks.)

> * Applications can also use renegotiation-based rekeying to improve
> forward secrecy; for example, the Mixminion specification
> (<https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt>,
> section 4, line 1040) requires that relay-to-relay TLS connections be
> rekeyed using renegotiation every 15 minutes for this purpose.

Renegotiation is a really heavy-weight way to do this.  Just have both
sides apply some irreversible transformation to the master secret every
now and then.  (For example, they could hash the keys and throw away the
originals.)


OTOH, using renegotiation to request a client certificate after you've
seen the URL is useful.  But this doesn't actually need a change of
cipher -- it just needs the client to prove its identity.

--Andy

> 
> * A TLS connection can be established by a fully trusted device which
> knows a password or other application-layer authorization credential,
> authorized to perform some operations using messages within the TLS
> connection, and then transferred with the help of renegotiation to a
> less trusted device to actually perform those operations.  This is
> similar to the preceding use, but to provide 'sideways secrecy' rather
> than forward secrecy.
> 
> * One version of the Tor 'link protocol' (Tor's term for its outer
> TLS-based connection protocol) uses renegotiation to provide secrecy
> for the server's certification chain against purely passive attackers.
>  The purposes above could be served by applying a one-way function to
> the originally derived key material, then discarding the old keys;
> this purpose cannot.
> 
> 
> Robert Ransom
> 


From nico@cryptonector.com  Sat Nov  2 14:15:04 2013
Return-Path: <nico@cryptonector.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 2700A11E8241 for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 14:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.184
X-Spam-Level: 
X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 lULRPpCpQrav for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 14:14:59 -0700 (PDT)
Received: from homiemail-a97.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id ED79011E811D for <tls@ietf.org>; Sat,  2 Nov 2013 14:14:58 -0700 (PDT)
Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 70CD2286059; Sat,  2 Nov 2013 14:14:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uccQbX9KdEiYM4 LYefiZZvxEoyo=; b=ZTrQm8qh95CgF/M96xNSSd3CoRonxxQcL2fA/wcMNZaCZH PT+oer0ASO90EvwOrM4AU9PIl5xAPSD2Jnt15VRNIeE3LKy1vy3pOnQM6IS39RSa 7VeEmFfM1zPwH3WLtYvyWr0jtu7LJIxz76xqA0iS++7F5Va60TFDt5FHhfyz0=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 01278286058;  Sat,  2 Nov 2013 14:14:57 -0700 (PDT)
Date: Sat, 2 Nov 2013 16:14:45 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robert Ransom <rransom.8774@gmail.com>
Message-ID: <20131102211441.GA11907@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com> <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net> <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 21:15:04 -0000

On Fri, Nov 01, 2013 at 08:53:13PM -0700, Robert Ransom wrote:
> Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
> shared secrets in a future version of TLS.  My objection to that
> proposal was that servers need to ensure that *something* in the
> handshake is fresh, and if that is not a nonce, they will need to
> ensure that at least one of the DH keypairs is new.  I thought it was
> obvious that the reason for that was to prevent an attacker from
> replaying the client DH public key and causing the server to reuse a
> session key.  (It was obvious to Nico.)

If either party wants to reuse a DH key then all they have to do to make
it safe is also send a counter for salting.  The counter would reveal
some information, so it may have to look random -- like a nonce -- and
anyways, the other party can't validate anything about that counter.
BUT, a) it's optional (if you don't reuse DH keys, you don't reuse
session keys), b) it's *small*, much smaller than 32 bytes.

Large nonces and explicit random IVs form a great subliminal channel.
Taking direct outputs from a Dual_EC DRBG-style RNG for 32 byte nonces
in TLS handshake messages makes you vulnerable to attack via the RNG.
While having tiny nonces (or no nonces if not reusing your DH key) and
random-IV-free cipher modes makes such attacks much harder to mount
because the total number of bits of subliminal channel becomes fixed and
is way less than the number needed for that sort of attack.

Clearly there's a trade-off here:

 - no nonces -> no DH key reuse

 - large nonces -> no constraints on DH key reuse

 - small nonces -> limited number of DH key reuses

And:

 - large nonces facilitate some attacks via subliminal channels and RNG
   attacks

 - no nonces (and no explicit random IVs) -> no subliminal channels

 - small nonces -> lower subliminal channel bandwidth

There's no reason to pick one for all implementations.  And there's
reason to avoid large nonces.

> In any case, for the sake of security, performance, and simplicity,
> ciphersuites should be able to rely on the handshake layer to not
> generate the same session key twice.

Then GCM and friends are out.  They fail catastrophically with key
reuse.  But I think your concern is misplaced -- see above.

Nico
-- 

From nico@cryptonector.com  Sat Nov  2 14:23:12 2013
Return-Path: <nico@cryptonector.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 1CED821E80D8 for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 14:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level: 
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 dL8Jn487xl73 for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 14:23:07 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 35F8B11E811D for <tls@ietf.org>; Sat,  2 Nov 2013 14:23:07 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E39489405E; Sat,  2 Nov 2013 14:23:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QdTX0xmN3M8KBp Q8HdffFR5Vees=; b=WZVg219UfEE88IaYm1mKPHl+RsvDIZyPg/A6hcTTRNuwfR erckqylU9DNaqVMrCLKaV+ZjBwkOp9iW0df5d4U2PPdUEOXRr4EBfz/2oSNGK8Ba N5CSoHgbZP942FBGlRTngaGC7A5Yrw2w5CuBtFD+THqp5UXa5om+U0IDTqiQU=
Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 890D29405C;  Sat,  2 Nov 2013 14:23:06 -0700 (PDT)
Date: Sat, 2 Nov 2013 16:22:54 -0500
From: Nico Williams <nico@cryptonector.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Message-ID: <20131102212250.GB11907@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5274A92A.4030508@gnutls.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5274A92A.4030508@gnutls.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: tls@ietf.org
Subject: Re: [TLS] removal of nonces [was: What would make TLS cryptographically better for TLS 1.3]
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: Sat, 02 Nov 2013 21:23:12 -0000

On Sat, Nov 02, 2013 at 08:26:34AM +0100, Nikos Mavrogiannopoulos wrote:
> On 11/01/2013 12:09 AM, Nico Williams wrote:
> >  - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
> >    should be sent when needed, if needed.  For example, to derive a
> >    session key from an DHE shared secret one does not really need
> >    nonces.
> 
> Not really. Nonces are needed even in DHE ciphersuites. The nonces in
> TLS make sure that the signatures from both parties are fresh and only
> valid for this session (i.e., cannot be taken and re-used in another
> session). See how PKINIT Kerberos has issues when used with smart cards,
> just because it saved a round-trip by not sending a server nonce.

If your DH key is fresh then you don't need a nonce: the shared secret
will have a minimum of entropy close to that which you put into
selecting the DH private key, even if your peer reuses their DH key.

If you reuse DH keys then you need a coutner/nonce; the size of the
counter/nonce relates to the number of times you plan on reusing the DH
key.

>              [...], what would that buy? [...]

Nonces and explicit (even confounded) random IVs -especially the latter-
provide high subliminal channel bandwidth.  Smaller/fewer nonces and
explicit random IVs -> less subliminal channel bandwidth.  Capping the
number of subliminal channel bits per-connection is even more
interesting.

Nico
-- 

From rransom.8774@gmail.com  Sat Nov  2 14:51:19 2013
Return-Path: <rransom.8774@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 C7C8C21E80E8 for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 14:51:19 -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 Fkzl2UJyplzJ for <tls@ietfa.amsl.com>; Sat,  2 Nov 2013 14:51:19 -0700 (PDT)
Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1674521E80B7 for <tls@ietf.org>; Sat,  2 Nov 2013 14:51:18 -0700 (PDT)
Received: by mail-qe0-f42.google.com with SMTP id gc15so3363471qeb.15 for <tls@ietf.org>; Sat, 02 Nov 2013 14:51:18 -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=wkK1eyiH/lR3FVOCRC4t/02vOGjzslmpXGKYo4DZ0Uo=; b=d6a0HTltuMU/SS4Y+vlKpT92ILS7oTz5dnNe7DDNxlmgrbNIPWnacvs39q8XCgOWKa Ouju7nF/useCyDojdeApUJ6i65tliwiTLtfsaPq7jsIYmDHgBiZIuQIl7BmWsKf4azlO ApeIQLZwyRA6hq2+IzXttK7SJpppsWALeLb0QlG3Mx7CMz0aBzJopPSa++wvvRc4E6Z/ lZNQLAeXpmw9WG1AX2nldkXcWd0Dd/9gHUc6nufhmmCMMJUnqBqLtgljJqjsi5VwkQ0B iqL/bX3IVRULy9iDpLKJFz7cnr0+UlO4fWRUdgga9ov5xCiHR0gYF4AKZJ9MsWw5Tc4Q SI9w==
MIME-Version: 1.0
X-Received: by 10.49.95.135 with SMTP id dk7mr12647131qeb.3.1383429078396; Sat, 02 Nov 2013 14:51:18 -0700 (PDT)
Received: by 10.229.12.198 with HTTP; Sat, 2 Nov 2013 14:51:18 -0700 (PDT)
In-Reply-To: <20131102211441.GA11907@gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <CABqy+sof-NtSmZwTNN-x9Ekppz4PYMu2Pr3KjaEUdT7Wzxe7mQ@mail.gmail.com> <4e1772ced74d9347c88a66b123f8878f.squirrel@www.trepanning.net> <20131101231342.GG32733@gmail.com> <7e7cd08953358f9e9344d0afdb2e37bf.squirrel@www.trepanning.net> <CABqy+sq=9ue=iNkUEzrddJLdYRdAWk5YRz43sR2DV2Xrv5CHBQ@mail.gmail.com> <e5081bc3784fe15976397ccf73eee71f.squirrel@www.trepanning.net> <CABqy+sq9pp3hVkDYhZ98AfkXAYcdt2j+fbrFSnCmLteGHYEETg@mail.gmail.com> <20131102211441.GA11907@gmail.com>
Date: Sat, 2 Nov 2013 14:51:18 -0700
Message-ID: <CABqy+spfmoEC4G1WRo2czitPcWTbDUBQpon57bUof0dvPeT4Wg@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sat, 02 Nov 2013 21:51:19 -0000

On 11/2/13, Nico Williams <nico@cryptonector.com> wrote:
> On Fri, Nov 01, 2013 at 08:53:13PM -0700, Robert Ransom wrote:
>> Nico Williams proposed omitting all nonces from (EC)DHE handshakes and
>> shared secrets in a future version of TLS.  My objection to that
>> proposal was that servers need to ensure that *something* in the
>> handshake is fresh, and if that is not a nonce, they will need to
>> ensure that at least one of the DH keypairs is new.  I thought it was
>> obvious that the reason for that was to prevent an attacker from
>> replaying the client DH public key and causing the server to reuse a
>> session key.  (It was obvious to Nico.)
>
> If either party wants to reuse a DH key then all they have to do to make
> it safe is also send a counter for salting.  The counter would reveal
> some information, so it may have to look random -- like a nonce -- and
> anyways, the other party can't validate anything about that counter.
> BUT, a) it's optional (if you don't reuse DH keys, you don't reuse
> session keys), b) it's *small*, much smaller than 32 bytes.
>
> Large nonces and explicit random IVs form a great subliminal channel.
> Taking direct outputs from a Dual_EC DRBG-style RNG for 32 byte nonces
> in TLS handshake messages makes you vulnerable to attack via the RNG.
> While having tiny nonces (or no nonces if not reusing your DH key) and
> random-IV-free cipher modes makes such attacks much harder to mount
> because the total number of bits of subliminal channel becomes fixed and
> is way less than the number needed for that sort of attack.
>
> Clearly there's a trade-off here:
>
>  - no nonces -> no DH key reuse
>
>  - large nonces -> no constraints on DH key reuse
>
>  - small nonces -> limited number of DH key reuses
>
> And:
>
>  - large nonces facilitate some attacks via subliminal channels and RNG
>    attacks
>
>  - no nonces (and no explicit random IVs) -> no subliminal channels
>
>  - small nonces -> lower subliminal channel bandwidth
>
> There's no reason to pick one for all implementations.  And there's
> reason to avoid large nonces.

If your implementation is backdoored, you're screwed no matter what.
Avoiding nonces won't help you.


As for the nonce size tradeoff:

* no nonce: no DH keypair reuse, or a replay-detection cache
* 32-byte nonce: server can use a PRNG, or can use a keyed hash to
hide its key-use counter
* 16-byte nonce: server must disclose its key-use counter or use a
block cipher to hide it
* 8-byte nonce: server must disclose its key-use counter or use a
64-bit block cipher (e.g. 3DES or TEA) to hide it

32-byte nonces must be allowed.  There's no downside to using a
32-byte nonce field in all cases; the server can pad with zero bytes
(or PRNG output, or whatever it wants) if it uses AES to hide its
counter.


>> In any case, for the sake of security, performance, and simplicity,
>> ciphersuites should be able to rely on the handshake layer to not
>> generate the same session key twice.
>
> Then GCM and friends are out.  They fail catastrophically with key
> reuse.  But I think your concern is misplaced -- see above.

No.  The reason that ciphersuites should be able to rely on the
handshake layer to not generate the same session key twice is to
*allow* GCM and other stream-cipher-based constructions.


Robert Ransom

From skyper@thc.org  Sun Nov  3 09:03:53 2013
Return-Path: <skyper@thc.org>
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 A056521E80FB for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 09:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 YGgr395re3f3 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 09:03:49 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ABB1111E8196 for <tls@ietf.org>; Sun,  3 Nov 2013 09:03:49 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so10589976ieb.19 for <tls@ietf.org>; Sun, 03 Nov 2013 09:03:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZQ2rOeSnZLX3PyUGN1UBVHrRewnA/vFMWX3ovuzFuuE=; b=WUoYpqs7Nbz3kufAhagKgXC0BeaI4FLWXpaii5ytggzMpPcwhQYpjuSCEd17+myyKf v6ERwMFwdu4nQF78hX2GdNzleu+iPGdsCjmHdEzCLfF1iWehA5lIuk/9/K/4niHXE3/i n29rE4gIBaf2LZ5dC70bHr51v/X5/jI8NpGM4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZQ2rOeSnZLX3PyUGN1UBVHrRewnA/vFMWX3ovuzFuuE=; b=MImZUWOCNZzEsgHWH8hF6uWMVgYCOwjjwNCJOJaNhvaVVLMf1u44ACgM1QhXywxtld JSvliRAeWylGVboh11rVf2EAxOfRHCmyCZ1W01j/0c99t3T486880K0R3tx4GcW+laZF IrOvJRR/MPPwPhOozQQ+QJkXPRwoQ3gyxbjUkMRikcBkAiiYDRDjamNxsHxGgjusOgIN oO3M+Rc5IDhYE3lw5Omfj5Y7RGzLAioANBkhAa+Or+/BwcVaEpEAarOCXhOsMf3MpvoS G6ElNKXNkgr+E87Z4Nk3RDVUCueH3WM0MPMH411QoP5tDcqskrCDmQ6LjUFBnEAdbDOe LlYg==
X-Gm-Message-State: ALoCoQny9t7CitX9LfmNOSWzQocLJBr7l+F72KtcjiPx703dFW9LlactS7BlsjPV9TICpgXl8i8b
MIME-Version: 1.0
X-Received: by 10.50.30.229 with SMTP id v5mr9256467igh.27.1383498229088; Sun, 03 Nov 2013 09:03:49 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 09:03:48 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <5273FC73.8010303@gnutls.org>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org>
Date: Sun, 3 Nov 2013 17:03:48 +0000
Message-ID: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: multipart/alternative; boundary=047d7bacc30c7e1c8704ea48c8ad
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 17:03:53 -0000

--047d7bacc30c7e1c8704ea48c8ad
Content-Type: text/plain; charset=ISO-8859-1

Hi,

avoid renegotiation. It serves no purpose and only adds complexity. It is
so much more secure to kill and re-establish the TLS if the counters run
out instead of renegotiating.

This might be better placed in a higher layer:
It is desirable for the server to know how the client authenticated the
server. E.g. currently the a server does not know if the client matched the
Server's Certificate's CommonName against the URI or if the client
performed full certificate chain authentication. Currently the server
blindly trusts the client (e.g. user) to check the certificate chain and
match the URI<>CN.

(An example are jabber servers using TLS. Most clients allow the user to
accept any server certificate without verification. The jabber server has
no way to detect which client performed proper certificate verification and
CN<>URI match).


regards,

ralf



On Fri, Nov 1, 2013 at 7:09 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org>wrote:

> On 11/01/2013 12:09 AM, Nico Williams wrote:
> >
> > My list:
> >
> >  - It should be deployable, that's first; in particular, it needs to be
> >    deployable with ECDH PFS key exchanges.
>
> (unrelated) It would actually be nice to have a wiki for anyone to add
> his wish list there.
>
>
> >  - Renegotiation should be replaced with an NPN-like extension that
> >    provides privacy to the TLS client principal name.
>
> I don't think anyone can avoid renegotiation. Since the TLS packet
> counters are 64-bit (and more importantly in DTLS 48-bits), one cannot
> avoid renegotiation to reset the counters.
>
> (nevertheless, all the practical VPNs I've seen using TLS, don't use
> renegotiation, they just re-establish the session).
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7bacc30c7e1c8704ea48c8ad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br>avoid renegotiation. It serves no purpose =
and only adds complexity. It is so much more secure to kill and re-establis=
h the TLS if the counters run out instead of renegotiating.<br><br></div><d=
iv>
This might be better placed in a higher layer:<br></div><div>It is desirabl=
e for the server to know how the client authenticated the server. E.g. curr=
ently the a server does not know if the client matched the Server&#39;s Cer=
tificate&#39;s CommonName against the URI or if the client performed full c=
ertificate chain authentication. Currently the server blindly trusts the cl=
ient (e.g. user) to check the certificate chain and match the URI&lt;&gt;CN=
.<br>
<br></div><div>(An example are jabber servers using TLS. Most clients allow=
 the user to accept any server certificate without verification. The jabber=
 server has no way to detect which client performed proper certificate veri=
fication and CN&lt;&gt;URI match).<br>
</div><br><div><br>regards,<br><br>ralf<br><br></div></div><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Fri, Nov 1, 2013 at 7:09 P=
M, Nikos Mavrogiannopoulos <span dir=3D"ltr">&lt;<a href=3D"mailto:nmav@gnu=
tls.org" target=3D"_blank">nmav@gnutls.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 11/01/2013 12:09 AM, Ni=
co Williams wrote:<br>
&gt;<br>
&gt; My list:<br>
&gt;<br>
&gt; =A0- It should be deployable, that&#39;s first; in particular, it need=
s to be<br>
&gt; =A0 =A0deployable with ECDH PFS key exchanges.<br>
<br>
</div>(unrelated) It would actually be nice to have a wiki for anyone to ad=
d<br>
his wish list there.<br>
<div class=3D"im"><br>
<br>
&gt; =A0- Renegotiation should be replaced with an NPN-like extension that<=
br>
&gt; =A0 =A0provides privacy to the TLS client principal name.<br>
<br>
</div>I don&#39;t think anyone can avoid renegotiation. Since the TLS packe=
t<br>
counters are 64-bit (and more importantly in DTLS 48-bits), one cannot<br>
avoid renegotiation to reset the counters.<br>
<br>
(nevertheless, all the practical VPNs I&#39;ve seen using TLS, don&#39;t us=
e<br>
renegotiation, they just re-establish the session).<br>
<br>
regards,<br>
Nikos<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div>

--047d7bacc30c7e1c8704ea48c8ad--

From skyper@thc.org  Sun Nov  3 09:18:26 2013
Return-Path: <skyper@thc.org>
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 5679F21F9F88 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 09:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 ujWRMIeyM9Su for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 09:18:14 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B9ED121F9FA5 for <tls@ietf.org>; Sun,  3 Nov 2013 09:18:13 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so10945827iec.27 for <tls@ietf.org>; Sun, 03 Nov 2013 09:18:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RiF5WRogtBeq0nmuqUl8ZB86+Hnjg5ISmbmK3TA9/jk=; b=HtZzNfXHmOglL8Pc22nAHbf3Knw2P+WnEexP1AjM5WNWm1tRgX2mol7q+6UUL7cVYI f2JLQTj3tTgPxWllgvu1Bq+9rrDy24gWOhKkh1tJBa1ubp36qBMoz8r51lu9MT9mVviZ UCeTVXiKtDrx0r/DXgvbZ9bWU4EO2/Uo3tyFg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RiF5WRogtBeq0nmuqUl8ZB86+Hnjg5ISmbmK3TA9/jk=; b=cjXqcXxz13fbaVKropL2ssG8Vv6dpXEtPS05dYypTtPoefZp5ekInrIXrzv0kejBnR HR2zTo+RSFGpW4TWuXE7p4e/hJpXCfB6dzxTRV5257br1ZAvnd0wD3tOMDcdCNaYRjCD HdAG/1TJlgvNmRXK6ww3sEBXeeXWYD18D5HEOQC4qNjCDSQkidryWP7vkF65riJqhqeM vTz/cGfx34HcLRJfRfF35MCGprohUmxY3SlauGql6bHJ1aGI0CVehdZxm4Vm/4OSpCoJ abl1zPqnI9qiTsAmbMXvn5Ie6JP9pimflIDcXXIwUThOFf4CtvW+zfoE1CEa8xtnCOG8 bGZA==
X-Gm-Message-State: ALoCoQlVdGLBnZVuHQZn9Wi4r701wksHivtu1VbekHFxn6UaVdDlA7y1Ccz6oLt4vj+8+lroEEoI
MIME-Version: 1.0
X-Received: by 10.50.128.137 with SMTP id no9mr9131943igb.36.1383499093148; Sun, 03 Nov 2013 09:18:13 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 09:18:13 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
Date: Sun, 3 Nov 2013 17:18:13 +0000
Message-ID: <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Robert Ransom <rransom.8774@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b10cf0dfea48404ea48fba9
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 17:18:26 -0000

--047d7b10cf0dfea48404ea48fba9
Content-Type: text/plain; charset=ISO-8859-1

Hi,



Renegotiation is a critical feature of TLS, which serves multiple purposes.

>
> * Renegotiation allows rekeying of a session.  This is absolutely
> required for any ciphersuite based on a block cipher with a 128-bit or
> smaller block, because block cipher modes' security properties degrade
> after they are used for more than some number of blocks.
>

Can you be more specific about 'some number of blocks'? This number is
astronomically large. Reconnect the TLS if you have to.


>
> * Applications can also use renegotiation-based rekeying to improve
> forward secrecy; for example, the Mixminion specification
> (<
> https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
> >,
> section 4, line 1040) requires that relay-to-relay TLS connections be
> rekeyed using renegotiation every 15 minutes for this purpose.
>

Mixminion falsely assume  that the security degrades if a connection is
live for more than 15 minutes. That's security wise not true. In today's
security design (TLS) the negotiated session key material is secure for
years (if not decades). Gone are the times when DES was used and DES could
be cracked in 24h and it was desirable to use a new DES key every 24 hours.
Gone. Gone Gone.

If you negotiate session keys that could be cracked within a year you
should not have negotiated those sessions keys in the first place.



> * A TLS connection can be established by a fully trusted device which
> knows a password or other application-layer authorization credential,
> authorized to perform some operations using messages within the TLS
> connection, and then transferred with the help of renegotiation to a
> less trusted device to actually perform those operations.  This is
> similar to the preceding use, but to provide 'sideways secrecy' rather
> than forward secrecy.
>

Renegotiation comes at a huge cost of complexity (not just from a
development point of view but also from a security audit point of view).
All features of re-negotiation can be achieved by re-connecting.
Re-connecting is well understood, easily tested and audited.


>
> * One version of the Tor 'link protocol' (Tor's term for its outer
> TLS-based connection protocol) uses renegotiation to provide secrecy
> for the server's certification chain against purely passive attackers.
>  The purposes above could be served by applying a one-way function to
> the originally derived key material, then discarding the old keys;
> this purpose cannot.
>

reconnect!

regards,

ralf

>
>
> Robert Ransom
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b10cf0dfea48404ea48fba9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br><br><div><div class=3D"gmail_extra"><br>Renegot=
iation is a critical feature of TLS, which serves multiple purposes.<br><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
* Renegotiation allows rekeying of a session. =A0This is absolutely<br>
required for any ciphersuite based on a block cipher with a 128-bit or<br>
smaller block, because block cipher modes&#39; security properties degrade<=
br>
after they are used for more than some number of blocks.<br></blockquote><d=
iv><br></div><div>Can you be more specific about &#39;some number of blocks=
&#39;? This number is astronomically large. Reconnect the TLS if you have t=
o.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>
* Applications can also use renegotiation-based rekeying to improve<br>
forward secrecy; for example, the Mixminion specification<br>
(&lt;<a href=3D"https://github.com/nmathewson/mixminion-doc/blob/a661212831=
d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt" target=3D"_blank">http=
s://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca1=
6452e3aeec/spec/minion-spec.txt</a>&gt;,<br>

section 4, line 1040) requires that relay-to-relay TLS connections be<br>
rekeyed using renegotiation every 15 minutes for this purpose.<br></blockqu=
ote><div><br></div><div>Mixminion falsely assume=A0 that the security degra=
des if a connection is live for more than 15 minutes. That&#39;s security w=
ise not true. In today&#39;s security design (TLS) the negotiated session k=
ey material is secure for years (if not decades). Gone are the times when D=
ES was used and DES could be cracked in 24h and it was desirable to use a n=
ew DES key every 24 hours. Gone. Gone Gone. <br>
<br></div><div>If you negotiate session keys that could be cracked within a=
 year you should not have negotiated those sessions keys in the first place=
.<br><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
* A TLS connection can be established by a fully trusted device which<br>
knows a password or other application-layer authorization credential,<br>
authorized to perform some operations using messages within the TLS<br>
connection, and then transferred with the help of renegotiation to a<br>
less trusted device to actually perform those operations. =A0This is<br>
similar to the preceding use, but to provide &#39;sideways secrecy&#39; rat=
her<br>
than forward secrecy.<br></blockquote><div><br></div><div>Renegotiation com=
es at a huge cost of complexity (not just from a development point of view =
but also from a security audit point of view). All features of re-negotiati=
on can be achieved by re-connecting. Re-connecting is well understood, easi=
ly tested and audited.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<br>
* One version of the Tor &#39;link protocol&#39; (Tor&#39;s term for its ou=
ter<br>
TLS-based connection protocol) uses renegotiation to provide secrecy<br>
for the server&#39;s certification chain against purely passive attackers.<=
br>
=A0The purposes above could be served by applying a one-way function to<br>
the originally derived key material, then discarding the old keys;<br>
this purpose cannot.<br></blockquote><div><br></div><div>reconnect!<br><br>=
</div><div>regards,<br><br>ralf <br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Robert Ransom<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div></div></div>

--047d7b10cf0dfea48404ea48fba9--

From n.mavrogiannopoulos@gmail.com  Sun Nov  3 09:46:19 2013
Return-Path: <n.mavrogiannopoulos@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 2879F21E809F for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 09:46:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 SDdaQRPtzSJT for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 09:46:18 -0800 (PST)
Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1CA21E80C4 for <tls@ietf.org>; Sun,  3 Nov 2013 09:46:14 -0800 (PST)
Received: by mail-ee0-f43.google.com with SMTP id b47so673654eek.2 for <tls@ietf.org>; Sun, 03 Nov 2013 09:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=0hAvS4Gdr0te3GozBkOOt2nEb4cqmZSew2rixxHgtXU=; b=K65wRCJi+kPzS8+K5TomzWb1M3YElpcccP5ML4UayVhCRwYfLqdBrZOzWn9litqvWp GXgsxkZv1OHeekXT8QXVX0k63OjLkLSAUKPBHHE5r/SIysH02yDU9CWVQjd5T1lJfeJp fSFCf6HW0DTs+H4zWotggdz4y884TLYdHoONoC930v2/2abdoUG//GQhVqp9gPRYeW+B 7cyPmYWV7iBntahFR80M9L0KmFDjo78MnQjAtKAF2ZdM9QVNPjPcsImOvD1IWpRYJwVs GQBZLs3BF0no4ZCyONJQldIf4qr3ngptrWHZvCPsOQN/LM08uJa0vaV25z3s44Tp8GFh RUHQ==
X-Received: by 10.14.201.9 with SMTP id a9mr14360283eeo.28.1383500774137; Sun, 03 Nov 2013 09:46:14 -0800 (PST)
Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id i47sm12640372eem.5.2013.11.03.09.46.13 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 09:46:13 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <52768BE0.3000602@gnutls.org>
Date: Sun, 03 Nov 2013 18:46:08 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
In-Reply-To: <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 17:46:19 -0000

On 11/03/2013 06:18 PM, Ralf Skyper Kaiser wrote:

>     * A TLS connection can be established by a fully trusted device which
>     knows a password or other application-layer authorization credential,
>     authorized to perform some operations using messages within the TLS
>     connection, and then transferred with the help of renegotiation to a
>     less trusted device to actually perform those operations.  This is
>     similar to the preceding use, but to provide 'sideways secrecy' rather
>     than forward secrecy.
> Renegotiation comes at a huge cost of complexity (not just from a
> development point of view but also from a security audit point of view).
> All features of re-negotiation can be achieved by re-connecting.
> Re-connecting is well understood, easily tested and audited.

The fact that renegotiation is available in almost all implementations,
says that the cost is not as huge as you mention. You also seem to imply
that renegotiation is as secure as terminating a connection and
re-establishing another one. It is not.

regards,
Nikos


From ynir@checkpoint.com  Sun Nov  3 11:18:41 2013
Return-Path: <ynir@checkpoint.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 C87BF21E80FD for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 11:18:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.497
X-Spam-Level: 
X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 sNwL10lZCTcE for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 11:18:25 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 71E3021E80F8 for <tls@ietf.org>; Sun,  3 Nov 2013 11:18:17 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA3JI9JN026998; Sun, 3 Nov 2013 21:18:09 +0200
X-CheckPoint: {5276A02A-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 21:18:09 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngUoMjfWHp8eUeJG+rmdHIlV5oPTiyAgAFPL4CAAwGAAIAAJYkA
Date: Sun, 3 Nov 2013 19:18:08 +0000
Message-ID: <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com>
In-Reply-To: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.239]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <7F2343BE7D49F345B169325FA5E08048@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 19:18:41 -0000
X-List-Received-Date: Sun, 03 Nov 2013 19:18:41 -0000

On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:

> Hi,
>=20
> avoid renegotiation. It serves no purpose and only adds complexity. It is=
 so much more secure to kill and re-establish the TLS if the counters run o=
ut instead of renegotiating.
>=20

Hi, Ralf

The one use of renegotiation that I'm aware of, is for overcoming a UI issu=
e in browsers. If you do a TLS handshake with mutual authentication (so the=
 server sends a CertReq), the browser pops up a dialog box with all the cer=
tificates you might have. Website designers with to avoid that, especially =
on the welcome screen, so the web server does not send a CertReq. Instead, =
they present a welcome screen with a button or link that says "Login with c=
ertificates" Clicking that performs a regular SSL handshake (or does nothin=
g at all if the connection is already established), but when the request co=
mes in ("GET /login_with_certs HTTP/1.1"), the web server sends a HELLO_REQ=
UEST, and in the resulting handshake it sends the CertReq, so the pop-up ap=
pears when the user *is* expecting it.

I totally agree that renegotiation for rekeying is useless for people who a=
re not doing DES-CBC and 3DES-CBC. It's even superfluous for them in most c=
ases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in 3DES.=
 How many sites do you browse with 4 GB?  Maybe downloading stuff=85) =20

But before we can drop renegotiation from the standards, or recommend that =
implementors don't implement it, we need an alternate mechanism to upgrade =
from server-authenticated to mutually-authenticated within the same session=
. That is a real market need. How about allowing a CertReq sent from the se=
rver to the client in the middle of a connection, followed by the client se=
nding a Certificate and Certificate Verify. For simplicity, we could always=
 do that after the Finished, so that it's always Server-authenticated sessi=
on when the Finished is sent.

Yoav


From rransom.8774@gmail.com  Sun Nov  3 12:30:29 2013
Return-Path: <rransom.8774@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 0F6F021E8104 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 12:30:29 -0800 (PST)
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=[AWL=0.000, 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 XU0GuQqn1sYt for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 12:30:28 -0800 (PST)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 406D621E80E8 for <tls@ietf.org>; Sun,  3 Nov 2013 12:30:26 -0800 (PST)
Received: by mail-qc0-f170.google.com with SMTP id n9so3556957qcw.15 for <tls@ietf.org>; Sun, 03 Nov 2013 12:30:25 -0800 (PST)
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=JkpAin37B4na/GRl6ZpqMt6fFUl1T4yxViw+8SLAf7g=; b=hqNaD17ogMUrJK+sr5i1JDKlR3XzSxxydQ4vK5buxBSbGDt+XsLcetoByNDmlmfagT 1SuRYOul1dokXlO2Apgh/jaiQ4yi1JwEddTf6rEUhkiOGG6YyMv/oSaz1Z+Gs2IvuaNj mEJMZJXxGRx2RuzlGGsR5ZCY7LRHUzMyPQrBTOWeWvWiUN0D+9dE1flalt7aK8UvANzX UK2DAgOmQKyaltRJ+ReLGThhbJy0KLfO6z1MgdhGMQX9UP29kHmcYnUEwH7uqsZbhmHN VVSi+87Hf0g6wyQF7RUJXiWanmRUKRe9i8O+jw3R44AKUrdUuxwlTY7EIcyBGM6Jdq2B Z0lQ==
MIME-Version: 1.0
X-Received: by 10.229.106.131 with SMTP id x3mr18080151qco.1.1383510625665; Sun, 03 Nov 2013 12:30:25 -0800 (PST)
Received: by 10.229.12.198 with HTTP; Sun, 3 Nov 2013 12:30:25 -0800 (PST)
In-Reply-To: <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
Date: Sun, 3 Nov 2013 12:30:25 -0800
Message-ID: <CABqy+sre3V5eZXotTYGj=dg4774B4TYQB3jpnQ_8JFg-N0W4Bw@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 20:30:29 -0000

On 11/3/13, Ralf Skyper Kaiser <skyper@thc.org> wrote:

>> * Applications can also use renegotiation-based rekeying to improve
>> forward secrecy; for example, the Mixminion specification
>> (<
>> https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
>> >,
>> section 4, line 1040) requires that relay-to-relay TLS connections be
>> rekeyed using renegotiation every 15 minutes for this purpose.
>>
>
> Mixminion falsely assume  that the security degrades if a connection is
> live for more than 15 minutes. That's security wise not true. In today's
> security design (TLS) the negotiated session key material is secure for
> years (if not decades). Gone are the times when DES was used and DES could
> be cracked in 24h and it was desirable to use a new DES key every 24 hours.
> Gone. Gone Gone.
>
> If you negotiate session keys that could be cracked within a year you
> should not have negotiated those sessions keys in the first place.

Mixminion correctly assumes that anyone who obtains a session key by
compromising a server can use that key to decrypt all traffic
protected by it, no matter how long brute-force search would have
taken to find the key.


Robert Ransom

From skyper@thc.org  Sun Nov  3 15:12:44 2013
Return-Path: <skyper@thc.org>
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 939FF21E8127 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 EkBFp9YWjL+1 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:12:40 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 697C921E812D for <tls@ietf.org>; Sun,  3 Nov 2013 15:12:33 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id u16so11410647iet.35 for <tls@ietf.org>; Sun, 03 Nov 2013 15:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4oOBahAGkf+GJMF5oF9q9ueVkXcuGWm5d1620YttQK4=; b=dJDhO6Y1PrFeCNJr/BIBx/exqvJZ25EGTx31i8CMJIaBFxClJnqhn4PvtQ3wR8KzRS GGuCw0ZdaDYYd2qoKOkYflzPYm+fPWtVkmv972HaLA+18idlMyLbKiWGwzlyi51yXHXy UrQGT0VyoetXnlNCjwVijmKApHiVVCPADTDw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4oOBahAGkf+GJMF5oF9q9ueVkXcuGWm5d1620YttQK4=; b=YL75MD1caOEURz5b268I+Xj0ZniIr6UJSN/WXQ42WHCm0rHgLm8517ePMCQcrGoudn ITgUFVgOv3mKR+0b8aq9+oFzCFtF0MMzjs5Lc+J20d0ixFSWdg0ATzbosvVCyiU/9gF3 GuWljJE6rthvmIOhcTYve86Ho5kVnEGVjPlcSDCtu3YdQWr7TR73FjV6lHr4CzWBOjRV AkQIRIKBvVGNEb8yGxwUIIwQV0akxCtW4VJ86jYuBE73UKeBlJR31bPaFF8d0t0r2lCY lQ1HzKv16tYP9Kj4IgbNYsJrKlbtVGrzwT/bRSeY6pjlQaClUCbzfTRiauLeDjkOWsjz J5Fg==
X-Gm-Message-State: ALoCoQms8X+airg7OqJbiH6OZGvP8dh0VlM2/zhbOUe6XPNtZ5C/ZbGJTT47pxr4/XmWXvK6HfNS
MIME-Version: 1.0
X-Received: by 10.43.158.10 with SMTP id ls10mr8220424icc.20.1383520350845; Sun, 03 Nov 2013 15:12:30 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 15:12:30 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CABqy+sre3V5eZXotTYGj=dg4774B4TYQB3jpnQ_8JFg-N0W4Bw@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com> <CABqy+sre3V5eZXotTYGj=dg4774B4TYQB3jpnQ_8JFg-N0W4Bw@mail.gmail.com>
Date: Sun, 3 Nov 2013 23:12:30 +0000
Message-ID: <CA+BZK2oRv-c7vKPqshhmgadg=DNWTnAXCvPrJubWhrUzNCgtXg@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Robert Ransom <rransom.8774@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c1ead60d4ff404ea4def98
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 23:12:44 -0000

--001a11c1ead60d4ff404ea4def98
Content-Type: text/plain; charset=ISO-8859-1

Hi,

someone who can compromise the server to extract the currently used session
keys can also extract all future session keys (or at least is most likely
able to). There is no (practical) need or added security when the session
key is renegotiated every 15 minutes.

ralf



On Sun, Nov 3, 2013 at 8:30 PM, Robert Ransom <rransom.8774@gmail.com>wrote:

> On 11/3/13, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>
> >> * Applications can also use renegotiation-based rekeying to improve
> >> forward secrecy; for example, the Mixminion specification
> >> (<
> >>
> https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
> >> >,
> >> section 4, line 1040) requires that relay-to-relay TLS connections be
> >> rekeyed using renegotiation every 15 minutes for this purpose.
> >>
> >
> > Mixminion falsely assume  that the security degrades if a connection is
> > live for more than 15 minutes. That's security wise not true. In today's
> > security design (TLS) the negotiated session key material is secure for
> > years (if not decades). Gone are the times when DES was used and DES
> could
> > be cracked in 24h and it was desirable to use a new DES key every 24
> hours.
> > Gone. Gone Gone.
> >
> > If you negotiate session keys that could be cracked within a year you
> > should not have negotiated those sessions keys in the first place.
>
> Mixminion correctly assumes that anyone who obtains a session key by
> compromising a server can use that key to decrypt all traffic
> protected by it, no matter how long brute-force search would have
> taken to find the key.
>
>
> Robert Ransom
>

--001a11c1ead60d4ff404ea4def98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br>someone who can compromise the server to e=
xtract the currently used session keys can also extract all future session =
keys (or at least is most likely able to). There is no (practical) need or =
added security when the session key is renegotiated every 15 minutes.<br>
<br></div>ralf<br><br></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Sun, Nov 3, 2013 at 8:30 PM, Robert Ransom <span dir=3D=
"ltr">&lt;<a href=3D"mailto:rransom.8774@gmail.com" target=3D"_blank">rrans=
om.8774@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 11/3/13, Ralf Skyper Ka=
iser &lt;<a href=3D"mailto:skyper@thc.org">skyper@thc.org</a>&gt; wrote:<br=
>
<br>
&gt;&gt; * Applications can also use renegotiation-based rekeying to improv=
e<br>
&gt;&gt; forward secrecy; for example, the Mixminion specification<br>
&gt;&gt; (&lt;<br>
&gt;&gt; <a href=3D"https://github.com/nmathewson/mixminion-doc/blob/a66121=
2831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt" target=3D"_blank">=
https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b263=
4ca16452e3aeec/spec/minion-spec.txt</a><br>

&gt;&gt; &gt;,<br>
&gt;&gt; section 4, line 1040) requires that relay-to-relay TLS connections=
 be<br>
&gt;&gt; rekeyed using renegotiation every 15 minutes for this purpose.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Mixminion falsely assume =A0that the security degrades if a connection=
 is<br>
&gt; live for more than 15 minutes. That&#39;s security wise not true. In t=
oday&#39;s<br>
&gt; security design (TLS) the negotiated session key material is secure fo=
r<br>
&gt; years (if not decades). Gone are the times when DES was used and DES c=
ould<br>
&gt; be cracked in 24h and it was desirable to use a new DES key every 24 h=
ours.<br>
&gt; Gone. Gone Gone.<br>
&gt;<br>
&gt; If you negotiate session keys that could be cracked within a year you<=
br>
&gt; should not have negotiated those sessions keys in the first place.<br>
<br>
</div>Mixminion correctly assumes that anyone who obtains a session key by<=
br>
compromising a server can use that key to decrypt all traffic<br>
protected by it, no matter how long brute-force search would have<br>
taken to find the key.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Robert Ransom<br>
</font></span></blockquote></div><br></div>

--001a11c1ead60d4ff404ea4def98--

From skyper@thc.org  Sun Nov  3 15:23:20 2013
Return-Path: <skyper@thc.org>
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 E8C7E11E8105 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 0NOArxrdOMZ9 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:23:16 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 49D4F11E824E for <tls@ietf.org>; Sun,  3 Nov 2013 15:23:11 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id tp5so10937377ieb.2 for <tls@ietf.org>; Sun, 03 Nov 2013 15:23:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7XpyPNEqTY03svTYk34Y5wUjyzmaPdO8nb9SQYST1Qw=; b=EvL0/ss3Lh+tmpqC8zwzojwgU8C78PbLVybpH1PiaGGq+DDOH5IZc452m+UTq/uOSO Ijj90t0wHKpQkNQst1a0gZRz3pvA2lPfKGQn6IqMOl/v+e6NVCIx/Dn4jWpSrbpBjd3D 02Fc+RDVLcnFbZgP5gjxsKg7rQDHtHS7FUzhs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7XpyPNEqTY03svTYk34Y5wUjyzmaPdO8nb9SQYST1Qw=; b=Nq0gKMq0rTkQvQM40XK+4OvTplYLA0JASRfN6YHzuszHumBRzOqDUMGoAKWow0wZl8 cr5l9wGvE0m/GZYYrtIWd8VrbXL9mlJP8+wA7cGbsEHZk8qnsP0htnxLqQr5nbemkiX/ zQdx2twL5X29wUc/r0QV3n8zHVVDUBDlkJaI9fvwocoAMyqxd6F8dQlBdpDJAS9dxzLG yDhWgakTHE32o+OMMevJr9oiwRRHEh/gmcndTruNhDyebLNEkSXOByDWiSCZQlu2ehYr w3YObm+AqIZLmgY5Rmg7NFn17nEjKXnxQdUN8R/E7gVh8bCt6/jLgPHjhTdKfkQMv2lP S8OQ==
X-Gm-Message-State: ALoCoQnDHyB9rNiB7eeKvFjT7PZNRIZWVdJE/hAHQoF819GQg3tBhuMGup7hMqoVCSFKyi5FzmdW
MIME-Version: 1.0
X-Received: by 10.50.128.137 with SMTP id no9mr9845622igb.36.1383520990815; Sun, 03 Nov 2013 15:23:10 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 15:23:10 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com>
Date: Sun, 3 Nov 2013 23:23:10 +0000
Message-ID: <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary=047d7b10cf0d3291cb04ea4e1542
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 23:23:21 -0000

--047d7b10cf0d3291cb04ea4e1542
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Yoav,

i agree with the UI issue. That's the only use that I can see where
renegotiation is useful.

I would guess here that 99% of all TLS users (if not 99.99%) do not need
this feature.

The 99.99% of all users would have to carry the risk of complexity to
satisfy the need of the 0.01% of users.

There are hopefully other ways to satisfy the need of the 0.01% without the
99.99% of us having to take an extra risk (complexity). (Anyone? Ideas are
welcome...).

(ps when i'm speaking about complexity i do not mean the working hours it
would take to write the code [earlier replies by somebody indicated this]
but rather the security complexity [making mistakes and auditing a
process/procedures/... that is rarely used]).

regards,

ralf




On Sun, Nov 3, 2013 at 7:18 PM, Yoav Nir <ynir@checkpoint.com> wrote:

>
> On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>
> > Hi,
> >
> > avoid renegotiation. It serves no purpose and only adds complexity. It
> is so much more secure to kill and re-establish the TLS if the counters r=
un
> out instead of renegotiating.
> >
>
> Hi, Ralf
>
> The one use of renegotiation that I'm aware of, is for overcoming a UI
> issue in browsers. If you do a TLS handshake with mutual authentication (=
so
> the server sends a CertReq), the browser pops up a dialog box with all th=
e
> certificates you might have. Website designers with to avoid that,
> especially on the welcome screen, so the web server does not send a
> CertReq. Instead, they present a welcome screen with a button or link tha=
t
> says "Login with certificates" Clicking that performs a regular SSL
> handshake (or does nothing at all if the connection is already
> established), but when the request comes in ("GET /login_with_certs
> HTTP/1.1"), the web server sends a HELLO_REQUEST, and in the resulting
> handshake it sends the CertReq, so the pop-up appears when the user *is*
> expecting it.
>
> I totally agree that renegotiation for rekeying is useless for people who
> are not doing DES-CBC and 3DES-CBC. It's even superfluous for them in mos=
t
> cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in
> 3DES. How many sites do you browse with 4 GB?  Maybe downloading stuff=85=
)
>
> But before we can drop renegotiation from the standards, or recommend tha=
t
> implementors don't implement it, we need an alternate mechanism to upgrad=
e
> from server-authenticated to mutually-authenticated within the same
> session. That is a real market need. How about allowing a CertReq sent fr=
om
> the server to the client in the middle of a connection, followed by the
> client sending a Certificate and Certificate Verify. For simplicity, we
> could always do that after the Finished, so that it's always
> Server-authenticated session when the Finished is sent.
>
> Yoav
>
>

--047d7b10cf0d3291cb04ea4e1542
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi Yoav,<br><br>i agree with the UI issue. That&=
#39;s the only use that I can see where renegotiation is useful.<br><br></d=
iv>I would guess here that 99% of all TLS users (if not 99.99%) do not need=
 this feature. <br>
<br>The 99.99% of all users would have to carry the risk of complexity to s=
atisfy the need of the 0.01% of users.<br><br></div><div>There are hopefull=
y other ways to satisfy the need of the 0.01% without the 99.99% of us havi=
ng to take an extra risk (complexity). (Anyone? Ideas are welcome...).<br>
<br>(ps when i&#39;m speaking about complexity i do not mean the working ho=
urs it would take to write the code [earlier replies by somebody indicated =
this] but rather the security complexity [making mistakes and auditing a pr=
ocess/procedures/... that is rarely used]).<br>
</div><br>regards,<br><br>ralf<br><br><div><br></div></div><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Sun, Nov 3, 2013 at 7:18 P=
M, Yoav Nir <span dir=3D"ltr">&lt;<a href=3D"mailto:ynir@checkpoint.com" ta=
rget=3D"_blank">ynir@checkpoint.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyper=
@thc.org">skyper@thc.org</a>&gt; wrote:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; avoid renegotiation. It serves no purpose and only adds complexity. It=
 is so much more secure to kill and re-establish the TLS if the counters ru=
n out instead of renegotiating.<br>
&gt;<br>
<br>
</div>Hi, Ralf<br>
<br>
The one use of renegotiation that I&#39;m aware of, is for overcoming a UI =
issue in browsers. If you do a TLS handshake with mutual authentication (so=
 the server sends a CertReq), the browser pops up a dialog box with all the=
 certificates you might have. Website designers with to avoid that, especia=
lly on the welcome screen, so the web server does not send a CertReq. Inste=
ad, they present a welcome screen with a button or link that says &quot;Log=
in with certificates&quot; Clicking that performs a regular SSL handshake (=
or does nothing at all if the connection is already established), but when =
the request comes in (&quot;GET /login_with_certs HTTP/1.1&quot;), the web =
server sends a HELLO_REQUEST, and in the resulting handshake it sends the C=
ertReq, so the pop-up appears when the user *is* expecting it.<br>

<br>
I totally agree that renegotiation for rekeying is useless for people who a=
re not doing DES-CBC and 3DES-CBC. It&#39;s even superfluous for them in mo=
st cases (you&#39;re pretty save doing 500,000,000 blocks, and that&#39;s 4=
 GB in 3DES. How many sites do you browse with 4 GB? =A0Maybe downloading s=
tuff=85)<br>

<br>
But before we can drop renegotiation from the standards, or recommend that =
implementors don&#39;t implement it, we need an alternate mechanism to upgr=
ade from server-authenticated to mutually-authenticated within the same ses=
sion. That is a real market need. How about allowing a CertReq sent from th=
e server to the client in the middle of a connection, followed by the clien=
t sending a Certificate and Certificate Verify. For simplicity, we could al=
ways do that after the Finished, so that it&#39;s always Server-authenticat=
ed session when the Finished is sent.<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Yoav<br>
<br>
</font></span></blockquote></div><br></div>

--047d7b10cf0d3291cb04ea4e1542--

From watsonbladd@gmail.com  Sun Nov  3 15:28:19 2013
Return-Path: <watsonbladd@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 4703811E8250 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level: 
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.046,  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 KioMvLhi+2Pf for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:28:18 -0800 (PST)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7507911E824E for <tls@ietf.org>; Sun,  3 Nov 2013 15:28:15 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id z12so1472910wgg.12 for <tls@ietf.org>; Sun, 03 Nov 2013 15:28:14 -0800 (PST)
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:content-transfer-encoding; bh=cIFDsPQFNtY3vj5/IQjDfntmGCXCRSxeW/HsOoLq0n4=; b=QZW9RXGwxECaAA6CFPASzMqBSY01WI8cxt/zOjno2JT24Nre5gLvOgltZB2Zb4yCZV qSB2oj3dkVtMVX2RrgEB9OqWOWhhnvq6anUG602jKtblnf9zgvsqCDVAaXC5HPfYx9vQ vl1c/8mpqcGD8ZwTdazw00bykUP98IbiVZXqnjwcZw7+Y7UemtOzVzP2FJppbn+gITNg 7gYNU55aFkdSWyVTMwD26gmchKUlRBgMGSQ1Q2ORnfklR31eAaVYNynBB4SAuJssheL9 ysXQm6bi4ot3zMZtNp0KC2zGWfU7y4SmjFZXPYf0sJvgTeUrmb6LaZ0yToCCYVMvc9dC LZIw==
MIME-Version: 1.0
X-Received: by 10.180.12.111 with SMTP id x15mr2380064wib.0.1383521294530; Sun, 03 Nov 2013 15:28:14 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sun, 3 Nov 2013 15:28:14 -0800 (PST)
In-Reply-To: <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com> <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com>
Date: Sun, 3 Nov 2013 15:28:14 -0800
Message-ID: <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 23:28:19 -0000

On Sun, Nov 3, 2013 at 3:23 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> Hi Yoav,
>
> i agree with the UI issue. That's the only use that I can see where
> renegotiation is useful.
>
> I would guess here that 99% of all TLS users (if not 99.99%) do not need
> this feature.
>
> The 99.99% of all users would have to carry the risk of complexity to
> satisfy the need of the 0.01% of users.
>
> There are hopefully other ways to satisfy the need of the 0.01% without t=
he
> 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas ar=
e
> welcome...).
Kick it into the application layer.
>
> (ps when i'm speaking about complexity i do not mean the working hours it
> would take to write the code [earlier replies by somebody indicated this]
> but rather the security complexity [making mistakes and auditing a
> process/procedures/... that is rarely used]).
>
> regards,
>
> ralf
>
>
>
>
> On Sun, Nov 3, 2013 at 7:18 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>>
>>
>> On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>>
>> > Hi,
>> >
>> > avoid renegotiation. It serves no purpose and only adds complexity. It
>> > is so much more secure to kill and re-establish the TLS if the counter=
s run
>> > out instead of renegotiating.
>> >
>>
>> Hi, Ralf
>>
>> The one use of renegotiation that I'm aware of, is for overcoming a UI
>> issue in browsers. If you do a TLS handshake with mutual authentication =
(so
>> the server sends a CertReq), the browser pops up a dialog box with all t=
he
>> certificates you might have. Website designers with to avoid that,
>> especially on the welcome screen, so the web server does not send a Cert=
Req.
>> Instead, they present a welcome screen with a button or link that says
>> "Login with certificates" Clicking that performs a regular SSL handshake=
 (or
>> does nothing at all if the connection is already established), but when =
the
>> request comes in ("GET /login_with_certs HTTP/1.1"), the web server send=
s a
>> HELLO_REQUEST, and in the resulting handshake it sends the CertReq, so t=
he
>> pop-up appears when the user *is* expecting it.
>>
>> I totally agree that renegotiation for rekeying is useless for people wh=
o
>> are not doing DES-CBC and 3DES-CBC. It's even superfluous for them in mo=
st
>> cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in 3=
DES.
>> How many sites do you browse with 4 GB?  Maybe downloading stuff=E2=80=
=A6)
>>
>> But before we can drop renegotiation from the standards, or recommend th=
at
>> implementors don't implement it, we need an alternate mechanism to upgra=
de
>> from server-authenticated to mutually-authenticated within the same sess=
ion.
>> That is a real market need. How about allowing a CertReq sent from the
>> server to the client in the middle of a connection, followed by the clie=
nt
>> sending a Certificate and Certificate Verify. For simplicity, we could
>> always do that after the Finished, so that it's always Server-authentica=
ted
>> session when the Finished is sent.
>>
>> Yoav
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From ynir@checkpoint.com  Sun Nov  3 15:42:43 2013
Return-Path: <ynir@checkpoint.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 7A5D411E8258 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.503
X-Spam-Level: 
X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 tOa2-MQq1DRu for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:42:37 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F331811E8255 for <tls@ietf.org>; Sun,  3 Nov 2013 15:42:24 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA3Nfxlf023208; Mon, 4 Nov 2013 01:41:59 +0200
X-CheckPoint: {5276DDFE-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 01:41:59 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngUoMjfWHp8eUeJG+rmdHIlV5oPTiyAgAFPL4CAAwGAAIAAJYkAgABEdgCAAAFqAIAAA9YA
Date: Sun, 3 Nov 2013 23:41:58 +0000
Message-ID: <4F215492-A376-45BD-A310-913B6BE97A36@checkpoint.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com> <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com> <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
In-Reply-To: <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.122]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1FE081322174E741AA90763B9CB95162@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 23:42:43 -0000

On Nov 3, 2013, at 3:28 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Sun, Nov 3, 2013 at 3:23 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote=
:
>> Hi Yoav,
>>=20
>> i agree with the UI issue. That's the only use that I can see where
>> renegotiation is useful.
>>=20
>> I would guess here that 99% of all TLS users (if not 99.99%) do not need
>> this feature.
>>=20
>> The 99.99% of all users would have to carry the risk of complexity to
>> satisfy the need of the 0.01% of users.
>>=20
>> There are hopefully other ways to satisfy the need of the 0.01% without =
the
>> 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas a=
re
>> welcome...).
> Kick it into the application layer.

Do you mean HTTP or the actual application?

Neither of them has all the cruft that is involved in accepting certificate=
s (ASN.1, revocation validation, etc). So do we reduce complexity a little =
for TLS, at the expense of a huge increase in complexity for higher layers?

The security of the system depends in part on the complexity, but that's th=
e complexity of the whole system, not of a particular component. Kicking th=
e complexity around from one component to another only helps if that makes =
for a more logical separation. Moving client authentication into another la=
yer doesn't do that.

Yoav


From skyper@thc.org  Sun Nov  3 15:48:21 2013
Return-Path: <skyper@thc.org>
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 632E111E8259 for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 d8SsF7NKcEWk for <tls@ietfa.amsl.com>; Sun,  3 Nov 2013 15:48:17 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4132A11E8252 for <tls@ietf.org>; Sun,  3 Nov 2013 15:48:17 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so11216624ieb.33 for <tls@ietf.org>; Sun, 03 Nov 2013 15:48:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R7s2dLvPqG/v5Lez32XKcSgvniA6UanDH2lA8lmQyO4=; b=G81mTnwucmG6dFfkFmW6WLbp/l7N5+/P6JUajAWxH47i90lbZvz/uQoL5LGN79+Jk9 z2KIQKETiGRgSKG+yo2at58V2/SoJAJ0MboxkU4SjqHLTMWo9bUSUTSNemanx8Jd6Q8b BzEiOtZolexlwj9zb5D0gj4pD1T+Cf7OOxfoU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R7s2dLvPqG/v5Lez32XKcSgvniA6UanDH2lA8lmQyO4=; b=VirSNujE8yU+PNsXLhb6XrTGjQpkP4I4rEGR6vOvLlWttPXypPNKn0vyQexcWPI+zM cyUckN++fbGah2pmBJpz4yZVX4U1vgLCs8wHHW/7RUbfK8/m0MHaXpTBL9nqrNlWqqnA fFfeRHE6NZmoOFPSROxCth0P4Ha6Vti8Dd1i0274uwPlcuyywHZRmaJ2TExnlTXklN90 1Dd5qjxG6eCT76YsfBGvR8Vm2rl1lCnGAKSF/8hCJFPMBgCwWztaUkLYHJ7DU8IfAoIO zJ5Rg5SwtGQz4o7VzidXaRBzpAxyvPefCYJQB97gRHPZ87/a3SSmQpS1Vne30YQQO/Id poYA==
X-Gm-Message-State: ALoCoQkrErE7ZWKmniley/80ASele+iURaMWe1ShDJDvuwS6qcNoyjAA8hNkjsCzNNWFOXQm9e5g
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr2333052igb.46.1383522496780; Sun, 03 Nov 2013 15:48:16 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 15:48:16 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com> <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com> <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
Date: Sun, 3 Nov 2013 23:48:16 +0000
Message-ID: <CA+BZK2q9BjjiHLXWsA3cc7Qma8QUv5z-qiiA-A6pimwPPbX3=Q@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b2e0d1ff5b14904ea4e6e6e
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Sun, 03 Nov 2013 23:48:21 -0000

--047d7b2e0d1ff5b14904ea4e6e6e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

Yoav, Waton did not mean to 'move the entire client side auth' into the
application layer.

Instead it is possible to remove renegotiation from the standard and still
be able to authenticate clients by certificate without UI pop up.

In the earlier example with HTTPS and 'Login with certificate button': The
button could indicate to the client to establish a new TLS connection and
authenticate the client by certificate (without the need of renegotiation).
There are endless options to make this neatly without UI pop-up as well.


regards,

ralf



On Sun, Nov 3, 2013 at 11:28 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Sun, Nov 3, 2013 at 3:23 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote=
:
> > Hi Yoav,
> >
> > i agree with the UI issue. That's the only use that I can see where
> > renegotiation is useful.
> >
> > I would guess here that 99% of all TLS users (if not 99.99%) do not nee=
d
> > this feature.
> >
> > The 99.99% of all users would have to carry the risk of complexity to
> > satisfy the need of the 0.01% of users.
> >
> > There are hopefully other ways to satisfy the need of the 0.01% without
> the
> > 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas
> are
> > welcome...).
> Kick it into the application layer.
> >
> > (ps when i'm speaking about complexity i do not mean the working hours =
it
> > would take to write the code [earlier replies by somebody indicated thi=
s]
> > but rather the security complexity [making mistakes and auditing a
> > process/procedures/... that is rarely used]).
> >
> > regards,
> >
> > ralf
> >
> >
> >
> >
> > On Sun, Nov 3, 2013 at 7:18 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> >>
> >>
> >> On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> >>
> >> > Hi,
> >> >
> >> > avoid renegotiation. It serves no purpose and only adds complexity. =
It
> >> > is so much more secure to kill and re-establish the TLS if the
> counters run
> >> > out instead of renegotiating.
> >> >
> >>
> >> Hi, Ralf
> >>
> >> The one use of renegotiation that I'm aware of, is for overcoming a UI
> >> issue in browsers. If you do a TLS handshake with mutual authenticatio=
n
> (so
> >> the server sends a CertReq), the browser pops up a dialog box with all
> the
> >> certificates you might have. Website designers with to avoid that,
> >> especially on the welcome screen, so the web server does not send a
> CertReq.
> >> Instead, they present a welcome screen with a button or link that says
> >> "Login with certificates" Clicking that performs a regular SSL
> handshake (or
> >> does nothing at all if the connection is already established), but whe=
n
> the
> >> request comes in ("GET /login_with_certs HTTP/1.1"), the web server
> sends a
> >> HELLO_REQUEST, and in the resulting handshake it sends the CertReq, so
> the
> >> pop-up appears when the user *is* expecting it.
> >>
> >> I totally agree that renegotiation for rekeying is useless for people
> who
> >> are not doing DES-CBC and 3DES-CBC. It's even superfluous for them in
> most
> >> cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in
> 3DES.
> >> How many sites do you browse with 4 GB?  Maybe downloading stuff=85)
> >>
> >> But before we can drop renegotiation from the standards, or recommend
> that
> >> implementors don't implement it, we need an alternate mechanism to
> upgrade
> >> from server-authenticated to mutually-authenticated within the same
> session.
> >> That is a real market need. How about allowing a CertReq sent from the
> >> server to the client in the middle of a connection, followed by the
> client
> >> sending a Certificate and Certificate Verify. For simplicity, we could
> >> always do that after the Finished, so that it's always
> Server-authenticated
> >> session when the Finished is sent.
> >>
> >> Yoav
> >>
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>

--047d7b2e0d1ff5b14904ea4e6e6e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi,<br><br></div><div>Yoav, Waton did not mean t=
o &#39;move the entire client side auth&#39; into the application layer.<br=
><br></div><div>Instead it is possible to remove renegotiation from the sta=
ndard and still be able to authenticate clients by certificate without UI p=
op up.<br>
<br></div><div>In the earlier example with HTTPS and &#39;Login with certif=
icate button&#39;: The button could indicate to the client to establish a n=
ew TLS connection and authenticate the client by certificate (without the n=
eed of renegotiation). There are endless options to make this neatly withou=
t UI pop-up as well.<br>
<br></div><br></div><div><div>regards,<br><br>ralf<br><br></div></div></div=
><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Nov =
3, 2013 at 11:28 PM, Watson Ladd <span dir=3D"ltr">&lt;<a href=3D"mailto:wa=
tsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail.com</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Sun, Nov 3, 2013 at 3:2=
3 PM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyper@thc.org">skyper@thc.o=
rg</a>&gt; wrote:<br>

&gt; Hi Yoav,<br>
&gt;<br>
&gt; i agree with the UI issue. That&#39;s the only use that I can see wher=
e<br>
&gt; renegotiation is useful.<br>
&gt;<br>
&gt; I would guess here that 99% of all TLS users (if not 99.99%) do not ne=
ed<br>
&gt; this feature.<br>
&gt;<br>
&gt; The 99.99% of all users would have to carry the risk of complexity to<=
br>
&gt; satisfy the need of the 0.01% of users.<br>
&gt;<br>
&gt; There are hopefully other ways to satisfy the need of the 0.01% withou=
t the<br>
&gt; 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas=
 are<br>
&gt; welcome...).<br>
</div>Kick it into the application layer.<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt;<br>
&gt; (ps when i&#39;m speaking about complexity i do not mean the working h=
ours it<br>
&gt; would take to write the code [earlier replies by somebody indicated th=
is]<br>
&gt; but rather the security complexity [making mistakes and auditing a<br>
&gt; process/procedures/... that is rarely used]).<br>
&gt;<br>
&gt; regards,<br>
&gt;<br>
&gt; ralf<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Nov 3, 2013 at 7:18 PM, Yoav Nir &lt;<a href=3D"mailto:ynir@ch=
eckpoint.com">ynir@checkpoint.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser &lt;<a href=3D"mail=
to:skyper@thc.org">skyper@thc.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; Hi,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; avoid renegotiation. It serves no purpose and only adds compl=
exity. It<br>
&gt;&gt; &gt; is so much more secure to kill and re-establish the TLS if th=
e counters run<br>
&gt;&gt; &gt; out instead of renegotiating.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi, Ralf<br>
&gt;&gt;<br>
&gt;&gt; The one use of renegotiation that I&#39;m aware of, is for overcom=
ing a UI<br>
&gt;&gt; issue in browsers. If you do a TLS handshake with mutual authentic=
ation (so<br>
&gt;&gt; the server sends a CertReq), the browser pops up a dialog box with=
 all the<br>
&gt;&gt; certificates you might have. Website designers with to avoid that,=
<br>
&gt;&gt; especially on the welcome screen, so the web server does not send =
a CertReq.<br>
&gt;&gt; Instead, they present a welcome screen with a button or link that =
says<br>
&gt;&gt; &quot;Login with certificates&quot; Clicking that performs a regul=
ar SSL handshake (or<br>
&gt;&gt; does nothing at all if the connection is already established), but=
 when the<br>
&gt;&gt; request comes in (&quot;GET /login_with_certs HTTP/1.1&quot;), the=
 web server sends a<br>
&gt;&gt; HELLO_REQUEST, and in the resulting handshake it sends the CertReq=
, so the<br>
&gt;&gt; pop-up appears when the user *is* expecting it.<br>
&gt;&gt;<br>
&gt;&gt; I totally agree that renegotiation for rekeying is useless for peo=
ple who<br>
&gt;&gt; are not doing DES-CBC and 3DES-CBC. It&#39;s even superfluous for =
them in most<br>
&gt;&gt; cases (you&#39;re pretty save doing 500,000,000 blocks, and that&#=
39;s 4 GB in 3DES.<br>
&gt;&gt; How many sites do you browse with 4 GB? =A0Maybe downloading stuff=
=85)<br>
&gt;&gt;<br>
&gt;&gt; But before we can drop renegotiation from the standards, or recomm=
end that<br>
&gt;&gt; implementors don&#39;t implement it, we need an alternate mechanis=
m to upgrade<br>
&gt;&gt; from server-authenticated to mutually-authenticated within the sam=
e session.<br>
&gt;&gt; That is a real market need. How about allowing a CertReq sent from=
 the<br>
&gt;&gt; server to the client in the middle of a connection, followed by th=
e client<br>
&gt;&gt; sending a Certificate and Certificate Verify. For simplicity, we c=
ould<br>
&gt;&gt; always do that after the Finished, so that it&#39;s always Server-=
authenticated<br>
&gt;&gt; session when the Finished is sent.<br>
&gt;&gt;<br>
&gt;&gt; Yoav<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
</div></div><div class=3D"im HOEnZb">&gt; _________________________________=
______________<br>
&gt; TLS mailing list<br>
&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
<br>
<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<br>
&quot;Those who would give up Essential Liberty to purchase a little<br>
Temporary Safety deserve neither =A0Liberty nor Safety.&quot;<br>
-- Benjamin Franklin<br>
</div></div></blockquote></div><br></div>

--047d7b2e0d1ff5b14904ea4e6e6e--

From john.mattsson@ericsson.com  Mon Nov  4 10:17:16 2013
Return-Path: <john.mattsson@ericsson.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 EE88E11E820A for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 10:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.358
X-Spam-Level: 
X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 5zbvR3egWa-Z for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 10:17:10 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF711E8162 for <TLS@ietf.org>; Mon,  4 Nov 2013 10:17:05 -0800 (PST)
X-AuditID: c1b4fb30-b7eff8e000006d14-4d-5277e49e3f8d
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 57.13.27924.E94E7725; Mon,  4 Nov 2013 19:17:02 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.88]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Mon, 4 Nov 2013 19:17:01 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: Comments on draft-ietf-tls-applayerprotoneg-03
Thread-Index: Ac7Zh9lj/ZIF1PUMQyaqF9nf3z7OeQ==
Date: Mon, 4 Nov 2013 18:17:01 +0000
Message-ID: <CAAB765F71FCD344B6BABC031C19EC490EE793@ESESSMB307.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvje68J+VBBvOeiFh8Ot/F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIMHZjAVzOGqmPi1m7mBcQ1HFyMHh4SAicS8TeVdjJxAppjE hXvr2boYuTiEBA4xSsx+38YE4SxilOhb95odpIpNwEBi7p4GNpBmEQFFiU+fs0HCwgLmEicu H2ABsUUEbCQuft/PCGHrSdz8/RTMZhFQkZj69wU7SCuvgLfEh7lBIGFGoL3fT61hArGZBcQl bj2ZzwRxj4DEkj3nmSFsUYmXj/+xQthKEotuf4aq15O4MXUKG4StLbFs4Wuwel4BQYmTM5+w TGAUnoVk7CwkLbOQtMxC0rKAkWUVI3tuYmZOern5JkZgCB/c8ttgB+Om+2KHGKU5WJTEeT+8 dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLgg//mH5l8HSo6anZBN7DhZ9dX+9sonitqu nM+9y92XVu4W+aff/vGQsbTfsh1z+yfGRx5If6ou+Fv65j+x/O5oDdX5va8/7tl0pTKVS+rP oSv58cV39e/OMTu74nzv1mMirs43tkpkCT9863Pkgg/7/e8v4wIUS6KXOBVfOnvKxEyd3732 XpkSS3FGoqEWc1FxIgAKp8LqLwIAAA==
Subject: [TLS] Comments on draft-ietf-tls-applayerprotoneg-03
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: Mon, 04 Nov 2013 18:17:16 -0000

Hi,=20

Some minor comments on draft-ietf-tls-applayerprotoneg-03

/John

- [Section 3.1]
"Implementations MUST ensure that an empty string is not included and that =
no byte strings are truncated."

How does an implementation differentiate between the byte string "spdy/10" =
truncated to "spdy/1" and the non-truncated string "spdy/1"?  ;)

I assume what is meant is that the implementation MUST ensure that the leng=
th of protocol_name_list is correct. But isn't that already handled by RFC5=
246 for both client and server (which sends a decode_error)? I suggest to r=
eformulate or remove.

- [Section 3.2]
Seems to be an extra line break that should be removed:=20

enum {
    no_application_protocol(120), (255)
} AlertDescription;


---------------------------------------------------------------------------=
---------
JOHN MATTSSON
MSc Engineering Physics, MSc Business Administration and Economics=20
Senior Researcher, Security=20

Ericsson AB
Security Research
F=E4r=F6gatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501
john.mattsson@ericsson.com
www.ericsson.com




This Communication is Confidential. We only send and receive email on the b=
asis of the terms set out at www.ericsson.com/email_disclaimer=20



From Andrei.Popov@microsoft.com  Mon Nov  4 10:57:31 2013
Return-Path: <Andrei.Popov@microsoft.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 0CFD111E81C4 for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 10:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 eDoENvSAAPtq for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 10:57:26 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 12B5321E805F for <TLS@ietf.org>; Mon,  4 Nov 2013 10:57:25 -0800 (PST)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 4 Nov 2013 18:57:19 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.243]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.5]) with mapi id 15.00.0785.001; Mon, 4 Nov 2013 18:57:18 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: John Mattsson <john.mattsson@ericsson.com>, "TLS@ietf.org" <TLS@ietf.org>
Thread-Topic: Comments on draft-ietf-tls-applayerprotoneg-03
Thread-Index: Ac7Zh9lj/ZIF1PUMQyaqF9nf3z7OeQABwRkM
Date: Mon, 4 Nov 2013 18:57:18 +0000
Message-ID: <4ad5556dfe40498eb232685808eee1dd@BL2PR03MB194.namprd03.prod.outlook.com>
References: <CAAB765F71FCD344B6BABC031C19EC490EE793@ESESSMB307.ericsson.se>
In-Reply-To: <CAAB765F71FCD344B6BABC031C19EC490EE793@ESESSMB307.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [64.114.24.114]
x-forefront-prvs: 0020414413
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(377454003)(83072001)(76576001)(80022001)(56816003)(77096001)(51856001)(46102001)(81342001)(81542001)(74316001)(76786001)(76796001)(2656002)(15975445006)(76482001)(59766001)(77982001)(87266001)(79102001)(63696002)(56776001)(54316002)(81686001)(65816001)(81816001)(66066001)(74706001)(15974865002)(74662001)(74502001)(47446002)(74876001)(74366001)(33646001)(69226001)(80976001)(50986001)(19580405001)(85306002)(83322001)(19580395003)(53806001)(47976001)(47736001)(49866001)(54356001)(4396001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB196; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:64.114.24.114; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Subject: Re: [TLS] Comments on draft-ietf-tls-applayerprotoneg-03
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: Mon, 04 Nov 2013 18:57:31 -0000

Perhaps the intent was to say that the sender needs to ensure they're sendi=
ng  valid protocol IDs, but I'm not too keen on the way it's phrased either=
. I don't mind removing the part where it talks about truncation.=0A=
=0A=
Cheers,=0A=
=0A=
Andrei=0A=
________________________________________=0A=
From: tls-bounces@ietf.org <tls-bounces@ietf.org> on behalf of John Mattsso=
n <john.mattsson@ericsson.com>=0A=
Sent: Monday, November 04, 2013 10:17 AM=0A=
To: TLS@ietf.org=0A=
Subject: [TLS] Comments on draft-ietf-tls-applayerprotoneg-03=0A=
=0A=
Hi,=0A=
=0A=
Some minor comments on draft-ietf-tls-applayerprotoneg-03=0A=
=0A=
/John=0A=
=0A=
- [Section 3.1]=0A=
"Implementations MUST ensure that an empty string is not included and that =
no byte strings are truncated."=0A=
=0A=
How does an implementation differentiate between the byte string "spdy/10" =
truncated to "spdy/1" and the non-truncated string "spdy/1"?  ;)=0A=
=0A=
I assume what is meant is that the implementation MUST ensure that the leng=
th of protocol_name_list is correct. But isn't that already handled by RFC5=
246 for both client and server (which sends a decode_error)? I suggest to r=
eformulate or remove.=0A=
=0A=
- [Section 3.2]=0A=
Seems to be an extra line break that should be removed:=0A=
=0A=
enum {=0A=
    no_application_protocol(120), (255)=0A=
} AlertDescription;=0A=
=0A=
=0A=
---------------------------------------------------------------------------=
---------=0A=
JOHN MATTSSON=0A=
MSc Engineering Physics, MSc Business Administration and Economics=0A=
Senior Researcher, Security=0A=
=0A=
Ericsson AB=0A=
Security Research=0A=
F=E4r=F6gatan 6=0A=
SE-164 80 Stockholm, Sweden=0A=
Phone +46 10 71 43 501=0A=
SMS/MMS +46 76 11 53 501=0A=
john.mattsson@ericsson.com=0A=
www.ericsson.com=0A=
=0A=
=0A=
=0A=
=0A=
This Communication is Confidential. We only send and receive email on the b=
asis of the terms set out at www.ericsson.com/email_disclaimer=0A=
=0A=
=0A=
_______________________________________________=0A=
TLS mailing list=0A=
TLS@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tls=0A=

From dbrown@certicom.com  Mon Nov  4 12:21:35 2013
Return-Path: <dbrown@certicom.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 3AB3F21E808D for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 12:21:35 -0800 (PST)
X-Quarantine-ID: <AoemJk4hVLjA>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.32
X-Spam-Level: 
X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.021,  BAYES_00=-2.599, SARE_WEOFFER=0.3]
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 AoemJk4hVLjA for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 12:21:30 -0800 (PST)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6C11E82CA for <tls@ietf.org>; Mon,  4 Nov 2013 12:21:28 -0800 (PST)
Content-Type: multipart/mixed; boundary="===============0766314385=="
MIME-Version: 1.0
Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 04 Nov 2013 15:21:21 -0500
Received: from XCT110CNC.rim.net (10.65.161.210) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Nov 2013 15:21:21 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT110CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 15:21:21 -0500
From: Dan Brown <dbrown@certicom.com>
To: "'djb@cr.yp.to'" <djb@cr.yp.to>, "'tls@ietf.org'" <tls@ietf.org>
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOxuJRxn3XJXmgAkKRAg2ZE6kwf5n3qq2ggAC0kACAAKQ6QIAB8gaAgAcmnxGAE3vA8A==
Date: Mon, 4 Nov 2013 20:21:19 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BFA5CB@XMB116CNC.rim.net>
References: <523E176F.3050304@gmail.com> <52616365.1080108@nthpermutation.com> <20131023094710.32763.qmail@cr.yp.to>
In-Reply-To: <20131023094710.32763.qmail@cr.yp.to>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.249]
MIME-Version: 1.0
Subject: Re: [TLS] Safe ECC usage
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: Mon, 04 Nov 2013 20:21:35 -0000

--===============0766314385==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0171_01CED971.8330D330"

------=_NextPart_000_0171_01CED971.8330D330
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi again ECC in TLS enthusiasts,

Sorry to raise this very theoretical issue yet again, but I realized a 
stronger argument for one of my claims in this thread.


Claim:

The Brainpool 256-bit curve, as a remedy to a hypothetically manipulated P256, 
provides more security assurance than Curve25519, assuming faultless 
implementations.


Mildly formal argument for the claim above:

P256: Let us call the curve weakness, which we are hypothesizing here that the 
P256 seed has been exhaustively searched, i.e. manipulated, to have: the 
spectral weakness (a term inspired by spectre and prism).  For simplicity, let 
us initially assume that the best available process to manipulate P256 was 
exhaustive search of seed, and this had an a priori expected running time of 
2^w trial seeds.  (A more complex analysis might go further and postulate a 
weakness in the P256 curve generation algorithm, perhaps even in the SHA1 hash 
function used, but in this case I will still use 2^w for the number of seeds 
that must be tried under this more complicated situation.)

Brainpool: Under the fairly reasonable heuristic assumptions below, one can 
argue that the probability the Brainpool 256-bit curve is affected by the 
spectral weakness with probability about 2^(-w).   The heuristic assumptions 
here are the independence of spectral weakness from the curve generation 
algorithm and from the digits of pi and e, or any similar fundamental 
constants (with the wiggle contributing the about).   These assumptions are 
fairly mild assumption about the spectral weakness, in my opinion.

Curve25519: It can also be argued (and, as I understand it, has already been 
argued on the list) that Curve25519 is affected by the spectral weakness with 
probability about 2^(-w), under the either of the following assumptions: (1) 
the spectral weakness affects curves uniformly, or (2) the spectral attack 
would be very similar to known attacks, e.g. PH, MOV and SASS, and that the 
non-random features that Curve25519 displays, such as small coefficients, have 
no bearing whatsoever on those attacks, thereby rendering Curve25519 as safe 
as any random curve.

Brainpool vs Curve25519: Both of the assumptions above made for Curve25519 on 
the spectral attack are formally, and intuitively, stronger than the mild 
assumption made for Brainpool curve, therefore the assurance that Curve25519 
provides is weaker than that of Brainpool.


Much more informal asides:

As I, and others, have noted already in this thread, Curve25519 has very good 
resistance to 1st person attacks, i.e. it has rigidity, perhaps even more than 
Brainpool.  Unfortunately, that does not sufficient to rule out the spectral 
weakness affecting Curve25519, at least under the arguments above, except 
under quite strong assumptions.  Besides, I find it unreasonable to suspect a 
1st person attack from Curve25519 because even in the very unlikely event that 
DJB knew what the spectral weakness, or even some other weakness, was, I feel 
certain he would reveal it, not exploit it.

At one point in this thread, I mistakenly tried to apply something like the 
semiformal argument above for future attacks, rather than for the spectral 
weakness.  Indeed, under the spectral attack hypothesis, it is unnecessary to 
argue, or even further speculate, about the nature of a future attack, e.g. 
whether they are more likely to affect random or special curves.  Rather, 
under the spectral attack hypothesis, we presume that an attack already 
affects P256, and we may attempt to avoid it when choosing alternative curves, 
and must avoid it as best as possible if we offer those curves as being safe 
against the spectral attack.  In other words, when I argued that it was more 
prudent to use random curves, e.g. Brainpool than to use special curves, e.g. 
Curve25519, merely because one has to be pessimistic as possible in one's 
assumptions, I was right about spectral attack, but wrong about future 
attacks.  Just to be clear, this is not to say that I think it likely, or that 
the evidence points to it being likely, for the spectral weakeness to affect 
Curve25519.  What I am saying is that Brainpool seems to be designed, whether 
intentionally or not, in such a way to offer better assurance of avoiding the 
spectral weakness.

The Brainpool curve is a fixed curve, but seems to be nearly as pseudorandom 
as a fixed curve could be.  Nonetheless, using a random curve for every 
exchange, or pair of users, ought to be even safer than Brainpool, but would 
be too inefficient, for example, due to the cost of point counting.  But that 
issue seems to independent of the arguments for the claim above.

I alluded above to a more complicated situation in which the curve generation 
algorithm is weak.  This seems unlikely for many reasons, but this issue is 
independent of the main claim that Curve25519 relies on a strong assumption 
about the spectral attack.  Also, this issue starts to become a different one 
from pure manipulation.  Further, if this hypothesis goes so far as to 
postulate invertibility of SHA1, then we may need further consider other 
criteria on elliptic curves, such as resisting Cheon-type attacks.

Of course, many reasons remain to doubt the existence of a spectral attack, 
including: the extensive research efforts into ECC, the risk of standardizing 
curves one knows to be weak, many other curves and algorithms from the same 
sources not known to be weak or subject to manipulation.

It may be worthwhile for TLS to offer its users more guidance than just "here 
are some safe algorithms you can use".  Some TLS users may have a reasonable 
expectation of security from the available TLS algorithms, and perhaps even 
security levels, which is reasonable if only because of the S in TLS.  Some 
users may want to make their own decisions about security.  Yet others may 
seek guidance for specific security goals, hoping to find it the TLS specs. 
Naturally, nobody has a very strong incentive to commit to too strong security 
claims.  If TLS is to offer various curves as providing 128-bit security, then 
it might point to what the provisos behind each to guide users in their 
choice.


Suggestions for further discussion:

Perhaps, I am missing or misunderstanding an argument for Curve25519 avoiding 
the hypothesized spectral weakeness.  Please correct me as needed.

Perhaps, my security analysis for Brainpool is unconvincing or too vague. 
Maybe we can discuss further.  I suspect one could formalize it better, i.e. 
random oracle model, pseudorandom functions, etc.  Certainly, there is a 
logical leap from pseudorandom fixed to random, but this independent of the 
arguments above.

Perhaps, one really can quantify the amount of wiggle room in the curves for 
Brainpool and Curve25519 to get slightly different probabilities from 2^(-w), 
with Curve25519 having a lower probability.  That does not override the 
stronger assumptions being necessary, but may be an argument that the relative 
security between the two is incomparable.

Best regards,

Dan




------=_NextPart_000_0171_01CED971.8330D330
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw
ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l
dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz
WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu
ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy
czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH
jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH
An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw
CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME
AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww
FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6
MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu
YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw
U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp
b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp
bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH
MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0
RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG
KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R
BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN
o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2
ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg
k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G
Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC
BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB
GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN
Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ
FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D
QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna
iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp
yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg
Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3
mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq
6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN
9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh
vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr
UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0
hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG
AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW
aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov
Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k
b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j
UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu
cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ
KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2
fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf
+ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi
fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9
aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8
rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ
jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog
dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s
FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z
bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD
ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx
EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT
dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx
jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV
mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X
Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa
99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p
036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w
HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE
AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe
CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg
MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys
Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz
LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp
b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew
MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu
Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy
MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp
Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG
Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93
cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB
AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK
PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f
aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG
E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6
xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2
6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k
q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg
jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0
KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts
MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt
MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D
AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTA0
MjAyMTE5WjAjBgkqhkiG9w0BCQQxFgQULEB66gU40bbfjSQtb/hUeCgtN3owZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw
EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi
b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR
BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv
cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgJGRUj6gNnTC
WwuHS++3JQhi4yt7kSKW57TRIUe7A6irG1VWprA8Dk23oUU5z+j/tueXbgBOp8jP4B0qNqXdyYtT
fY6KEsSZTVYq03kFbYjkhklw5KJpL0qYLCtS33z3Z+0PtGF4+XAs9tmVP7cv1JBQDLj8J6zO7JG1
hcc00gEmAAAAAAAA

------=_NextPart_000_0171_01CED971.8330D330--

--===============0766314385==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
--===============0766314385==--

From mrex@sap.com  Mon Nov  4 16:37:07 2013
Return-Path: <mrex@sap.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 6671321E839C for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 16:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.103
X-Spam-Level: 
X-Spam-Status: No, score=-10.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 XeNIowMtBPEq for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 16:37:02 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE721E839F for <tls@ietf.org>; Mon,  4 Nov 2013 16:36:57 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rA50aqw1018075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Nov 2013 01:36:52 +0100 (MET)
In-Reply-To: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tue, 5 Nov 2013 01:36:52 +0100 (CET)
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: <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 05 Nov 2013 00:37:07 -0000

Ralf Skyper Kaiser wrote:
> 
> (An example are jabber servers using TLS. Most clients allow the user to
> accept any server certificate without verification. The jabber server has
> no way to detect which client performed proper certificate verification and
> CN<>URI match).

Huh?

What policy the client applies when checking the server's certificate
chain is none of the server's business.  This is entirely at the
discretion of the client.

-Martin

From skyper@thc.org  Mon Nov  4 18:03:37 2013
Return-Path: <skyper@thc.org>
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 76C3D21E819D for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 18:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 u+ORuxk5-JD2 for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 18:03:33 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B919411E8269 for <tls@ietf.org>; Mon,  4 Nov 2013 18:03:31 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id ar20so13546824iec.26 for <tls@ietf.org>; Mon, 04 Nov 2013 18:03:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hcNqyMFTdZESF6O2UlTdt1WsT/h5sMT/TLNYjTUqbLc=; b=OVOIf1MP61KDUztofTj+/7H+KEkPdNwLV/bae/80+M7NMjOpjtMJuORF20vUSoy51D kJI+33ElHd2ilVvllFTPdHNYud2kTUDiZ8FGTh2JW/tD+eW32Nvnv/ncabfIC5h5Zt+7 xWURQHVot3Mou5wH4Qm8kZ48/3MPEF8YXwCw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hcNqyMFTdZESF6O2UlTdt1WsT/h5sMT/TLNYjTUqbLc=; b=LHblBOCU4IW3Opvs9sxveZEW0HRrtT+wDUrrN679o65WyPRSFvQGxsNuavqJYPWq7t dwSj8yWGv3bf1P4+b8NaapC9eEDp/zVgsOSKQbgYWMDUTOzWBKnvlbwvAxUbEDrI/p8U eoerTYjZiLa64eFEIDp/WrTUhqWHaXf26ldYenIeZKqNrAQ4oxgZFzGRQUK7+3c7RKzM bWtDYdLhzq+UILYv6ClowxROgQYzMeNl5GymO0Tk1X906ge8F1Dd3F85IXLsPUOask7K jFAQlf50V8dmKMT0csE9jqOQcE0UvqU9Z0mosOpVkl0bjMbDl1DGZKDbrp4broz5iYXw xXwg==
X-Gm-Message-State: ALoCoQnpiucPUrkDLChxtxyH+fKEsK0C7wSF/+wCIPlOvNB6SS1mTpO1j697GDnQBBu4/YpkMxLw
MIME-Version: 1.0
X-Received: by 10.42.190.142 with SMTP id di14mr3018866icb.45.1383617011249; Mon, 04 Nov 2013 18:03:31 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Mon, 4 Nov 2013 18:03:31 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp>
Date: Tue, 5 Nov 2013 02:03:31 +0000
Message-ID: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=20cf303ea4b876145904ea6470e3
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 02:03:37 -0000

--20cf303ea4b876145904ea6470e3
Content-Type: text/plain; charset=ISO-8859-1

Hi Martin,

exactly, and that's the problem: "What policy the client applies when
checking the server's certificate chain is at the discretion of the client."

There is no easy way to solve this. The client (and user) can always cheat
if he wants to. But we are not discussing dishonest users. Let's assume a
honest user who wants to connect to a TLS service securely.

The user uses a TLS client (say pidgin for jabber). This client has several
options to configure the TLS connection. These options include if the chain
should be checked at all, if the user is allowed to accept self-signed
certificates and against which CA-bundle to verify the server's certificate.

A securely configured TLS client would verify the certificate chain.

The server has no way to check if the TLS client is configured securely.
The server blindly trusts the client that it is configured securely. That
does not scale. Users make mistakes. Users will connect to a service not
knowing that the connection is not secure (even over TLS) because they did
not configure the TLS correctly.

A flag that would tell the server how the client has verified the
connection would enable the server to block the user from using the service
UNTIL his client is configured securely.

Tata. Better security.

regards,

ralf



On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <mrex@sap.com> wrote:

> Ralf Skyper Kaiser wrote:
> >
> > (An example are jabber servers using TLS. Most clients allow the user to
> > accept any server certificate without verification. The jabber server has
> > no way to detect which client performed proper certificate verification
> and
> > CN<>URI match).
>
> Huh?
>
> What policy the client applies when checking the server's certificate
> chain is none of the server's business.  This is entirely at the
> discretion of the client.
>
> -Martin
>

--20cf303ea4b876145904ea6470e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi Martin,<br><br></div>exactly, and that&#=
39;s the problem: &quot;What policy the client applies when checking the se=
rver&#39;s certificate chain is at the discretion of the client.&quot;<br>
<br>There is no easy way to solve this. The client (and user) can always ch=
eat if he wants to. But we are not discussing dishonest users. Let&#39;s as=
sume a honest user who wants to connect to a TLS service securely.<br><br>
The user uses a TLS client (say pidgin for jabber). This client has several=
 options to configure the TLS connection. These options include if the chai=
n should be checked at all, if the user is allowed to accept self-signed ce=
rtificates and against which CA-bundle to verify the server&#39;s certifica=
te.<br>
<br>A securely configured TLS client would verify the certificate chain.<br=
><br>The server has no way to check if the TLS client is configured securel=
y. The server blindly trusts the client that it is configured securely. Tha=
t does not scale. Users make mistakes. Users will connect to a service not =
knowing that the connection is not secure (even over TLS) because they did =
not configure the TLS correctly.<br>
<br></div><div>A flag that would tell the server how the client has verifie=
d the connection would enable the server to block the user from using the s=
ervice UNTIL his client is configured securely.<br></div><div><br></div>
<div>Tata. Better security.<br></div><div><br></div>regards,<br><br></div>r=
alf<br><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">Ralf Skyper Kaiser wrote:<=
br>
&gt;<br>
&gt; (An example are jabber servers using TLS. Most clients allow the user =
to<br>
&gt; accept any server certificate without verification. The jabber server =
has<br>
&gt; no way to detect which client performed proper certificate verificatio=
n and<br>
&gt; CN&lt;&gt;URI match).<br>
<br>
</div>Huh?<br>
<br>
What policy the client applies when checking the server&#39;s certificate<b=
r>
chain is none of the server&#39;s business. =A0This is entirely at the<br>
discretion of the client.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span></blockquote></div><br></div>

--20cf303ea4b876145904ea6470e3--

From jeff@jarmoc.com  Mon Nov  4 18:45:39 2013
Return-Path: <jeff@jarmoc.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 1116811E825A for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 18:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2688khISGanm for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 18:45:38 -0800 (PST)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF121E80F1 for <tls@ietf.org>; Mon,  4 Nov 2013 18:45:34 -0800 (PST)
Received: by mail-yh0-f47.google.com with SMTP id t59so1391712yho.20 for <tls@ietf.org>; Mon, 04 Nov 2013 18:45:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jarmoc.com; s=jarmoc; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=agvKYQTFYU7ZuuEuBUo1K8QGtP20fsP/v2qdhkxxuic=; b=TnS3yZ/1KpkIAFXpcvIL/9NW9eRFHgqPeYAUnkhd24H2hEfj5XFN0PS+TWnkhVyrrG VkyuWZjrRXB8m5FVz2Jzh2DBikqloyJclqIZk3IL7/I+M+Wp9SCkbMVsfU8/O2eoiqyf mBeWDjk5E84Rmad0M9nfkxq7xJoHt77J8ZhWo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:in-reply-to:to; bh=agvKYQTFYU7ZuuEuBUo1K8QGtP20fsP/v2qdhkxxuic=; b=mD89c20j+GI9ZXbL2pYTkwJ+5u8JHjUjMpnxD/2/rYOaQzwHzXHTtDL+WUZ/F5Fh1u aVg8hM2h5evmX/4ztOlJ6p5XcXi6i0Tavb0mP2DcqO8q190sS4M7p3vIFr4UeJ6JgnQp HAR4BNBmvxy1d8hLJPG+F38EiUx1RAmkpR3C7aS2Ncus/MhaTPlAlkvrMpNYl/PyupNM 9ybrOGr64HagY4cL82/y8fRpptiid97mn2P47CyjLxwC3R81RGKHjXMoVlu1D2iDjm+g 1thUGk75WS9dAeDBpX+ZZEkYbj+FW0QW/YRaZtHF4QG4kpRav7tiL8WkdjQWAAUY2F6F PQKQ==
X-Gm-Message-State: ALoCoQm1NvGVX2AN4lvCBT3KQxqo1d5m+eLBBxzkSx+TEGhLF3IIQeaS7mlpa5jkEFtWLrAxH/d1
X-Received: by 10.236.20.138 with SMTP id p10mr51446yhp.111.1383619533898; Mon, 04 Nov 2013 18:45:33 -0800 (PST)
Received: from ?IPv6:2601:d:8c00:20b:594c:3a8d:f8b6:a5e0? ([2601:d:8c00:20b:594c:3a8d:f8b6:a5e0]) by mx.google.com with ESMTPSA id o27sm31844137yhb.19.2013.11.04.18.45.32 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 18:45:32 -0800 (PST)
From: Jeff Jarmoc <jeff@jarmoc.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-9CD492D1-02D4-4A85-A7EB-983B12062E06
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Message-Id: <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
Date: Mon, 4 Nov 2013 20:45:32 -0600
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
In-Reply-To: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
X-Mailer: iPhone Mail (11B511)
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 02:45:39 -0000

--Apple-Mail-9CD492D1-02D4-4A85-A7EB-983B12062E06
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

And what prevents the client from setting the flag despite not checking?

It's the client's responsibility to validate the server's identity (or not) t=
o the extent it chooses to do so.  It's the server's responsibility to valid=
ate the client's identity (or not) to the extent it chooses to do so. =20

Neither end can take on that responsibility for the other.

> On Nov 4, 2013, at 8:03 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>=20
> Hi Martin,
>=20
> exactly, and that's the problem: "What policy the client applies when chec=
king the server's certificate chain is at the discretion of the client."
>=20
> There is no easy way to solve this. The client (and user) can always cheat=
 if he wants to. But we are not discussing dishonest users. Let's assume a h=
onest user who wants to connect to a TLS service securely.
>=20
> The user uses a TLS client (say pidgin for jabber). This client has severa=
l options to configure the TLS connection. These options include if the chai=
n should be checked at all, if the user is allowed to accept self-signed cer=
tificates and against which CA-bundle to verify the server's certificate.
>=20
> A securely configured TLS client would verify the certificate chain.
>=20
> The server has no way to check if the TLS client is configured securely. T=
he server blindly trusts the client that it is configured securely. That doe=
s not scale. Users make mistakes. Users will connect to a service not knowin=
g that the connection is not secure (even over TLS) because they did not con=
figure the TLS correctly.
>=20
> A flag that would tell the server how the client has verified the connecti=
on would enable the server to block the user from using the service UNTIL hi=
s client is configured securely.
>=20
> Tata. Better security.
>=20
> regards,
>=20
> ralf
>=20
>=20
>=20
>> On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <mrex@sap.com> wrote:
>> Ralf Skyper Kaiser wrote:
>> >
>> > (An example are jabber servers using TLS. Most clients allow the user t=
o
>> > accept any server certificate without verification. The jabber server h=
as
>> > no way to detect which client performed proper certificate verification=
 and
>> > CN<>URI match).
>>=20
>> Huh?
>>=20
>> What policy the client applies when checking the server's certificate
>> chain is none of the server's business.  This is entirely at the
>> discretion of the client.
>>=20
>> -Martin
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--Apple-Mail-9CD492D1-02D4-4A85-A7EB-983B12062E06
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><div><span style=3D"-webkit-text-size-=
adjust: auto; background-color: rgba(255, 255, 255, 0);">And what prevents t=
he client from setting the flag despite not checking?</span></div><div><span=
 style=3D"-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 2=
55, 0);"><br></span></div><div><span style=3D"-webkit-text-size-adjust: auto=
; background-color: rgba(255, 255, 255, 0);">It's the client's responsibilit=
y to validate the server's identity (or not) to the extent it chooses to do s=
o. &nbsp;It's the server's responsibility to validate the client's identity (=
or not) to the extent it chooses to do so. &nbsp;</span></div><div><span sty=
le=3D"-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0=
);"><br></span></div><div><span style=3D"-webkit-text-size-adjust: auto; bac=
kground-color: rgba(255, 255, 255, 0);">Neither end can take on that respons=
ibility for the other.</span></div></div><div style=3D"-webkit-text-size-adj=
ust: auto;"><br>On Nov 4, 2013, at 8:03 PM, Ralf Skyper Kaiser &lt;<a href=3D=
"mailto:skyper@thc.org">skyper@thc.org</a>&gt; wrote:<br><br></div><blockquo=
te type=3D"cite" style=3D"-webkit-text-size-adjust: auto;"><div><div dir=3D"=
ltr"><div><div><div>Hi Martin,<br><br></div>exactly, and that's the problem:=
 "What policy the client applies when checking the server's certificate chai=
n is at the discretion of the client."<br>
<br>There is no easy way to solve this. The client (and user) can always che=
at if he wants to. But we are not discussing dishonest users. Let's assume a=
 honest user who wants to connect to a TLS service securely.<br><br>
The user uses a TLS client (say pidgin for jabber). This client has several o=
ptions to configure the TLS connection. These options include if the chain s=
hould be checked at all, if the user is allowed to accept self-signed certif=
icates and against which CA-bundle to verify the server's certificate.<br>
<br>A securely configured TLS client would verify the certificate chain.<br>=
<br>The server has no way to check if the TLS client is configured securely.=
 The server blindly trusts the client that it is configured securely. That d=
oes not scale. Users make mistakes. Users will connect to a service not know=
ing that the connection is not secure (even over TLS) because they did not c=
onfigure the TLS correctly.<br>
<br></div><div>A flag that would tell the server how the client has verified=
 the connection would enable the server to block the user from using the ser=
vice UNTIL his client is configured securely.<br></div><div><br></div>
<div>Tata. Better security.<br></div><div><br></div>regards,<br><br></div>ra=
lf<br><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>&gt;</span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div class=3D"im">Ralf Skyper Kaiser wrote:<br=
>
&gt;<br>
&gt; (An example are jabber servers using TLS. Most clients allow the user t=
o<br>
&gt; accept any server certificate without verification. The jabber server h=
as<br>
&gt; no way to detect which client performed proper certificate verification=
 and<br>
&gt; CN&lt;&gt;URI match).<br>
<br>
</div>Huh?<br>
<br>
What policy the client applies when checking the server's certificate<br>
chain is none of the server's business. &nbsp;This is entirely at the<br>
discretion of the client.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span></blockquote></div><br></div>
</div></blockquote><blockquote type=3D"cite" style=3D"-webkit-text-size-adju=
st: auto;"><div><span>_______________________________________________</span>=
<br><span>TLS mailing list</span><br><span><a href=3D"mailto:TLS@ietf.org">T=
LS@ietf.org</a></span><br><span><a href=3D"https://www.ietf.org/mailman/list=
info/tls">https://www.ietf.org/mailman/listinfo/tls</a></span><br></div></bl=
ockquote></body></html>=

--Apple-Mail-9CD492D1-02D4-4A85-A7EB-983B12062E06--

From nico@cryptonector.com  Mon Nov  4 19:19:17 2013
Return-Path: <nico@cryptonector.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 EFB9E11E8232 for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 19:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level: 
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 7CmL+kKS4rDo for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 19:19:12 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E7B9911E8105 for <tls@ietf.org>; Mon,  4 Nov 2013 19:19:11 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 80EDE9405C for <tls@ietf.org>; Mon,  4 Nov 2013 19:19:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SHD1FkOLnUqCXZ3LBkVR aNA/Gvw=; b=Q0AKR/p34NnsV2PUgwVMlSLYW84vwBnwpG2CdLEvrSHhg2u/FBdh mLQ/Gm18aFvXzf8flr18xNm9BOQ8eDMAQOsHi/ZlXDtFj36nLQ4HDIn6TD8eOh4c U3+pBV8zOvxGFMf5i5cC3fji6D3fO1p5E1lk9WIEto7wMZecnRXOjYM=
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 360C794059 for <tls@ietf.org>; Mon,  4 Nov 2013 19:19:11 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id x55so2852730wes.8 for <tls@ietf.org>; Mon, 04 Nov 2013 19:19:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hsqpZ8wfuNWXYYYyk+iH/KUSC/0FdV/b7OrjM7mPGBQ=; b=Cv7ma0FM1JseBgfWlDqGegokrTkAH9HUrljTzzxaNebSH0BoJYJ2TJ4DVuipGuaieC lppB1gxF6c7idny86oloUlpEM2doMe+tFTnHRiPcu5vICHRBp+2SqeYWw8+CcFKLe9eQ n+K98IxtPK8nJ8Cp/LmYHSovBMgzf+lXOuWl6ejRr2ykFPdd6sfPIVTA4C/dHEc4VtWo V2pofjUReaQNY69ZmLLx+9WUibhHU8QMTZNeHsaX8M73DMk6QxFDJUdYN90cAJ54eRmm 5xgU/2wQH1CscKSoK2k9Q/bOVHdJHG/NAbhhEOq6azDQ43I5LynUzqmT8s5XhsDFLPZp rNkA==
MIME-Version: 1.0
X-Received: by 10.180.99.3 with SMTP id em3mr15168006wib.4.1383621549543; Mon, 04 Nov 2013 19:19:09 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Mon, 4 Nov 2013 19:19:09 -0800 (PST)
In-Reply-To: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
Date: Mon, 4 Nov 2013 21:19:09 -0600
Message-ID: <CAK3OfOh+mc-UzS62fx_oN1QUasjAu3NU72=9tkyQfk8yJw9T=A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 03:19:17 -0000

On Mon, Nov 4, 2013 at 8:03 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> Hi Martin,
>
> exactly, and that's the problem: "What policy the client applies when
> checking the server's certificate chain is at the discretion of the client."
>
> There is no easy way to solve this. The client (and user) can always cheat
> if he wants to. But we are not discussing dishonest users. Let's assume a
> honest user who wants to connect to a TLS service securely.

What are you talking about?  Of course the client and server (and CAs,
and...) can all cheat on *themselves*.  But the whole point of
verifying some other party's certificate is to protect yourself.  The
client (unless it's a dumb, dumb client) is going to do check the
server's cert.

> The user uses a TLS client (say pidgin for jabber). This client has several
> options to configure the TLS connection. These options include if the chain
> should be checked at all, if the user is allowed to accept self-signed
> certificates and against which CA-bundle to verify the server's certificate.

Yes, it'd be nice if XMPP clients had a
leap-of-faith/trust-on-first-use option.  That has nothing to do with
this thread unless you're proposing a different method of
authenticating servers.

> A securely configured TLS client would verify the certificate chain.

I know right?  So that's a bug in the client.  Nothing wrong with TLS
itself.  (Well, the PKIX bits are not trivial, and that has to do with
why some clients get things wrong, but surely you're not proposing
replacing the PKIX bits.)

> The server has no way to check if the TLS client is configured securely. The

And vice-versa.  Of course.

> server blindly trusts the client that it is configured securely. That does
> not scale. Users make mistakes. Users will connect to a service not knowing
> that the connection is not secure (even over TLS) because they did not
> configure the TLS correctly.
>
> A flag that would tell the server how the client has verified the connection
> would enable the server to block the user from using the service UNTIL his
> client is configured securely.
>
> Tata. Better security.

Ah!  You want a secure bit.  Like RFC3514 (note the publication date).
 It doesn't work.

Nico
--

From ynir@checkpoint.com  Mon Nov  4 21:53:10 2013
Return-Path: <ynir@checkpoint.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 C0DA021E80F3 for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 21:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.517
X-Spam-Level: 
X-Spam-Status: No, score=-10.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 lKCrhPjJ3zTI for <tls@ietfa.amsl.com>; Mon,  4 Nov 2013 21:53:04 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3B621E8063 for <tls@ietf.org>; Mon,  4 Nov 2013 21:53:03 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA55r12j012413; Tue, 5 Nov 2013 07:53:02 +0200
X-CheckPoint: {52788660-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 07:53:01 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Jeff Jarmoc <jeff@jarmoc.com>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngUoMjfWHp8eUeJG+rmdHIlV5oPTiyAgAFPL4CAAwGAAIACEOsAgAAYNoCAAAu9AIAANGKA
Date: Tue, 5 Nov 2013 05:53:01 +0000
Message-ID: <DAC7B33B-D76F-4111-AF6F-B2218C7294BA@checkpoint.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com> <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
In-Reply-To: <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.53]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_DAC7B33BD76F4111AF6FB2218C7294BAcheckpointcom_"
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 05:53:10 -0000

--_000_DAC7B33BD76F4111AF6FB2218C7294BAcheckpointcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


On Nov 4, 2013, at 6:45 PM, Jeff Jarmoc <jeff@jarmoc.com<mailto:jeff@jarmoc=
.com>> wrote:

And what prevents the client from setting the flag despite not checking?

It's the client's responsibility to validate the server's identity (or not)=
 to the extent it chooses to do so.  It's the server's responsibility to va=
lidate the client's identity (or not) to the extent it chooses to do so.

Neither end can take on that responsibility for the other.

Right. This is what the NEA people call "the lying endpoint" problem, and i=
t can't be solved without some pretty rubegoldbergian stuff like trusted co=
mputing.

I don't want a client on my machine acting as an agent of the server, infor=
ming it that my machine is not configured correctly. Sometimes this informa=
tion leaks (like when my ClientHello has only SSLv3 and TLS_RSA_EXPORT_WITH=
_RC4_40_MD5. But beyond that, this is none of the server's business.

Yoav



--_000_DAC7B33BD76F4111AF6FB2218C7294BAcheckpointcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <162BB7B95054E5489D46EF85898498D1@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
<br>
<div>
<div>On Nov 4, 2013, at 6:45 PM, Jeff Jarmoc &lt;<a href=3D"mailto:jeff@jar=
moc.com">jeff@jarmoc.com</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div dir=3D"auto">
<div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">And what prevents the client from setting the flag desp=
ite not checking?</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);"><br>
</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">It's the client's responsibility to validate the server=
's identity (or not) to the extent it chooses to do so. &nbsp;It's the serv=
er's responsibility to validate the client's
 identity (or not) to the extent it chooses to do so. &nbsp;</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);"><br>
</span></div>
<div><span style=3D"-webkit-text-size-adjust: auto; background-color: rgba(=
255, 255, 255, 0);">Neither end can take on that responsibility for the oth=
er.</span></div>
</div>
</div>
</blockquote>
<br>
</div>
<div>Right. This is what the NEA people call &quot;the lying endpoint&quot;=
 problem, and it can't be solved without some pretty rubegoldbergian stuff =
like trusted computing.</div>
<div><br>
</div>
<div>I don't want a client on my machine acting as an agent of the server, =
informing it that my machine is not configured correctly. Sometimes this in=
formation leaks (like when my ClientHello has only SSLv3 and&nbsp;<span sty=
le=3D"font-family: sans-serif; font-size: 13px; ">TLS_RSA_EXPORT_WITH_RC4_4=
0_MD5.
 But beyond that, this is none of the server's business.</span></div>
<div><span style=3D"font-family: sans-serif; font-size: 13px; "><br>
</span></div>
<div><span style=3D"font-family: sans-serif; font-size: 13px; ">Yoav</span>=
</div>
<div><span style=3D"font-family: sans-serif; font-size: 13px; "><br>
</span></div>
<br>
</body>
</html>

--_000_DAC7B33BD76F4111AF6FB2218C7294BAcheckpointcom_--

From Johannes.Merkle@secunet.com  Tue Nov  5 05:19:04 2013
Return-Path: <Johannes.Merkle@secunet.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 18C6211E81F3 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 05:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Level: 
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 p+rQZZ6iNfdn for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 05:18:52 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29311E8167 for <tls@ietf.org>; Tue,  5 Nov 2013 05:18:50 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CAE9A1A0075; Tue,  5 Nov 2013 14:18:47 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ofSroQi8qqy; Tue,  5 Nov 2013 14:18:46 +0100 (CET)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id B2A271A0071; Tue,  5 Nov 2013 14:18:44 +0100 (CET)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Nov 2013 14:18:44 +0100
Message-ID: <5278F039.2060404@secunet.com>
Date: Tue, 05 Nov 2013 14:18:49 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ralf Skyper Kaiser <skyper@thc.org>, mrex@sap.com
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com>	<20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
In-Reply-To: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Nov 2013 13:18:44.0917 (UTC) FILETIME=[8DE0FE50:01CEDA29]
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 13:19:04 -0000

Ralf Skyper Kaiser schrieb am 05.11.2013 03:03:
> A securely configured TLS client would verify the certificate chain.
> 
> The server has no way to check if the TLS client is configured securely.
> The server blindly trusts the client that it is configured securely. That
> does not scale. Users make mistakes. Users will connect to a service not
> knowing that the connection is not secure (even over TLS) because they did
> not configure the TLS correctly.

I don't see the point. You are referring to a verification of the server's certificate by the client.
When a client identifies a server, what is the benefit for the server to ensure that the client performs the
identification in a proper way?

If the verification is not done properly by the client, the client may be susceptible to impersonation attacks on the
server side, i.e. may trust a malicious server pretending to be the honest server. If such a case occurs, i.e, if the
client has connected to a malicious server, what were the point in the honest server's checking the client's policy? In
such a case, the honest server is not even participating in the communication, and the malicious server, who is
participating in the communication, will certainly not insist on a strict client policy (not if he is a clever attacker,
at least).

So, what threat scenario is your requirement (of the server being able to verify the client's policy) addressing?

-- 
Johannes

From dharkins@lounge.org  Tue Nov  5 09:53:19 2013
Return-Path: <dharkins@lounge.org>
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 4753321F9E91 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 09:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.005
X-Spam-Level: 
X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 pHorJQGVuF8U for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 09:53:07 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1F121F9D98 for <tls@ietf.org>; Tue,  5 Nov 2013 09:51:29 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9400A10224008; Tue,  5 Nov 2013 09:51:15 -0800 (PST)
Received: from 31.133.166.166 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 5 Nov 2013 09:51:16 -0800 (PST)
Message-ID: <866d3caa053aacb9be8a3ed19a61311e.squirrel@www.trepanning.net>
In-Reply-To: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
Date: Tue, 5 Nov 2013 09:51:16 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Ralf Skyper Kaiser" <skyper@thc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 17:53:19 -0000

  Hello,

On Mon, November 4, 2013 6:03 pm, Ralf Skyper Kaiser wrote:
> Hi Martin,
>
> exactly, and that's the problem: "What policy the client applies when
> checking the server's certificate chain is at the discretion of the
> client."
>
> There is no easy way to solve this. The client (and user) can always cheat
> if he wants to. But we are not discussing dishonest users. Let's assume a
> honest user who wants to connect to a TLS service securely.
>
> The user uses a TLS client (say pidgin for jabber). This client has
> several
> options to configure the TLS connection. These options include if the
> chain
> should be checked at all, if the user is allowed to accept self-signed
> certificates and against which CA-bundle to verify the server's
> certificate.
>
> A securely configured TLS client would verify the certificate chain.
>
> The server has no way to check if the TLS client is configured securely.
> The server blindly trusts the client that it is configured securely. That
> does not scale. Users make mistakes. Users will connect to a service not
> knowing that the connection is not secure (even over TLS) because they did
> not configure the TLS correctly.
>
> A flag that would tell the server how the client has verified the
> connection would enable the server to block the user from using the
> service
> UNTIL his client is configured securely.

  Doesn't RFC 3514 solve this problem for you? If not, then maybe it's
time for a 3514-bis.

  regards,

  Dan.



From ynir@checkpoint.com  Tue Nov  5 09:56:04 2013
Return-Path: <ynir@checkpoint.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 1D45921E8175 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 09:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.513
X-Spam-Level: 
X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 KLth68a2mzvf for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 09:55:50 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D71B021F9D34 for <tls@ietf.org>; Tue,  5 Nov 2013 09:55:25 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA5HtNUK017719; Tue, 5 Nov 2013 19:55:23 +0200
X-CheckPoint: {52792FA6-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 19:55:23 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngUoMjfWHp8eUeJG+rmdHIlV5oPTiyAgAFPL4CAAwGAAIACEOsAgAAYNoCAALytgIAATUQA
Date: Tue, 5 Nov 2013 17:55:23 +0000
Message-ID: <4C24FFCF-6BC0-47D6-B9F3-41E9614539A7@checkpoint.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com> <5278F039.2060404@secunet.com>
In-Reply-To: <5278F039.2060404@secunet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.188]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2202A8F63C36FF4793C63E5E2F37A239@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 17:56:04 -0000

On Nov 5, 2013, at 5:18 AM, Johannes Merkle <johannes.merkle@secunet.com> w=
rote:

> Ralf Skyper Kaiser schrieb am 05.11.2013 03:03:
>> A securely configured TLS client would verify the certificate chain.
>>=20
>> The server has no way to check if the TLS client is configured securely.
>> The server blindly trusts the client that it is configured securely. Tha=
t
>> does not scale. Users make mistakes. Users will connect to a service not
>> knowing that the connection is not secure (even over TLS) because they d=
id
>> not configure the TLS correctly.
>=20
> I don't see the point. You are referring to a verification of the server'=
s certificate by the client.
> When a client identifies a server, what is the benefit for the server to =
ensure that the client performs the
> identification in a proper way?

There is a benefit in making the whole ecosystem more secure, and rejecting=
 components that are insecurely configured, because they can compromise the=
 whole system.

I don't think that's enough to justify this kind of thing.

Yoav=

From SChokhani@cygnacom.com  Tue Nov  5 10:00:54 2013
Return-Path: <SChokhani@cygnacom.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 BEE1C11E81F8 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 10:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Jczxbf4EHLnf for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 10:00:49 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8152E11E816F for <tls@ietf.org>; Tue,  5 Nov 2013 09:59:38 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,640,1378872000";  d="scan'208";a="1031648"
Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 05 Nov 2013 12:59:19 -0500
Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Tue, 5 Nov 2013 12:59:19 -0500
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: Dan Harkins <dharkins@lounge.org>, Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngQ/AIKIwgsCkqtqecwwW27CJoPssKAgAFPLoCAAxJEAIACEOsAgAAYNYCAAQjNAP//rdeA
Date: Tue, 5 Nov 2013 17:59:18 +0000
Message-ID: <4262AC0DB9856847A2D00EF817E811390B1D07@scygexch10.cygnacom.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com> <866d3caa053aacb9be8a3ed19a61311e.squirrel@www.trepanning.net>
In-Reply-To: <866d3caa053aacb9be8a3ed19a61311e.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.24.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 18:00:54 -0000

I am failing to see the security benefit or threat the server verification =
of client's hygiene on certification path validation provides.

If the client ends up trusting the wrong key, it will go to a bad server.

If the client is connected to the good server, certification path validatio=
n does not matter since it is already at the right place no matter how it g=
ot there.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Dan H=
arkins
Sent: Tuesday, November 05, 2013 12:51 PM
To: Ralf Skyper Kaiser
Cc: tls@ietf.org
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3


  Hello,

On Mon, November 4, 2013 6:03 pm, Ralf Skyper Kaiser wrote:
> Hi Martin,
>
> exactly, and that's the problem: "What policy the client applies when=20
> checking the server's certificate chain is at the discretion of the=20
> client."
>
> There is no easy way to solve this. The client (and user) can always=20
> cheat if he wants to. But we are not discussing dishonest users. Let's=20
> assume a honest user who wants to connect to a TLS service securely.
>
> The user uses a TLS client (say pidgin for jabber). This client has=20
> several options to configure the TLS connection. These options include=20
> if the chain should be checked at all, if the user is allowed to=20
> accept self-signed certificates and against which CA-bundle to verify=20
> the server's certificate.
>
> A securely configured TLS client would verify the certificate chain.
>
> The server has no way to check if the TLS client is configured securely.
> The server blindly trusts the client that it is configured securely.=20
> That does not scale. Users make mistakes. Users will connect to a=20
> service not knowing that the connection is not secure (even over TLS)=20
> because they did not configure the TLS correctly.
>
> A flag that would tell the server how the client has verified the=20
> connection would enable the server to block the user from using the=20
> service UNTIL his client is configured securely.

  Doesn't RFC 3514 solve this problem for you? If not, then maybe it's time=
 for a 3514-bis.

  regards,

  Dan.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From skyper@thc.org  Tue Nov  5 11:51:09 2013
Return-Path: <skyper@thc.org>
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 45A7D21E80B0 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 11:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 p4lWDtPv15JR for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 11:50:27 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7798011E812B for <tls@ietf.org>; Tue,  5 Nov 2013 11:49:36 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id tp5so16238783ieb.30 for <tls@ietf.org>; Tue, 05 Nov 2013 11:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x4wfIvaHj/wLW7B72Y9i/+9yk46jiZMJXzL1BhwR0y8=; b=WT0a/Cp6fQB5ZDekfWX8OPQK+nbfzbWCe1LmEqgudEw0fYHbZypLWItvQoRsCpihtC cFDe2PXDh2NaqbaEtxpGFPgX1MfVsETh2AwPxDrELXof+RSFtQQVVHrVwlRIRFv1vCKo 9QJ2fgWtFU0KXQ7hdr3EyZUS8MkEuSgdwA62g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x4wfIvaHj/wLW7B72Y9i/+9yk46jiZMJXzL1BhwR0y8=; b=k9ycPfRRm4qI7j9VYyi2tPaI8/h6ZR4wFbiKf+J9j7UQ+xgk0koo638PZ/2weQnvlE ytJcNNr3nt7iaG7vtrhdck1SwVj8HSwNj764RRoveo5yF+2TzbWHKKj4zy99l0AYdCsB Sq1wsXag+ep4HS8aTTHhJldcwX3QYXWGrPhKKzweUraupPF8wjqOeHlXXOgT8UOkm0V5 bEg1eWxHdiQRyo/Tcu23nMREX4kQJPLkB06rKciVyzo8vLO/kdJXvUaMTykVHiwHtJKl H46kmldVsTMWzPBZtKOy8BHwGTKlIHQ5DTtp99pDQlF2WYSko4Siuo6tB2jK+UEvfM5p Jarw==
X-Gm-Message-State: ALoCoQm3kBX/7mlHbBH8GjgdLPllqNw+2AEWce5YkLf/Cdg02KyZ6/QyHVP/l+/Nha+62uDwPHTj
MIME-Version: 1.0
X-Received: by 10.42.250.148 with SMTP id mo20mr7869198icb.34.1383680970956; Tue, 05 Nov 2013 11:49:30 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Tue, 5 Nov 2013 11:49:30 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com> <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
Date: Tue, 5 Nov 2013 19:49:30 +0000
Message-ID: <CA+BZK2qgqAA7=7_aTw6A=ounnkK9pvRyNA0FoJmd51U+qTrLKQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Jeff Jarmoc <jeff@jarmoc.com>
Content-Type: multipart/alternative; boundary=20cf300e4e51c2574404ea7354e5
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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: Tue, 05 Nov 2013 19:51:09 -0000

--20cf300e4e51c2574404ea7354e5
Content-Type: text/plain; charset=ISO-8859-1

Hi,

i mentioned earlier that this would not prevent dishonest clients (I am not
trying to achieve this). The goal is not to solve "the lying endpoint"
problem or re-invent trusted computing.

There are some applications which implement such a notification in the
application layer already. For example a web server can query a web-browser
if the browser is using 'Private Browsing' and if prevent the client from
using the web-site.

The user/browser can lie (but it would be to the disadvantage of the user).

As somebody else mentioned it's a flag that enables the server to prevent
accidental misconfiguration of a client - unless the user is dishonest - in
which case it is to the disadvantage of the user.

Maybe we need a real-life scenario:

You are better off wearing a seat-belt in a car. You might one day forget
to put on the seat belt (honest mistake!). So a mechanism that the car
warns you about it. Yes, you can cheat the car and pretend you put the
seat-belt on when you did not - but that's to your disadvantage.

Equally does it not mean that every time you do not wear a seat-belt  that
you will have an accident ('are attacked'...) (some people suggest this).

regards,

ralf





regards,

ralf


On Tue, Nov 5, 2013 at 2:45 AM, Jeff Jarmoc <jeff@jarmoc.com> wrote:

> And what prevents the client from setting the flag despite not checking?
>
> It's the client's responsibility to validate the server's identity (or
> not) to the extent it chooses to do so.  It's the server's responsibility
> to validate the client's identity (or not) to the extent it chooses to do
> so.
>
> Neither end can take on that responsibility for the other.
>
> On Nov 4, 2013, at 8:03 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>
> Hi Martin,
>
> exactly, and that's the problem: "What policy the client applies when
> checking the server's certificate chain is at the discretion of the client."
>
> There is no easy way to solve this. The client (and user) can always cheat
> if he wants to. But we are not discussing dishonest users. Let's assume a
> honest user who wants to connect to a TLS service securely.
>
> The user uses a TLS client (say pidgin for jabber). This client has
> several options to configure the TLS connection. These options include if
> the chain should be checked at all, if the user is allowed to accept
> self-signed certificates and against which CA-bundle to verify the server's
> certificate.
>
> A securely configured TLS client would verify the certificate chain.
>
> The server has no way to check if the TLS client is configured securely.
> The server blindly trusts the client that it is configured securely. That
> does not scale. Users make mistakes. Users will connect to a service not
> knowing that the connection is not secure (even over TLS) because they did
> not configure the TLS correctly.
>
> A flag that would tell the server how the client has verified the
> connection would enable the server to block the user from using the service
> UNTIL his client is configured securely.
>
> Tata. Better security.
>
> regards,
>
> ralf
>
>
>
> On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <mrex@sap.com> wrote:
>
>> Ralf Skyper Kaiser wrote:
>> >
>> > (An example are jabber servers using TLS. Most clients allow the user to
>> > accept any server certificate without verification. The jabber server
>> has
>> > no way to detect which client performed proper certificate verification
>> and
>> > CN<>URI match).
>>
>> Huh?
>>
>> What policy the client applies when checking the server's certificate
>> chain is none of the server's business.  This is entirely at the
>> discretion of the client.
>>
>> -Martin
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--20cf300e4e51c2574404ea7354e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br>i mentioned earlier that this would not pr=
event dishonest clients (I am not trying to achieve this). The goal is not =
to solve &quot;the lying endpoint&quot; problem or re-invent trusted comput=
ing.<br>
<br></div><div>There are some applications which implement such a notificat=
ion in the application layer already. For example a web server can query a =
web-browser if the browser is using &#39;Private Browsing&#39; and if preve=
nt the client from using the web-site.<br>
<br>The user/browser can lie (but it would be to the disadvantage of the us=
er).<br><br></div><div>As somebody else mentioned it&#39;s a flag that enab=
les the server to prevent accidental misconfiguration of a client - unless =
the user is dishonest - in which case it is to the disadvantage of the user=
.<br>
<br></div><div>Maybe we need a real-life scenario:<br><br></div><div>You ar=
e better off wearing a seat-belt in a car. You might one day forget to put =
on the seat belt (honest mistake!). So a mechanism that the car warns you a=
bout it. Yes, you can cheat the car and pretend you put the seat-belt on wh=
en you did not - but that&#39;s to your disadvantage.<br>
<br>Equally does it not mean that every time you do not wear a seat-belt=A0=
 that you will have an accident (&#39;are attacked&#39;...) (some people su=
ggest this).<br><br>regards,<br><br>ralf<br><br></div><div><br></div><div>
<br></div><div><br><br></div>regards,<br><br>ralf<br></div><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Tue, Nov 5, 2013 at 2:45 A=
M, Jeff Jarmoc <span dir=3D"ltr">&lt;<a href=3D"mailto:jeff@jarmoc.com" tar=
get=3D"_blank">jeff@jarmoc.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div class=3D"im"><div><di=
v><span style=3D"background-color:rgba(255,255,255,0)">And what prevents th=
e client from setting the flag despite not checking?</span></div>
<div><span style=3D"background-color:rgba(255,255,255,0)"><br></span></div>=
<div><span style=3D"background-color:rgba(255,255,255,0)">It&#39;s the clie=
nt&#39;s responsibility to validate the server&#39;s identity (or not) to t=
he extent it chooses to do so. =A0It&#39;s the server&#39;s responsibility =
to validate the client&#39;s identity (or not) to the extent it chooses to =
do so. =A0</span></div>
<div><span style=3D"background-color:rgba(255,255,255,0)"><br></span></div>=
<div><span style=3D"background-color:rgba(255,255,255,0)">Neither end can t=
ake on that responsibility for the other.</span></div></div><div><br>On Nov=
 4, 2013, at 8:03 PM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyper@thc.o=
rg" target=3D"_blank">skyper@thc.org</a>&gt; wrote:<br>
<br></div></div><div><div class=3D"h5"><blockquote type=3D"cite"><div><div =
dir=3D"ltr"><div><div><div>Hi Martin,<br><br></div>exactly, and that&#39;s =
the problem: &quot;What policy the client applies when checking the server&=
#39;s certificate chain is at the discretion of the client.&quot;<br>

<br>There is no easy way to solve this. The client (and user) can always ch=
eat if he wants to. But we are not discussing dishonest users. Let&#39;s as=
sume a honest user who wants to connect to a TLS service securely.<br>
<br>
The user uses a TLS client (say pidgin for jabber). This client has several=
 options to configure the TLS connection. These options include if the chai=
n should be checked at all, if the user is allowed to accept self-signed ce=
rtificates and against which CA-bundle to verify the server&#39;s certifica=
te.<br>

<br>A securely configured TLS client would verify the certificate chain.<br=
><br>The server has no way to check if the TLS client is configured securel=
y. The server blindly trusts the client that it is configured securely. Tha=
t does not scale. Users make mistakes. Users will connect to a service not =
knowing that the connection is not secure (even over TLS) because they did =
not configure the TLS correctly.<br>

<br></div><div>A flag that would tell the server how the client has verifie=
d the connection would enable the server to block the user from using the s=
ervice UNTIL his client is configured securely.<br></div><div><br></div>

<div>Tata. Better security.<br></div><div><br></div>regards,<br><br></div>r=
alf<br><br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo=
te">On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>&gt;</span> wr=
ote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>Ralf Skyper Kaiser wrote:<br>
&gt;<br>
&gt; (An example are jabber servers using TLS. Most clients allow the user =
to<br>
&gt; accept any server certificate without verification. The jabber server =
has<br>
&gt; no way to detect which client performed proper certificate verificatio=
n and<br>
&gt; CN&lt;&gt;URI match).<br>
<br>
</div>Huh?<br>
<br>
What policy the client applies when checking the server&#39;s certificate<b=
r>
chain is none of the server&#39;s business. =A0This is entirely at the<br>
discretion of the client.<br>
<span><font color=3D"#888888"><br>
-Martin<br>
</font></span></blockquote></div><br></div>
</div></blockquote></div></div><div class=3D"im"><blockquote type=3D"cite">=
<div><span>_______________________________________________</span><br><span>=
TLS mailing list</span><br><span><a href=3D"mailto:TLS@ietf.org" target=3D"=
_blank">TLS@ietf.org</a></span><br>
<span><a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/tls</a></span><br></div></blockquo=
te></div></div><br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br></div>

--20cf300e4e51c2574404ea7354e5--

From ekr@rtfm.com  Tue Nov  5 13:09:47 2013
Return-Path: <ekr@rtfm.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 510AB11E8175 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 13:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 N9yAoFMfIwBK for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 13:09:43 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC6D11E81EB for <tls@ietf.org>; Tue,  5 Nov 2013 13:09:36 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id k14so4114253wgh.7 for <tls@ietf.org>; Tue, 05 Nov 2013 13:09:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=z6atyFFNJVyMD1Xcbzw5haKj1e6R5LleQ8X+XTp2HR4=; b=Nmmip0/7xnx78SSZe7GXyMLcwvDtJn2Qv/0x9Oh+s5ugX39QX7KieYezwGnaDekySc CKQzfW+9EDAXj8axCpA73DoCetwGX48o5CVmB/DuVbSLW+D0dDw0uUl8xbQWqTzy7rAC 3+7YtMKkBA7sJbm5nDuceBpasemBbt666e0vbNPmmgujp8jUuj3En5rRCfypcL8YJaVV ZfYJIWWB5IJ9EoToc43YmNs3jHnTu/uJVHQfbBflHWa98EWp8H3PYy/iGvh2FDh/hS2J H3qVTVSgePkyqtbE6ttTchoRfGcWoGqxtZEYz5jEufjL3/pYBQOoXBAaqJTQHGRdfPj6 PH0A==
X-Gm-Message-State: ALoCoQlsxlS6leZAjtmLu+niS9xWX2UwiNB+yiRNY7oNAVHZuuCzaFBHsl8EovSKojuCgRurwriO
X-Received: by 10.194.240.197 with SMTP id wc5mr19953168wjc.23.1383685776019;  Tue, 05 Nov 2013 13:09:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 5 Nov 2013 13:08:55 -0800 (PST)
X-Originating-IP: [2001:67c:370:176:6970:964c:adc8:66fa]
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 5 Nov 2013 13:08:55 -0800
Message-ID: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e013d19cc292abb04ea747396
Subject: [TLS] Potential New Handshake Flows for TLS 1.3
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: Tue, 05 Nov 2013 21:09:47 -0000

--089e013d19cc292abb04ea747396
Content-Type: text/plain; charset=ISO-8859-1

I've just submitted a document on potentially new reduced RT/more
private protocol flows for TLS 1.3. It's fairly handwavy ATM but I wanted
to err on the side of getting some of the ideas out for discussion
so we could figure out which avenues we want to pursue. This draft
borrows (steals) liberally from a bunch of prior work too numerous
to name here.

I'll be going over some of this material at today's meeting, but seeing
as how this just got delivered, I'll make sure you don't need to have
read the draft to follow along.

Sorry about the late delivery....

-Ekr


Filename:        draft-rescorla-tls13-new-flows
Revision:        00
Title:           New Handshake Flows for TLS 1.3
Creation date:   2013-11-05
Group:           Individual Submission
Number of pages: 21
URL:
http://www.ietf.org/internet-drafts/draft-rescorla-tls13-new-flows-00.txt
Status:
http://datatracker.ietf.org/doc/draft-rescorla-tls13-new-flows
Htmlized:
http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00


Abstract:
   This document sketches some potential new handshake flows for TLS
   1.3.

--089e013d19cc292abb04ea747396
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve just submitted a document on potentially new redu=
ced RT/more<div>private protocol flows for TLS 1.3. It&#39;s fairly handwav=
y ATM but I wanted</div><div>to err on the side of getting some of the idea=
s out for discussion</div>


<div>so we could figure out which avenues we want to pursue. This draft</di=
v><div>borrows (steals) liberally from a bunch of prior work too numerous</=
div><div>to name here.</div><div><br></div><div>I&#39;ll be going over some=
 of this material at today&#39;s meeting, but seeing</div>


<div>as how this just got delivered, I&#39;ll make sure you don&#39;t need =
to have</div><div>read the draft to follow along.</div><div><br></div><div>=
<font face=3D"arial, sans-serif">Sorry about the late delivery....</font></=
div>


<div><font face=3D"arial, sans-serif"><br></font></div><div>-Ekr<br></div><=
div><br><div><br><span style=3D"font-family:arial,sans-serif;font-size:13.3=
33333969116211px">Filename: =A0 =A0 =A0 =A0draft-rescorla-tls13-new-flows</=
span><br style=3D"font-family:arial,sans-serif;font-size:13.333333969116211=
px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>Revision: =A0 =A0 =A0 =A000</span><br style=3D"font-family:arial,sans-seri=
f;font-size:13.333333969116211px"><span style=3D"font-family:arial,sans-ser=
if;font-size:13.333333969116211px">Title: =A0 =A0 =A0 =A0 =A0 New Handshake=
 Flows for TLS 1.3</span><br style=3D"font-family:arial,sans-serif;font-siz=
e:13.333333969116211px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>Creation date: =A0=A0</span><span style=3D"font-family:arial,sans-serif;fo=
nt-size:13.333333969116211px"><span>2013-11-05</span></span><br style=3D"fo=
nt-family:arial,sans-serif;font-size:13.333333969116211px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>Group: =A0 =A0 =A0 =A0 =A0 Individual Submission</span><br style=3D"font-f=
amily:arial,sans-serif;font-size:13.333333969116211px"><span style=3D"font-=
family:arial,sans-serif;font-size:13.333333969116211px">Number of pages: 21=
</span><br style=3D"font-family:arial,sans-serif;font-size:13.3333339691162=
11px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>URL: =A0 =A0 =A0 =A0 =A0 =A0=A0</span><a href=3D"http://www.ietf.org/inter=
net-drafts/draft-rescorla-tls13-new-flows-00.txt" style=3D"font-family:aria=
l,sans-serif;font-size:13.333333969116211px" target=3D"_blank">http://www.i=
etf.org/internet-drafts/draft-rescorla-tls13-new-flows-00.txt</a><br style=
=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>Status: =A0 =A0 =A0 =A0 =A0</span><a href=3D"http://datatracker.ietf.org/d=
oc/draft-rescorla-tls13-new-flows" style=3D"font-family:arial,sans-serif;fo=
nt-size:13.333333969116211px" target=3D"_blank">http://datatracker.ietf.org=
/doc/draft-rescorla-tls13-new-flows</a><br style=3D"font-family:arial,sans-=
serif;font-size:13.333333969116211px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>Htmlized: =A0 =A0 =A0 =A0</span><a href=3D"http://tools.ietf.org/html/draf=
t-rescorla-tls13-new-flows-00" style=3D"font-family:arial,sans-serif;font-s=
ize:13.333333969116211px" target=3D"_blank">http://tools.ietf.org/html/draf=
t-rescorla-tls13-new-flows-00</a><br style=3D"font-family:arial,sans-serif;=
font-size:13.333333969116211px">


<br style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"><=
br style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"><s=
pan style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">A=
bstract:</span><br style=3D"font-family:arial,sans-serif;font-size:13.33333=
3969116211px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>=A0 =A0This document sketches some potential new handshake flows for TLS</=
span><br style=3D"font-family:arial,sans-serif;font-size:13.333333969116211=
px">


<span style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px"=
>=A0 =A01.3.</span><br style=3D"font-family:arial,sans-serif;font-size:13.3=
33333969116211px"></div></div></div>

--089e013d19cc292abb04ea747396--

From brian@briansmith.org  Tue Nov  5 14:21:37 2013
Return-Path: <brian@briansmith.org>
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 1080611E8103 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 14:21:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 gP8MD5vzCfr4 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 14:21:31 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id E150A11E81DE for <tls@ietf.org>; Tue,  5 Nov 2013 14:21:26 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id i7so5279437qcq.30 for <tls@ietf.org>; Tue, 05 Nov 2013 14:21:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SQx89Ito6gJn3WF+g2IA6+J8Au3W3+Q/kmtapLob0rI=; b=LzYW4Ix6QO4oRIWT82q8q06+syReLE682kK5sM2B6pPrH2rMhvzmj55o3PlW6zcDGw 4IBvD46/5SHPiZbjDcW6uhGJ3htEPV4HTwxsNRHjSjLbwQCGM4G5K+eYpU1VcUBPPaaV /nDns+ZiYC6eAomBlUp8jreDAVeCBmnj2qSfCKCPR8TKyLS12E3NObIJD6hbjzxWlRxK YY/UGUUizwSmbPssspRGFBdRmtTx1+6PlefyvYC0paj3Pak4LKcRXzYhW7+MNLwqTgg+ bCricunlCgQJnbbo038dvsZajNAKD2/ihGz978vj3Y1ioYmbGugz0nQutgPeuiYdjG9w 8tgw==
X-Gm-Message-State: ALoCoQkLUu7eUv/mFDMvyV7RgrVGt2PVcIFYeC+9F9jI5q6WnSpjE6c/aM1gYWFqPO3ZrYVBV6oy
MIME-Version: 1.0
X-Received: by 10.49.94.71 with SMTP id da7mr33527826qeb.22.1383690085946; Tue, 05 Nov 2013 14:21:25 -0800 (PST)
Received: by 10.224.38.5 with HTTP; Tue, 5 Nov 2013 14:21:25 -0800 (PST)
X-Originating-IP: [2001:67c:370:144:443a:a6a:235a:f1d3]
Date: Tue, 5 Nov 2013 14:21:25 -0800
Message-ID: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] ALPN concerns
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: Tue, 05 Nov 2013 22:21:37 -0000

Hi all,

First, I apologize for sending this message at the last minute. I know
that the delay has caused some people come inconvenience and/or
consternation. I actually feel like I still don't have enough
information to make this email as helpful as it could be, but I think
waiting longer to collect more information is going to cause more harm
than good. I will follow up with more information as soon as I have
it.

I have been watching the efforts of my Google counterparts, who I work
on NSS with, regarding their deployment of ALPN and TLS 1.2.  I am
very concerned about the issues that they've run into where many web
servers are failing to handshake when the ClientHello message is
larger than 255 bytes. See [1] and [2] for some (not all) of the
information. Just yesterday, I got some numbers from Kurt Roeckx, who
relayed them from Ivan Ristic, that around 2.9% of the web servers
surveyed on the internet have this problem [3]. This is higher than
all the TLS 1.2/1.1/1.0 version intolerance measured in that survey
*combined*. That is well above the threshold where web browser makers
become very concerned.

Note that the failure mode for this is "the server does not respond."
This is the worst possible failure mode because it can only be dealt
with by implementing some kind of timeout for the handshake, that
falls back to a handshake with a smaller ClientHello. At Mozilla we
have extensive experience with this kind of timeout-based fallback
logic and we hate it due to too many false positives on poor networks.
It means that people on very poor connections lose the ability to
negotiate any TLS extensions, including in particular the SNI
extension and elliptic-curve-related extensions. In fact, we hate this
timeout-based fallback so much that we just removed it. (AFAICT, we
were the only browser to still be implementing it.) We don't want to
bring it back. Even if we were to decide to bring it back and accept
the false positives, a look at the list that Adam published ([1]
again) shows that we'd be impacting some very important sites with
horrible latency, which would almost definitely be unacceptable for
us.

We also know from prior experience that it is very difficult to get
people to deploy newer firmware and software updates to fix these
issues. Google tried a long time ago when similar issues were causing
False Start to fail, with the same failure mode. Adam Langley did
extensive lobbying to try to get these issues resolve, but they
weren't successful at convincing enough sites to do so. Consequently,
Google had to disable False Start for almost every website except
google.com, which was a major (30%, according to them) performance hit
for the affected sites. Note that Google also tried a blacklist
approach for dealing with False Start and that wasn't successful
either.

Consequently, it is very hard for me to see how I can interpret the
current information I have as anything other than "Firefox must make
sure its ClientHello stays under 256 bytes for some indefinite, but
almost certainly long, period of time." Right now, Firefox is doing
fine at staying under that limit. However, If we add support for ALPN
we're likely to go over that limit frequently. Further, even if we
could squeeze the ALPN extension in *now*, it may mean that we
effectively cannot deploy any more TLS extensions going forward, for
some indefinite period of time. That is unacceptable to me.

In particular, you may have seen the draft that EKR just posted [4].
Note how that draft adds significant amounts of information to the
ClientHello. When I talked about this with Patrick McManus and EKR, my
initial conclusion is that we can probably squeeze just enough
information into the ClientHello to stay under this artificial
256-byte limit, but only if we don't do ALPN. Or, put another way,
currently it looks like my choice is between the upcoming TLS 1.3
one-roundtrip handshake and ALPN, at least for an indefinite and
currently-unbounded period of time.

In the HTTPbis working group session earlier today, we noted that
besides certificate-related issues that are slowing HTTPS adoption,
there are significant performance concerns that also slow HTTPS
adoption. I view the TLS 1.3 one-roundtrip handshake as a way of
greatly improving the default level of TLS-induced latency, to help in
this regard. That is, I think that we can design the TLS 1.3
one-roundtrip handshake in a way that is safe and bulletproof enough
that we can have it enabled in the default configuration of all web
servers without requiring additional system administrator
configuration. In other words, we'll be able to do with a single
OpenSSL update what we haven't been able to do successfully enough
with False Start. I think that would be a huge win in the fight to
make encryption as pervasive as surveillance is.

I want to do whatever I can do to ensure we get that win, even if it
means not doing ALPN. We are very fortunate that every major browser,
and many server-side implementations, already implemented an
alternative to ALPN that avoids the compatibility risk: NPN. I don't
think NPN is perfect. But, NPN *works*, and it works *today*, and it
has been demonstrated to not cause any compatibility issues. So, from
a technical standpoint, NPN is the zero-risk, zero-effort choice and
thus greatly preferable.

Here at IETF 88 we're spending a lot of effort to figure out what to
do about the pervasive passive evesdropping problem by effectively
trying to figure out how to encrypt as much of the internet as is
feasible. I am having a hard time squaring this with the effect that
switching from NPN to ALPN would have. We're effectively asking web
browsers to *stop* encrypting information in the handshake that they
are currently encrypting. It seems backwards. I think it is well worth
considering, given what we've all read in the news between IETF 86 and
IETF 88, whether we should be extra, especially careful about leaking
anything in cleartext that we can possibly encrypt. Further, I think
we should be careful to avoid setting precedent for leaking more and
more cleartext information in protocols that are designed to be
secure. I hate slippery-slope arguments as much as anybody, but we've
actually already seen this happen in the HTTP WG, where people are now
suggesting that ALPN be used to negotiate additional information
beyond HTTP 1.x vs. HTTP 2.0. I feel like saying that it is OK to
provide a cleartext outlet for this information is likely going to be
a mistake analogous to how the TLS 1.1 spec was wrong in saying "This
leaves a small timing channel, since MAC performance depends to some
extent on the size of the data fragment, ut it is not believed to be
large enough to be exploitable" regarding the verification of MACs.
Just because we cannot find a problem now doesn't mean we won't find a
problem later. We should default to the safer choice.

Unfortunately, being at odds with the IETF TLS working group by
preferring to do NPN and not ALPN is a sucky situation to be in--for
me personally, and for my organization, and for others on this working
group. So, I would like to find some way for us to reconsider whether
NPN is really so bad that we (the TLS WG and implementers) must
immediately pay the costs of resolving the significant issues with
ALPN now, when we don't understand the full compatibility impact of
ALPN on current implementations and/or on our ability to deploy TLS
1.3 in the future.

I am very interested in what other implementers think about the issues
I brought up:

1. Is ALPN causing too many compatibility issues now?
2. Is it going to be difficult to deploy much-needed TLS 1.3
functionality later if we deploy ALPN first?
3. Is it really a good idea to have TLS encrypt less application data
instead of of more, especially considering that IETF and TLS 1.3 are
moving in the other direction overall.
4. Is it really problematic, other than the unfortunate politics, for
web browsers to carry on using NPN, either in addition to, or instead
of ALPN?

Thanks for your consideration.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

[1] https://www.imperialviolet.org/2013/10/07/f5update.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=923696
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48
[4] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00#section-5.1

From mike-list@pobox.com  Tue Nov  5 15:58:28 2013
Return-Path: <mike-list@pobox.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 25B9F11E8125 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 15:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 FHDFv67X65L6 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 15:58:23 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97511E811A for <tls@ietf.org>; Tue,  5 Nov 2013 15:58:23 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 1E0C4D7C5; Tue,  5 Nov 2013 18:58:21 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=8fD12Lrr5zPL tQJmhgicNx4bD10=; b=vqxC/e4KxFKc8uTGFprWAvVdZAR9ilmgFAT6qURJinmj xjA7OPwR9i8hRJpnxvc5mJDeiNdBdAx8dmyZuqqDCd56/uu8NBUkEWv0163ejXKk Ik6X6FGpMUU4BUL9QDvN/cDWIjI1q5hOChRcIT+w72+LhQu3oU4zY9o2AN9JdK8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=iaENhm yZ/GzFeyYmmkE1ImEz/mUfPTkkrLoXWae20DRkgR+oWjH973jM+RnhwtAtjvmHqz Zn+iqoc0PHNIJLgI8TGr1Q76gkyvwd9JfFtPIyyuUheydE7+IjVOimc6N3YiH8JT lq+0MJ3A4pHjFxwJWzlb0GUVgIRCgGJX0UGeg=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 16496D7C4; Tue,  5 Nov 2013 18:58:21 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 73FE1D7C3; Tue,  5 Nov 2013 18:58:20 -0500 (EST)
Message-ID: <52798619.8030305@pobox.com>
Date: Tue, 05 Nov 2013 15:58:17 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
In-Reply-To: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 25DAED70-4676-11E3-A5BB-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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: Tue, 05 Nov 2013 23:58:28 -0000

Eric Rescorla wrote:
> I've just submitted a document on potentially new reduced RT/more
> private protocol flows for TLS 1.3. It's fairly handwavy ATM but I wanted
> to err on the side of getting some of the ideas out for discussion
> so we could figure out which avenues we want to pursue. This draft
> borrows (steals) liberally from a bunch of prior work too numerous
> to name here.

In the handshake of Figure 7, an active attacker can obtain the 3rd
ClientHello since the ServerKeyExchange is not signed.

I would like to see some DH parameters standardized to simplify
things (no need for the client to validate) and to remove the need
to transmit them.

Since the idea of server state is being thrown around, perhaps the
server can simply send a key to the client (after Finished) to be
used to make the next handshake private.  New PreSharedKeyRequest
and response messages (not necessarily Handshake messages) could be
defined for this if necessary.

Mike


From ekr@rtfm.com  Tue Nov  5 16:45:15 2013
Return-Path: <ekr@rtfm.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 E464B11E81E9 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 16:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.698
X-Spam-Level: 
X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Ont-IufE8ibM for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 16:45:10 -0800 (PST)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AF11E818C for <tls@ietf.org>; Tue,  5 Nov 2013 16:45:10 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id c11so4171073wgh.2 for <tls@ietf.org>; Tue, 05 Nov 2013 16:45:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=A+vUV0C9E2QFyHN4fCP2ZkTMCfX5Edfvk0ofu0WvusA=; b=FVY4+VO+Tchjhw4raTh3oG/NLH8o0b93HmZxj+i8j4rjA7XpVMMAK6IjBKrAGHL9CI yFqZU1XivOutw/2ZkSucidij9U1CQhEiLrmfGiTnjWb1FZLrXQKuHhvWIzm7fWlhfOWr yD66TsF6S367WrsSWOIA/EeJPyMMc6X70DvGRzGAgGWCJ1+Qcwd5l5jAA4Zq99InOW2X 2cb0xY0r4arSwq4RXlbzZXRYznUq/5vHLuPQ4EAXn1Hohig4C43HfbpWcgry7p5deuVL XT0wfI/wSq6ZXYwW8RFo+nkjyJVMEuBZJdbiuIKhI90ZIjke1wwUBUoY5ewro4hsZY4/ gbzg==
X-Gm-Message-State: ALoCoQnWgzLpJVd0yO9U3T/guIQkzQbjK6pig4mcetd6MHZCa6WTO7ZYABsDxHZAst53hRQYapuz
X-Received: by 10.180.24.197 with SMTP id w5mr18763709wif.8.1383698709312; Tue, 05 Nov 2013 16:45:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 5 Nov 2013 16:44:29 -0800 (PST)
X-Originating-IP: [2001:67c:370:176:c5c2:c97f:8a38:931]
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 5 Nov 2013 16:44:29 -0800
Message-ID: <CABcZeBNvrWhuzrwZM56mhFDkWrxf9VO49-YKKpzCiuWOxYEg+w@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>, draft-sheffer-tls-bcp@tools.ietf.org
Content-Type: multipart/alternative; boundary=f46d044286e20b981a04ea777661
Subject: [TLS] Curve recommendations for TLS in draft-sheffer-tls-bcp-01
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, 06 Nov 2013 00:45:16 -0000

--f46d044286e20b981a04ea777661
Content-Type: text/plain; charset=ISO-8859-1

Joe and I have discussed this draft.

On the specific issue of the curve recommendations, we don't believe
that the TLS WG should be making TLS-specific EC recommendations
for two reasons:

1. The question of the best curves is something that applies more or
 less across the IETF.

2. The TLS WG doesn't really have the expertise to assess curves.

We will be reaching out to the security ADs and the CFRG to figure
out the best way to come to IETF-wide consensus on this topic
and will come back to the WG with a report once we have done
so.

-Ekr
[For the TLS chairs]

--f46d044286e20b981a04ea777661
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif;font-size:13.33=
3333969116211px">Joe and I have discussed this draft.</div><div style=3D"fo=
nt-family:arial,sans-serif;font-size:13.333333969116211px"><br></div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">

On the specific issue of the curve recommendations, we don&#39;t believe</d=
iv><div style=3D"font-family:arial,sans-serif;font-size:13.333333969116211p=
x">that the TLS WG should be making TLS-specific EC recommendations</div>

<div style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">=
for two reasons:</div><div style=3D"font-family:arial,sans-serif;font-size:=
13.333333969116211px"><br></div><div style=3D"font-family:arial,sans-serif;=
font-size:13.333333969116211px">

1. The question of the best curves is something that applies more or</div><=
div style=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">=
=A0less across the IETF.</div><div style=3D"font-family:arial,sans-serif;fo=
nt-size:13.333333969116211px">

<br></div><div style=3D"font-family:arial,sans-serif;font-size:13.333333969=
116211px">2. The TLS WG doesn&#39;t really have the expertise to assess cur=
ves.</div><div style=3D"font-family:arial,sans-serif;font-size:13.333333969=
116211px">

<br></div><div style=3D"font-family:arial,sans-serif;font-size:13.333333969=
116211px">We will be reaching out to the security ADs and the CFRG to figur=
e</div><div style=3D"font-family:arial,sans-serif;font-size:13.333333969116=
211px">

out the best way to come to IETF-wide consensus on this topic</div><div sty=
le=3D"font-family:arial,sans-serif;font-size:13.333333969116211px">and will=
 come back to the WG with a report once we have done</div><div style=3D"fon=
t-family:arial,sans-serif;font-size:13.333333969116211px">

so.</div><div style=3D"font-family:arial,sans-serif;font-size:13.3333339691=
16211px"><br></div><div style=3D"font-family:arial,sans-serif;font-size:13.=
333333969116211px">-Ekr</div><div style=3D"font-family:arial,sans-serif;fon=
t-size:13.333333969116211px">

[For the TLS chairs]</div></div>

--f46d044286e20b981a04ea777661--

From ynir@checkpoint.com  Tue Nov  5 17:19:37 2013
Return-Path: <ynir@checkpoint.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 E11D611E818C for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 17:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.514
X-Spam-Level: 
X-Spam-Status: No, score=-10.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 6p1I5EBMAaGY for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 17:19:28 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA111E811A for <tls@ietf.org>; Tue,  5 Nov 2013 17:19:27 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA61JQ6k031509 for <tls@ietf.org>; Wed, 6 Nov 2013 03:19:26 +0200
X-CheckPoint: {527997B5-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 03:19:26 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "tls@ietf.org list" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: AQHO2nVrisyeONraYE22idIo0fVZhpoXRgSA
Date: Wed, 6 Nov 2013 01:19:26 +0000
Message-ID: <699721CA-EF4F-4FBA-B1FA-B2AC8EC4303F@checkpoint.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
In-Reply-To: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.11]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E717C3C0AD45324C8E131CB89DD61995@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 01:19:38 -0000

Hi

A few data points:

Currently (with NPN but without ALPN), the length of a ClientHello is about=
 17x bytes for both Chrome and FF, not including the hostname in SNI.

Removing NPN saves 4 bytes, and adding ALPN may add 10-20 bytes, and the SN=
I is unbounded anyways [1]. That doesn't usually get to you 255. But sessio=
n resumption may add the session ID, which is about 32 bytes.=20

Can we assume that the old BigIP don't support ALPN?  If so, you could avoi=
d either ALPN or session resumption with a server that did not return ALPN.=
 Wouldn't this solve the problem?

Yoav


From martin.thomson@gmail.com  Tue Nov  5 17:24:24 2013
Return-Path: <martin.thomson@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 485B921E808F for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 17:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24]
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 vQvinE8oKUK1 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 17:24:23 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 11AA521E80F3 for <tls@ietf.org>; Tue,  5 Nov 2013 17:24:20 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id q58so4231446wes.17 for <tls@ietf.org>; Tue, 05 Nov 2013 17:24:19 -0800 (PST)
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=qq1N7zW68i+/TC//9FcvbpeKT0ukyCQhpfnDHF1t2Ho=; b=wNdh9/gqtTDfW5UFHbkJHZxvU/lk8bMXOmY0afYYXhUspT7r9M1susxW1C2x7mCpxE Mn+cRxMsYyCfVkEGvZgkMFlJbCAL02B0rKeh8YKrQWjBIS7vzM3PzN0P/0rlXkZn/kR2 5goOTWrqfRIVKtmzmtJ20EiRMJyxvGnTrvtGx+SrvNu5UJpLuViK1IIbbCdAvNMPcbzG 1R+mniJzugJ755+BrnFItbAaAuoII3uFqlzfHDnENUV37cHC/0VmmA5uGeOMnFUKa4q1 KMVxTH0cmGWCoBNEP0PkPtu+oFNuS6Oy0OyxlcmGxhN0pGk+1W1kRZ5MFa6neKoYL+kP C3VQ==
MIME-Version: 1.0
X-Received: by 10.194.240.197 with SMTP id wc5mr354019wjc.23.1383701059900; Tue, 05 Nov 2013 17:24:19 -0800 (PST)
Received: by 10.227.202.194 with HTTP; Tue, 5 Nov 2013 17:24:19 -0800 (PST)
In-Reply-To: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com>
Date: Tue, 5 Nov 2013 17:24:19 -0800
Message-ID: <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 01:24:24 -0000

On 5 November 2013 14:21, Brian Smith <brian@briansmith.org> wrote:
> I am
> very concerned about the issues that they've run into where many web
> servers are failing to handshake when the ClientHello message is
> larger than 255 bytes.

I can understand the need to avoid the ceiling in the short term, no
question.  But how much headroom is there?

Having some specific numbers would definitely help inform the
discussion.  Clearly, including SNI with a maximum-length hostname is
going to blow this limit, so the question is where we think the line
needs to be drawn.

Given information on sizes, there are other options available to us.
Changing to shorter ALPN strings, or even moving to binary identifiers
(which would be unpleasant, but probably manageable) are definitely
still possible.  And those are only the solutions that are constrained
to ALPN, if you are willing to look elsewhere, you might instead
suppress SNI instead for long hostnames.  After all,
http://www.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk.com/
created this problem for themselves.

If we're that close to the limit, then a great many of the advantages
of TLS1.3 are likely to be eliminated.  Most of the 0-RTT modes won't
work.

From ynir@checkpoint.com  Tue Nov  5 17:36:29 2013
Return-Path: <ynir@checkpoint.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 53BC811E811A for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 17:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.515
X-Spam-Level: 
X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 6MgvFWAZJgy5 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 17:36:23 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 18AC811E8199 for <tls@ietf.org>; Tue,  5 Nov 2013 17:35:37 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA61Za8r001421 for <tls@ietf.org>; Wed, 6 Nov 2013 03:35:36 +0200
X-CheckPoint: {52799B7E-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 03:35:36 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "tls@ietf.org list" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: AQHO2nVrisyeONraYE22idIo0fVZhpoXR2KAgAADJoA=
Date: Wed, 6 Nov 2013 01:35:35 +0000
Message-ID: <C98EE823-C8BD-4ED3-894A-5F562BE329EE@checkpoint.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com> <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com>
In-Reply-To: <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.11]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C68D9182E4F2A94891C0782843633C0B@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 01:36:29 -0000

One other thing: Microsoft has released IE 11 that has ALPN. So if ALPN mak=
es TLS fail, then those 2.3% of websites are now inaccessible by Internet E=
xplorer. That is one big reason to upgrade their BigIP box.


From geoffk@geoffk.org  Tue Nov  5 18:33:02 2013
Return-Path: <geoffk@geoffk.org>
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 DBAB021F9D94 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 18:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.359
X-Spam-Level: 
X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24]
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 d2u3h5SydSBQ for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 18:32:57 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id E35A421F9D3E for <tls@ietf.org>; Tue,  5 Nov 2013 18:32:57 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 9737433D115; Wed,  6 Nov 2013 02:32:57 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Martin Thomson <martin.thomson@gmail.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com> <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 05 Nov 2013 18:32:57 -0800
In-Reply-To: <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com>
Message-ID: <m27gcm1cpy.fsf@localhost.localdomain>
Lines: 33
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 02:33:03 -0000

Martin Thomson <martin.thomson@gmail.com> writes:

> On 5 November 2013 14:21, Brian Smith <brian@briansmith.org> wrote:
> > I am
> > very concerned about the issues that they've run into where many web
> > servers are failing to handshake when the ClientHello message is
> > larger than 255 bytes.
> 
> I can understand the need to avoid the ceiling in the short term, no
> question.  But how much headroom is there?
> 
> Having some specific numbers would definitely help inform the
> discussion.  Clearly, including SNI with a maximum-length hostname is
> going to blow this limit, so the question is where we think the line
> needs to be drawn.

To give an idea:

A TLS 1.2 ClientHello which lists all the authenticated ciphersuites
currently defined (no anonymous), EC curves and formats, and signature
algorithms, but no SNI, is 528 bytes.  So you can already be way over
255 bytes just with things already defined.

The TLS 1.2 Safari ClientHello in OS X 10.9 when connecting to
ssl.apple.com is 180 bytes, and that has SNI but no NPN or similar,
and a limited number of elliptic curves.

I think the Safari ClientHello is close to the minimum you would want;
that is, if your ClientHello is much shorter, you're probably missing
something more important than ALPN.  I would suggest allowing 30 bytes
for longer domain names.  So there's maybe 45 bytes to split between
ALPN, TLS 1.4, AEAD ciphers, new elliptic curves, and any other
feature that might be implemented in future.

From watsonbladd@gmail.com  Tue Nov  5 19:38:33 2013
Return-Path: <watsonbladd@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 B50F121E8113 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 19:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043,  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 z-nuwwQFIpRU for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 19:38:33 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id E35EA21E80F7 for <tls@ietf.org>; Tue,  5 Nov 2013 19:38:32 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id cb5so4261551wib.2 for <tls@ietf.org>; Tue, 05 Nov 2013 19:38:32 -0800 (PST)
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=ZhJeQK4mP52xy6Bxa/lOZtpfUpJdqFczT50ctmE1yiA=; b=N2XgrEEtupGZ0eB8uh1PUjD+vt4mKawIydwWzrcDQFHS/FnULF3tRryQNigupNylvT A9N6LGrzy0KFr9Zg0MpaRRShFF6zXDsJ5EhOva1C3xE2EJ60ngS4bZabb3IhH/ebip+I xXnEYE+jyKv5LyX6cVBOgzmODVeifX9nBrHEIMNdMbBfEJpfQCv682KfLffZv3+9nOvt CLO9ZNmEx0Pf6d95dyZ92mCXcTDOTMEeHgKe0aLUbgMOH01t3MRZ4RVgkalpxzwgETTe 6H8jMD86ld5+pRU7+54w4FmsXiehTPOxJ1rPUQ9v12mdMr5phNB/ZWKNESSZ4QH0qr5J tegg==
MIME-Version: 1.0
X-Received: by 10.180.12.111 with SMTP id x15mr718381wib.0.1383709112148; Tue, 05 Nov 2013 19:38:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 5 Nov 2013 19:38:32 -0800 (PST)
In-Reply-To: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
References: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
Date: Tue, 5 Nov 2013 19:38:32 -0800
Message-ID: <CACsn0ckySgQBQBsa0HtTKXCt4-23MQ6z+4KUYVhM0+3=xuwzpg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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, 06 Nov 2013 03:38:33 -0000

On Tue, Nov 5, 2013 at 1:08 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> I've just submitted a document on potentially new reduced RT/more
> private protocol flows for TLS 1.3. It's fairly handwavy ATM but I wanted
> to err on the side of getting some of the ideas out for discussion
> so we could figure out which avenues we want to pursue. This draft
> borrows (steals) liberally from a bunch of prior work too numerous
> to name here.
>
> I'll be going over some of this material at today's meeting, but seeing
> as how this just got delivered, I'll make sure you don't need to have
> read the draft to follow along.
Is there a technical reason we can't have the client send an ECDH key,
server respond with ECDH key and signature of client
and server keys, and then use that key for a transmission in the response.
This has one round trip latency, and is secure under standard assumptions.

The second issue is that historically the handshaking has been a
plague upon the security: We should chop out handshakes,
not add them, to simplify the analysis. This assumes we keep the
bloated message+extension format here.
>
> Sorry about the late delivery....
>
> -Ekr
>
>
> Filename:        draft-rescorla-tls13-new-flows
> Revision:        00
> Title:           New Handshake Flows for TLS 1.3
> Creation date:   2013-11-05
> Group:           Individual Submission
> Number of pages: 21
> URL:
> http://www.ietf.org/internet-drafts/draft-rescorla-tls13-new-flows-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-rescorla-tls13-new-flows
> Htmlized:
> http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00
>
>
> Abstract:
>    This document sketches some potential new handshake flows for TLS
>    1.3.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From ynir@checkpoint.com  Tue Nov  5 19:50:59 2013
Return-Path: <ynir@checkpoint.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 57D1E21E815D for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 19:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Level: 
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24]
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 NAS0RymQGcqQ for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 19:50:54 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D39B311E81F7 for <tls@ietf.org>; Tue,  5 Nov 2013 19:50:46 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA63ocvU021673; Wed, 6 Nov 2013 05:50:39 +0200
X-CheckPoint: {5279BB23-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 05:50:38 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: AQHO2nVrisyeONraYE22idIo0fVZhpoXR2KAgAATLYCAABWxgA==
Date: Wed, 6 Nov 2013 03:50:38 +0000
Message-ID: <034ABE49-7A26-4018-80F0-049F2724243B@checkpoint.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com> <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com> <m27gcm1cpy.fsf@localhost.localdomain>
In-Reply-To: <m27gcm1cpy.fsf@localhost.localdomain>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.225]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E0CBFFB444117644A31EE8633FE4D746@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 03:50:59 -0000

On Nov 5, 2013, at 6:32 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:

> Martin Thomson <martin.thomson@gmail.com> writes:
>=20
>> On 5 November 2013 14:21, Brian Smith <brian@briansmith.org> wrote:
>>> I am
>>> very concerned about the issues that they've run into where many web
>>> servers are failing to handshake when the ClientHello message is
>>> larger than 255 bytes.
>>=20
>> I can understand the need to avoid the ceiling in the short term, no
>> question.  But how much headroom is there?
>>=20
>> Having some specific numbers would definitely help inform the
>> discussion.  Clearly, including SNI with a maximum-length hostname is
>> going to blow this limit, so the question is where we think the line
>> needs to be drawn.
>=20
> To give an idea:
>=20
> A TLS 1.2 ClientHello which lists all the authenticated ciphersuites
> currently defined (no anonymous), EC curves and formats, and signature
> algorithms, but no SNI, is 528 bytes.  So you can already be way over
> 255 bytes just with things already defined.
>=20
> The TLS 1.2 Safari ClientHello in OS X 10.9 when connecting to
> ssl.apple.com is 180 bytes, and that has SNI but no NPN or similar,
> and a limited number of elliptic curves.
>=20
> I think the Safari ClientHello is close to the minimum you would want;
> that is, if your ClientHello is much shorter, you're probably missing
> something more important than ALPN.  I would suggest allowing 30 bytes
> for longer domain names.  So there's maybe 45 bytes to split between
> ALPN, TLS 1.4, AEAD ciphers, new elliptic curves, and any other
> feature that might be implemented in future.

Don't forget 32 bytes for session ID or any number of bytes for session tic=
ket in resumption attempts. Now your 45 bytes are down to 13 or less. =20

And as for domain names:
http://www.thelongestdomainnameintheworldandthensomeandthensomemoreandmore.=
com




From nico@cryptonector.com  Tue Nov  5 20:01:32 2013
Return-Path: <nico@cryptonector.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 B30E111E81F7 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 20:01:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.303,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_75=0.6]
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 UBe7UuUD45sw for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 20:01:27 -0800 (PST)
Received: from homiemail-a64.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id BCCF111E81C3 for <tls@ietf.org>; Tue,  5 Nov 2013 20:01:27 -0800 (PST)
Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 79FD2438072 for <tls@ietf.org>; Tue,  5 Nov 2013 20:01:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wueXMjdtxP422ByRPqjK c3HR9wg=; b=cJmTZONCVbupraiREUIhQfYYtKhg1FTFL6eMP2y+CThc3Ip3ZIu0 AFeD/BeQY4XjNURTlY8Z8npQMTuLcrbw/3yaZl+7FciDP1yAXPy4+n+XWzFZL8+E +D51sM5cRm3clpNBfzzBxw75AZGEyWsPnFAHy1RE8YWqdvrWSUl0jOA=
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 2EE8843806C for <tls@ietf.org>; Tue,  5 Nov 2013 20:01:27 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id ex4so3133560wid.15 for <tls@ietf.org>; Tue, 05 Nov 2013 20:01:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+qeMRX/TeN3TnirMVsn+JklynNBXpUQ/37wIy/lx1bA=; b=KP1rGswA2kekfht68Qem1z1X6bcEWRdf0y7/L3TY6U4pHKdCDo9ciXnTQa3o2LzRA7 uM+5vhKA2O3VBpQSni6YYMi1N7F3+nuFOMApSXOxtV8dQKyL840ijTwjDDhwsH7vY86Z kiAvpLeX1NlMn2+kHkDPjo2HfSbAGvT5RKeByNcdW4TtggiRHOmQvp+VXFaS2qbmxRoF 6w4K219laWu7oqklwM563ksF6GRMIOc+UMNKjwtL3HvyuUXbNpYb0U7SEvXQmJnyRg1r 0ssOAcM3nOmOcGsAh4P3QsASXMhWolAM7ayYB2V7gQpnectgFoJYFClUl1Aoft0BPjWH a2vw==
MIME-Version: 1.0
X-Received: by 10.194.11.67 with SMTP id o3mr828031wjb.0.1383710485518; Tue, 05 Nov 2013 20:01:25 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Tue, 5 Nov 2013 20:01:25 -0800 (PST)
In-Reply-To: <CACsn0ckySgQBQBsa0HtTKXCt4-23MQ6z+4KUYVhM0+3=xuwzpg@mail.gmail.com>
References: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com> <CACsn0ckySgQBQBsa0HtTKXCt4-23MQ6z+4KUYVhM0+3=xuwzpg@mail.gmail.com>
Date: Tue, 5 Nov 2013 22:01:25 -0600
Message-ID: <CAK3OfOifhK8KZL_1PRa1R-YHguHf+ZtMZJFG2nNxn7KOiWFDUA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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, 06 Nov 2013 04:01:32 -0000

On Tue, Nov 5, 2013 at 9:38 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> Is there a technical reason we can't have the client send an ECDH key,
> server respond with ECDH key and signature of client
> and server keys, and then use that key for a transmission in the response.
> This has one round trip latency, and is secure under standard assumptions.

Sure, but this is optimistic; there has to be a fallback if the server
doesn't like the client's proposed curve/group/whatever.  The client
could send multiple DH keys, but...  Also, might as well always use
key agreement (which isn't quite the same as PFS, since what should be
ephemeral keys might get reused).

So, at least for initial [and therefore non-resumption] connections
there must be at least an option for a 1.5 round trip handshake.  Note
that a 1.5 round-trip handshake does not add a round-trip's worth of
latency to when the client can start sending application records -- it
only adds local crypto's worth of latency.

> The second issue is that historically the handshaking has been a
> plague upon the security: We should chop out handshakes,
> not add them, to simplify the analysis. This assumes we keep the
> bloated message+extension format here.

The key to this is negotiating key agreement, DH groups/curves, KDFs,
hash functions, server authentication methods, and symmetric (and
authenticated) ciphers+modes separately, in as compact a way as
possible (variable-length bitmasks, with a registry of bit numbers).
With optimal initial assignments (optimal for assignment-time
conditions anyways, or near future) this might yield really, really
small hellos.

Nico
--

From watsonbladd@gmail.com  Tue Nov  5 20:16:33 2013
Return-Path: <watsonbladd@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 9ADF021E80F9 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 20:16:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level: 
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.260,  BAYES_00=-2.599, J_CHICKENPOX_75=0.6, 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 EpdenSGnKWKa for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 20:16:33 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id B54BA21E8104 for <tls@ietf.org>; Tue,  5 Nov 2013 20:16:30 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id ey11so3099092wid.1 for <tls@ietf.org>; Tue, 05 Nov 2013 20:16:29 -0800 (PST)
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=4x55lPcGHd6zbUFB5JNuZFUXJX/8WIqjYbcIqlrEsC0=; b=sahfZRVoUT788pJH6j2shcxh7+HKUhorJNP0MW/o02KJkpqatNxsQkJ9O6qdDe0dKU ZAZu+RnzBoJTSNKo2uB95VZ1eV/Bl3y/VAgMWvVPYxjryisYtTptX8MJ6GFD0kakkmkQ DHayDJyqp8UfWyFlL7DEYUwigsaQEfEWe6ElJROg1FvZQehYbRfPSDlNbbr3jxPmOU+h liSxiazZVDrz8LLV7hhYfKqLJ+e3Y10usLJI6ld8n79sTT68LMc4VvWZrgNeFPgNjQrL 0vL6BDD+WB38+Ywp8xyrGQ4lIpxMTUyge5xG0V/YvCOhnwEI+RRSTN+OO2fMjU2W8RbB L65w==
MIME-Version: 1.0
X-Received: by 10.180.106.133 with SMTP id gu5mr19734943wib.0.1383711389615; Tue, 05 Nov 2013 20:16:29 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 5 Nov 2013 20:16:29 -0800 (PST)
In-Reply-To: <CAK3OfOifhK8KZL_1PRa1R-YHguHf+ZtMZJFG2nNxn7KOiWFDUA@mail.gmail.com>
References: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com> <CACsn0ckySgQBQBsa0HtTKXCt4-23MQ6z+4KUYVhM0+3=xuwzpg@mail.gmail.com> <CAK3OfOifhK8KZL_1PRa1R-YHguHf+ZtMZJFG2nNxn7KOiWFDUA@mail.gmail.com>
Date: Tue, 5 Nov 2013 20:16:29 -0800
Message-ID: <CACsn0ckFFzhsmaBaXXNb7eeDA7DhSGw6JZdFR9_4KQYLrroNcQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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, 06 Nov 2013 04:16:33 -0000

On Tue, Nov 5, 2013 at 8:01 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 5, 2013 at 9:38 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>> Is there a technical reason we can't have the client send an ECDH key,
>> server respond with ECDH key and signature of client
>> and server keys, and then use that key for a transmission in the response.
>> This has one round trip latency, and is secure under standard assumptions.
>
> Sure, but this is optimistic; there has to be a fallback if the server
> doesn't like the client's proposed curve/group/whatever.  The client
> could send multiple DH keys, but...  Also, might as well always use
> key agreement (which isn't quite the same as PFS, since what should be
> ephemeral keys might get reused).
>
> So, at least for initial [and therefore non-resumption] connections
> there must be at least an option for a 1.5 round trip handshake.  Note
> that a 1.5 round-trip handshake does not add a round-trip's worth of
> latency to when the client can start sending application records -- it
> only adds local crypto's worth of latency.
Solution: the client says what it will accept and offer, and the
server goes first. Actually,
I don't like that idea because we have to have the server present an
authentication of the handshake.
The fact that we need this is utterly horrid: there should be so few
options that
the chances of success are very good.

Seriously, why don't we resolve to do it right this time? Yes,
backwards compatibility matters, but at this point
it will break because RC4 is dead, and so is AtE without seriously clever fixes.
>
>> The second issue is that historically the handshaking has been a
>> plague upon the security: We should chop out handshakes,
>> not add them, to simplify the analysis. This assumes we keep the
>> bloated message+extension format here.
>
> The key to this is negotiating key agreement, DH groups/curves, KDFs,
> hash functions, server authentication methods, and symmetric (and
> authenticated) ciphers+modes separately, in as compact a way as
> possible (variable-length bitmasks, with a registry of bit numbers).
> With optimal initial assignments (optimal for assignment-time
> conditions anyways, or near future) this might yield really, really
> small hellos.
Will anyone not using AES_GCM, AES_SHA256, or the ECDHE variants
thereof, please explain to the list
what your reason is?
>
> Nico
> --



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From n.mavrogiannopoulos@gmail.com  Wed Nov  6 01:09:39 2013
Return-Path: <n.mavrogiannopoulos@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 C61A111E819C for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 01:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Km1nLS6Np+m5 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 01:09:39 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B568911E8196 for <tls@ietf.org>; Wed,  6 Nov 2013 01:09:38 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id el20so1480037lab.33 for <tls@ietf.org>; Wed, 06 Nov 2013 01:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8CYcxVEG6TEY3pmvdFjfg5vmfjOWSGQsuKZKDpfkBs0=; b=UZmq8TwONyy8xksgCQHXWcXxETDriTQ8+UpSMY9ZURJP0kn3kJ8roHkimY+Hz+y4CE so0erCLeDq+05mZhgop08ZF08EZWIZBrHCDFRsHiwz0CVET3QxvwWVqS8RhA/foroSkl uKb1wFmLr6wNnuAb5ePgrmFNm4xrjojvbDgcMRKeL5c8RH1+Yim8Gwj6RLTJNdFXTWZ3 ALNV5RBs0gHuonZDL9JG9mwthLE1k2aYxcI2dmCdL2ABrB4T552Jd2+BnlzxTLM4/56V kQV01MSfPOr7NVOIErRiV4oTAzfLSRKoAkxvIM8wCLK6+nbZEY4iu1sVuVPpd2IKWP+u VnXQ==
MIME-Version: 1.0
X-Received: by 10.152.87.17 with SMTP id t17mr1596399laz.6.1383728977329; Wed, 06 Nov 2013 01:09:37 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Wed, 6 Nov 2013 01:09:37 -0800 (PST)
In-Reply-To: <CABcZeBNvrWhuzrwZM56mhFDkWrxf9VO49-YKKpzCiuWOxYEg+w@mail.gmail.com>
References: <CABcZeBNvrWhuzrwZM56mhFDkWrxf9VO49-YKKpzCiuWOxYEg+w@mail.gmail.com>
Date: Wed, 6 Nov 2013 10:09:37 +0100
X-Google-Sender-Auth: tZZBCdMT-VaSQ5jpfpfYVQvShMQ
Message-ID: <CAJU7zaLv8Kj8dvVkvPJ2KP2R6iJ9+a1kh0x0dnMnVqAGBcza8w@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>, draft-sheffer-tls-bcp@tools.ietf.org
Subject: Re: [TLS] Curve recommendations for TLS in draft-sheffer-tls-bcp-01
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, 06 Nov 2013 09:09:40 -0000

On Wed, Nov 6, 2013 at 1:44 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> On the specific issue of the curve recommendations, we don't believe
> that the TLS WG should be making TLS-specific EC recommendations
> for two reasons:
>
> 1. The question of the best curves is something that applies more or
>  less across the IETF.
>
> 2. The TLS WG doesn't really have the expertise to assess curves.

Well, while arguing about the "best" curves to use is indeed
controversial, but what if the draft is confined to list the curves
sufficient in terms of length? I.e., if it suggests the curves that
their length provides adequate security for today's needs. I think
that would help implementers and users of TLS without getting into
controversial issues.

regards,
Nikos

From n.mavrogiannopoulos@gmail.com  Wed Nov  6 01:29:06 2013
Return-Path: <n.mavrogiannopoulos@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 D4BBD11E8194 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 01:29:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 stwQw51wd4r8 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 01:29:06 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id EE27A11E819A for <tls@ietf.org>; Wed,  6 Nov 2013 01:29:00 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id y6so7592546lbh.11 for <tls@ietf.org>; Wed, 06 Nov 2013 01:28:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rNkPE8E9SpLOXwOkhcebpgDHjm18VOx/zFsy8iF+YGY=; b=lFOD0ffp4JqahQArfdlkZsqLyT/u8U8zzXi1TBWl47pvBEXbfgkPy1oyRqG7DbHNEk pnGX7lhQ3eA1LsElkeascc4JhTPFqo7YIbfRf7RLY9apzrIF8KtAJeXMqzUDR1VxIIof Xzoz334mCpssY1EYP8G/4BqaFYhvyqBkt9PV+6poYyt2wS0phHQINnTHJrVa3/V4+GKT W93MmAUDlSTOZF6/zB+3tyDuWHTCDSdu1UVtSJNyEKlwmZPjrC+Rp8ZMYv/eW7oT1RAt 26SDMblkq4DL0vWLBz6LAsSb33dTohkD29whyoqSHJdugDyeOJU7P3atv4dkJJPQX6pY eMXA==
MIME-Version: 1.0
X-Received: by 10.112.205.34 with SMTP id ld2mr1880073lbc.27.1383730133962; Wed, 06 Nov 2013 01:28:53 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Wed, 6 Nov 2013 01:28:53 -0800 (PST)
In-Reply-To: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
References: <CABcZeBPcJW7juru-RsYM+_of8xTd8Nk0xRJApztcmoEh3r-EoQ@mail.gmail.com>
Date: Wed, 6 Nov 2013 10:28:53 +0100
X-Google-Sender-Auth: FKDuRugLd91UvzvoWWP8Sv3CPVo
Message-ID: <CAJU7zaJ+qGbVzANAJpGL0Y1O_ZFH4dgXEP+AJFeuo7+sowTsQQ@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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, 06 Nov 2013 09:29:07 -0000

On Tue, Nov 5, 2013 at 10:08 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> I've just submitted a document on potentially new reduced RT/more
> private protocol flows for TLS 1.3. It's fairly handwavy ATM but I wanted
> to err on the side of getting some of the ideas out for discussion
> so we could figure out which avenues we want to pursue. This draft
> borrows (steals) liberally from a bunch of prior work too numerous
> to name here.

I don't quite like that all the abbreviated handshakes make use of
cached information. Does this really scale? I mean do we expect each
client to keep a database of every host it connected? I'm afraid that
if cache information are required then these handshakes will be used
to connect to popular sites, and everyone else will be using the old
non-cached-data depended handshake. This adds complexity as everyone
would have to implement the old and the new handshakes.

In fact the same effect with cached information is present with
session tickets, which is even lighter and available today.

Maybe instead of cached information, move the choice of the parameters
to the client (and maybe give the server the option to discard them
and use others at the cost of an additional RTT and a
ClientKeyExchange).

The handshakes in Figure 6 and 7 look quite promising (although I
don't get the idea of AlmostFinished). What is its purpose?

regards,
Nikos

From frantz@pwpconsult.com  Wed Nov  6 06:02:25 2013
Return-Path: <frantz@pwpconsult.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 9D94911E8165 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 06:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 izKaNYKR60C0 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 06:02:21 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 014A311E8102 for <tls@ietf.org>; Wed,  6 Nov 2013 06:02:20 -0800 (PST)
Received: from [64.17.80.205] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1Ve3gZ-0001i5-Jv for tls@ietf.org; Wed, 06 Nov 2013 09:02:19 -0500
Date: Wed,  6 Nov 2013 06:02:20 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: tls@ietf.org
X-Priority: 3
In-Reply-To: <CAJU7zaJ+qGbVzANAJpGL0Y1O_ZFH4dgXEP+AJFeuo7+sowTsQQ@mail.gmail.com>
Message-ID: <r422Ps-1075i-412D89056F5641B89D60B746AC0CE7ED@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79cd21267e497769623c39caee6ce5d8d5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.17.80.205
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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, 06 Nov 2013 14:02:25 -0000

On 11/6/13 at 1:28 AM, nmav@gnutls.org (Nikos Mavrogiannopoulos) wrote:

>I don't quite like that all the abbreviated handshakes make use of
>cached information. Does this really scale? I mean do we expect each
>client to keep a database of every host it connected?

If we are only concerned with HTTP, and all the cacheing is at=20
the client side, things should scale quite well. Assuming the=20
cached data is 10K bytes, you would be able to hold 200-300=20
sites for the storage cost of one digital picture -- well within=20
the capacity of even a smart phone.

The cache would only contain the sites of interest to the user.=20
My cache would not have an entry for Facebook or Twitter, which=20
I never use, but would have entries for www.caves.org and www.qrz.com.

If caching is required on the server side, it would be an=20
additional burden for Periwinkle. www.pwpconsult.com is a simple=20
web site that displays the same information to every visitor.=20
The only per visitor information may be a log entry. (I question=20
if HTTPS is really appropriate for web sites like Periwinkle.=20
Defeating traffic analysis is a separate problem.)

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said=20
users haven't
www.pwpconsult.com | learned anything about security?" -- Bruce Schneier


From rsalz@akamai.com  Wed Nov  6 06:24:17 2013
Return-Path: <rsalz@akamai.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 A1F1711E8102 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 06:24:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 fW4cCCt22J1p for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 06:24:12 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2B111E8140 for <tls@ietf.org>; Wed,  6 Nov 2013 06:24:12 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 98AB648197; Wed,  6 Nov 2013 14:24:11 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 8B6A24819A; Wed,  6 Nov 2013 14:24:11 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id DEE2247BD2; Wed,  6 Nov 2013 14:24:07 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 6 Nov 2013 09:24:05 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Bill Frantz <frantz@pwpconsult.com>, "tls@ietf.org" <tls@ietf.org>
Date: Wed, 6 Nov 2013 09:24:03 -0500
Thread-Topic: [TLS] Potential New Handshake Flows for TLS 1.3
Thread-Index: Ac7a+NSjh1IKdzCQTH+01U7S2cAxFQAAptBw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA34695D@USMBX1.msg.corp.akamai.com>
References: <CAJU7zaJ+qGbVzANAJpGL0Y1O_ZFH4dgXEP+AJFeuo7+sowTsQQ@mail.gmail.com> <r422Ps-1075i-412D89056F5641B89D60B746AC0CE7ED@Williams-MacBook-Pro.local>
In-Reply-To: <r422Ps-1075i-412D89056F5641B89D60B746AC0CE7ED@Williams-MacBook-Pro.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Potential New Handshake Flows for TLS 1.3
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, 06 Nov 2013 14:24:17 -0000

> If caching is required on the server side,

I would expect that to be problematic for any big site that is spread aroun=
d multiple locations, or even just multiple racks in a datacenter, or blade=
s in a rack. Unless you can pin the client to a specific IP address which d=
oesn't move.

	/r$
-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA


From p.gutmann@auckland.ac.nz  Tue Nov  5 22:53:02 2013
Return-Path: <p.gutmann@auckland.ac.nz>
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 AF66F21E80AE for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 22:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 76mb-fbFPNy6 for <tls@ietfa.amsl.com>; Tue,  5 Nov 2013 22:52:57 -0800 (PST)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2335821E8063 for <tls@ietf.org>; Tue,  5 Nov 2013 22:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1383720777; x=1415256777; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=t7OHaFcgf6g0Ar5Jr4FK9rkMRJpY9HqGaGEdjFJKfKk=; b=T+Pf/kResERBvK7QnLYdXC53Fg21tjlnk+1c5OuahItuxdQr+UM8vDjY 2clWOlLONJuPPC1uHr80KsWYGmscspFwAsp7YItiwFfhup1WwPZIMdltD N5uz5GcQE43LzSCYK+C4cBaZZJ4ug+eVujqrmJb/DJVHMbV88Jc9uyMUo s=;
X-IronPort-AV: E=Sophos;i="4.93,644,1378814400"; d="scan'208";a="287017409"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Nov 2013 19:52:43 +1300
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.207]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 19:52:42 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2dskaCaL/Q4ufEA6jUw/n4g==
Date: Wed, 6 Nov 2013 06:52:42 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 06 Nov 2013 08:00:32 -0800
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 06:54:12 -0000

Brian Smith <brian@briansmith.org> writes:=0A=
=0A=
>I am very concerned about the issues that they've run into where many web=
=0A=
>servers are failing to handshake when the ClientHello message is larger th=
an=0A=
>255 bytes.=0A=
=0A=
I'm curious as to how something like this could come about, is anyone famil=
iar=0A=
with the code base for something that does this?  Is there actually code ou=
t=0A=
there that explicitly checks:=0A=
=0A=
  if( sizeof( client_handshake ) > 255 )=0A=
    return( -1 );=0A=
=0A=
and if so, why?=0A=
=0A=
Peter.=0A=

From john.mattsson@ericsson.com  Wed Nov  6 08:06:11 2013
Return-Path: <john.mattsson@ericsson.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 F29AA21E8147 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 08:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Level: 
X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 5IuA9QKO8iyD for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 08:06:05 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12C21E8140 for <tls@ietf.org>; Wed,  6 Nov 2013 08:06:05 -0800 (PST)
X-AuditID: c1b4fb30-b7eff8e000006d14-f2-527a68eb0508
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.49.27924.BE86A725; Wed,  6 Nov 2013 17:06:04 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.88]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 17:06:03 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo21sv4RcDkL02knsdaQq+3gQATLHMA
Date: Wed, 6 Nov 2013 16:06:03 +0000
Message-ID: <CAAB765F71FCD344B6BABC031C19EC490F2F73@ESESSMB307.ericsson.se>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvje6bjKogg8k93BZrjj5ntvh0vovR gcnj9++HjB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY/uE6Y0E3Z8X/a79ZGxg3sHcxcnJICJhI HNn/mQnCFpO4cG89G4gtJHCIUWJRo1sXIxeQvYhRoqfvJFiCTcBAYu6eBiCbg0NEwFdi9nVu EFNYQEHi7hsWkAoRAUWJO2+7WSFsI4nLZ7aAxVkEVCQeTzzKDlLOK+At8edPJcSmMImeP0vA hnMKhEusn9PEDGIzAl3z/dQasMuYBcQlbj2ZD3WlgMSSPeeZIWxRiZeP/7FC2EoSi25/hqrX kViw+xMbhK0tsWzha7B6XgFBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25iZk56ufkm RmAUHNzy22AH46b7YocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOH1/ zqrbmtv0T//XK2zOldi2pa9UWHBGhOz1SeLu+4+a9PJP/vbU5/llm5ibxf/ObXWpOlNQvChh codBDPtsTw6R3q4b+4JKF2Wf4NRPWa4msftJ9O6fmzc2fw644mvzRGTnKfHParaTq/yOdprp vmBXfLjswp/Mtf1FxYuD3oey2N7IZ7DfqcRSnJFoqMVcVJwIACFVxbRQAgAA
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 16:06:11 -0000

Isn't the most probable explanation that they use an unsigned 8-bit int to =
store the length of the ClientHello message?

Then they might check that the length actually fits (as your example code),=
 get some overflow exception, or just succeeding in discarding the most sig=
nificant bits in the length.

/John


-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter=
 Gutmann
Sent: den 6 november 2013 07:53
To: <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns

Brian Smith <brian@briansmith.org> writes:

>I am very concerned about the issues that they've run into where many=20
>web servers are failing to handshake when the ClientHello message is=20
>larger than
>255 bytes.

I'm curious as to how something like this could come about, is anyone famil=
iar with the code base for something that does this?  Is there actually cod=
e out there that explicitly checks:

  if( sizeof( client_handshake ) > 255 )
    return( -1 );

and if so, why?

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From ynir@checkpoint.com  Wed Nov  6 08:11:03 2013
Return-Path: <ynir@checkpoint.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 E358321E8082 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 08:11:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.513
X-Spam-Level: 
X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 u5VSkgqakrgJ for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 08:10:58 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3088821E811B for <tls@ietf.org>; Wed,  6 Nov 2013 08:10:47 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA6GA1Kx029397; Wed, 6 Nov 2013 18:10:01 +0200
X-CheckPoint: {527A6866-2D-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 18:10:01 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2isyeONraYE22idIo0fVZhgAPReSA
Date: Wed, 6 Nov 2013 16:10:00 +0000
Message-ID: <85A3F57D-D011-40B5-8CFB-52D9BAB07FF3@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.122]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <40A0780DD986BC40B8CBBB615C53311F@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 16:11:04 -0000

On Nov 5, 2013, at 10:52 PM, Peter Gutmann <p.gutmann@auckland.ac.nz>
 wrote:

> Brian Smith <brian@briansmith.org> writes:
>=20
>> I am very concerned about the issues that they've run into where many we=
b
>> servers are failing to handshake when the ClientHello message is larger =
than
>> 255 bytes.
>=20
> I'm curious as to how something like this could come about, is anyone fam=
iliar
> with the code base for something that does this?  Is there actually code =
out
> there that explicitly checks:
>=20
>  if( sizeof( client_handshake ) > 255 )
>    return( -1 );
>=20
> and if so, why?

Based on no actual knowledge, maybe it's part of some anti-DoS scheme.

Big ClientHello --> Weird --> Attack=

From X.Wu@f5.com  Wed Nov  6 10:00:36 2013
Return-Path: <X.Wu@f5.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 C7AE721F99F8 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 tcRzw+oZQy4R for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:00:32 -0800 (PST)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0976011E80F9 for <tls@ietf.org>; Wed,  6 Nov 2013 10:00:32 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="86508893"
X-IPAS-Result: AqIEAHSDelLAqArr/2dsb2JhbABaDoMxU782gTt0giUBAQEBAwEBATc0FwQCAQgNAQMEAQEfCQcnCxQJCAEBBAESCIgGvwkTBI8oOAaDGoEQA55wjg0/gio
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 06 Nov 2013 18:00:06 +0000
Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 10:00:05 -0800
From: Xiaoyong Wu <X.Wu@F5.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2dskaCaL/Q4ufEA6jUw/n4gAWXiRA
Date: Wed, 6 Nov 2013 18:00:05 +0000
Message-ID: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.16.250]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 18:00:36 -0000

It is a little bit more calculation than that and related to some historic =
reasons, aka SSLv2.

For SSL records, the SSLv3 and TLS ClientHello headers are as follows:

| 22 | version major | version minor | length high bits | length low bits |

If this is interpreted as an SSLv2 header, it will be considered as a 3 byt=
e header:
| v2 header b0 | v2 header b1 | v2 header b2 | message type |=20

The value for Client Hello message type is SSLV2_MT_CLIENTHELLO which is 1.
When there is an SSLv3/TLS client-hello of length 256 - 511 bytes, this is =
ambiguous as "message type" is 1 or it is the "length high bits" to be 1.

Out implementation before the patch was to prefer SSLv2 and thus the issue.

As I am explaining this in detail, I would say that another work around on =
this would be making a client hello that exceeds 512 in length.

-Xiaoyong

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Pet=
er
> Gutmann
> Sent: Tuesday, November 05, 2013 10:53 PM
> To: <tls@ietf.org>
> Subject: Re: [TLS] ALPN concerns
>=20
> Brian Smith <brian@briansmith.org> writes:
>=20
> >I am very concerned about the issues that they've run into where many
> >web servers are failing to handshake when the ClientHello message is
> >larger than
> >255 bytes.
>=20
> I'm curious as to how something like this could come about, is anyone fam=
iliar
> with the code base for something that does this?  Is there actually code =
out
> there that explicitly checks:
>=20
>   if( sizeof( client_handshake ) > 255 )
>     return( -1 );
>=20
> and if so, why?
>=20
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From agl@google.com  Wed Nov  6 10:03:46 2013
Return-Path: <agl@google.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 0469911E815A for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Tl0NfogIH-6q for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:03:45 -0800 (PST)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5F11E80D9 for <tls@ietf.org>; Wed,  6 Nov 2013 10:03:45 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id ht10so6911864vcb.34 for <tls@ietf.org>; Wed, 06 Nov 2013 10:03:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Zu3xcxQJfxxpT0z4vznIJbPHJbHdV+FZk8iuFXctOF0=; b=O7s4Bp16xv76ZLaZa4qTT7xl+p5wug7BqA7djpGKiwYk8PjzxUm2Ws8tUfVZ7mBwk3 tFC7Ai9OJatm+U/bDrd/b9+VlTBqantkXrJ3QmZuo8x+2v/cYvAD68IAPRsNMkQEKU5H nr2f0g1gDYcG13rvQqzW7xL33IIQaS0PZLnfsUOkDE/S3IA7fdVCEssQX39//KaXCQGO TN6l5TmuHgWVsT71xSQpy+gdNbCNhyIo848at6eaXhk+hwRIKUBTsy4UFYHiD+vvHT9t F1mXXDOCPJS76eRiLEp531CZo1ac8tiEBo72gC5i8x0vs1vfDRbkiPpI5sbVLfdEUmE1 rDsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Zu3xcxQJfxxpT0z4vznIJbPHJbHdV+FZk8iuFXctOF0=; b=N8OO5KAiyE983z7sO/W84/LlDxREd8PH7DJMnJGcPWpQBOIds7ExIB4WPJT9+D4l8Z rwEjIeQc/ZsaP2tU+Y/4zt0PbQ+xNF9QGdKeMDjKCpQyoCS/5nn7OZTg94KZ3fAI3C6S jvZUHvAiFlkedemZVHc76spLV3Yn99IzTAy2435wwvQqw9H9bHL8FWyehupRwTfnR7Yw hNiNtNxbpUffjk7ySOxMtEIhICihA8UyRU8/MOZSprinNfw/7Yia7amVsv6YvTSB7JfZ SCDbH9NOLZkG7KTcOvrW+70YdXt8ufqnT6mvkrhGGLlwhAQ7eEc1N/5O7Mh+CYf4ghN/ y2/A==
X-Gm-Message-State: ALoCoQlsw43QQQli3PEkbxh6aKOEhH/8BfUVNFMzEoETFm+Y8l4Q4j83dVUgD7nt3HPcFCKpvEL75a7wGI/QJPedY5zfcWWhbsAq4eNUQ6Ft/AqQs8xmVYIlDmC2SpcR3FFzOVDWJj45m+y4dQqv3LIeWrVfI5oUYxivC6x88ojcH1seZEKsuPvu589ATVPhLQPjnd5jiFUM
X-Received: by 10.52.36.40 with SMTP id n8mr2985759vdj.34.1383761024973; Wed, 06 Nov 2013 10:03:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 6 Nov 2013 10:03:24 -0800 (PST)
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
From: Adam Langley <agl@google.com>
Date: Wed, 6 Nov 2013 13:03:24 -0500
Message-ID: <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com>
To: Xiaoyong Wu <X.Wu@f5.com>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 18:03:46 -0000

On Wed, Nov 6, 2013 at 1:00 PM, Xiaoyong Wu <X.Wu@f5.com> wrote:
> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.

^^^ Holy crap. I wish I had known that sooner. That might solve the issue.


Cheers

AGL

From ynir@checkpoint.com  Wed Nov  6 10:11:29 2013
Return-Path: <ynir@checkpoint.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 65C4721E817D for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.515
X-Spam-Level: 
X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 JT5gvAQLi3qq for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:11:15 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 64A9021E808D for <tls@ietf.org>; Wed,  6 Nov 2013 10:11:04 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA6IAaGq030066; Wed, 6 Nov 2013 20:10:36 +0200
X-CheckPoint: {527A84A8-1-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 20:10:36 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Adam Langley <agl@google.com>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2isyeONraYE22idIo0fVZhgATHfeAAAAdpwAAAEA5gA==
Date: Wed, 6 Nov 2013 18:10:35 +0000
Message-ID: <C43F816A-DD7B-441D-98F1-BB64F4997EE5@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com>
In-Reply-To: <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.10]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <65A1D17295DA1941879357F2E1FEF352@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 18:11:29 -0000

On Nov 6, 2013, at 10:03 AM, Adam Langley <agl@google.com> wrote:

> On Wed, Nov 6, 2013 at 1:00 PM, Xiaoyong Wu <X.Wu@f5.com> wrote:
>> As I am explaining this in detail, I would say that another work around =
on this would be making a client hello that exceeds 512 in length.
>=20
> ^^^ Holy crap. I wish I had known that sooner. That might solve the issue=
.

Time to standardize the "jpeg-of-cat" extension for TLS.


From lists@drh-consultancy.co.uk  Wed Nov  6 10:13:07 2013
Return-Path: <lists@drh-consultancy.co.uk>
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 A305D21F9339 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 2kBD1NM3OBEt for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 10:13:03 -0800 (PST)
Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by ietfa.amsl.com (Postfix) with ESMTP id 08FA611E8164 for <tls@ietf.org>; Wed,  6 Nov 2013 10:13:03 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:43532 helo=[192.168.7.9]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10465) with esmtpa (authdaemon_plain:drh) id 1Ve7b9-0002Gh-EW for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Wed, 06 Nov 2013 18:12:59 +0000
Message-ID: <527A86A7.5080700@drh-consultancy.co.uk>
Date: Wed, 06 Nov 2013 18:12:55 +0000
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>	<E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com>
In-Reply-To: <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 18:13:07 -0000

On 06/11/2013 18:03, Adam Langley wrote:
> On Wed, Nov 6, 2013 at 1:00 PM, Xiaoyong Wu <X.Wu@f5.com> wrote:
>> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.
> 
> ^^^ Holy crap. I wish I had known that sooner. That might solve the issue.
> 

Just did a quick test with OpenSSL on a couple of known "hang" machines. Seems
to work.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From seonghan.shin@aist.go.jp  Wed Nov  6 11:25:21 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 8A9F921E8189 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 11:25:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 aS5LujzclUnm for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 11:25:17 -0800 (PST)
Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB9211E81C7 for <tls@ietf.org>; Wed,  6 Nov 2013 11:25:15 -0800 (PST)
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUnqXmvYO4bLPYX7xDlClQs9tmD/RyoWR@postini.com; Wed, 06 Nov 2013 11:25:15 PST
Received: by mail-lb0-f182.google.com with SMTP id w6so91669lbh.41 for <tls@ietf.org>; Wed, 06 Nov 2013 11:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=xh22HQaFNNqSWhHsP8jwcnOXapX0zYpxt1KDNMS+zPM=; b=wXxbkphlAoLiDqWoTy0NCw4056+7aFGEwZ83X2kfVa39y+cECMd72QipdS+HNeOPWd WUxsEwynbh98LPz4ZCeXdKPu1kSnyZbjNEaFrNbmP3U9TlDPOwNYTZijkPWJnt+I8FVO bLkKlHWAu7ebT9cQjtDEMVmcTwlFM0DpSvVRk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=xh22HQaFNNqSWhHsP8jwcnOXapX0zYpxt1KDNMS+zPM=; b=M2Q2MavicBNg4qS2QYXPGhEORzlT7fclXDijCZV7/v8qTFtODxl/wE9JebKHz1mbXp YV/VwBJEiwWBsetkTv/wTuKG3aYdRxr5YQxodheC0YfoTbhxYWuveL+I8DJb1mzO9FvN pJxTNg4VT8RWYwKGytQjoovigVbs4yGL/stsVJpNm8wW196kLJMnkJtbhaGu5h9wk0Ey GGnQAUkqWkHz2X3WCbYchGJ9A6K0iJkZNUtNQ9n/7LFeHAqB721/8blWXpfsxAJGcXuh 0Ii88UtsktinrhNPq9nP+ht7r+MktANod02TPijMFcmMhA4ltj872nKAjo97E70zmjsP Euag==
X-Gm-Message-State: ALoCoQl1MWTKk2SdbHO9My6rQYOGfYbbgAij2GaGonmJavwv9p1OYTlpk7J4CP55I1hACBj2G8Y2hzsb5VCU3l9aTJGLwFcC2IzA14oWaDZvQuBzlRhKAwNoAka2nbz8J4gb+SBIZLMC09g8brZ/lz7FPXxF31m9xA==
X-Received: by 10.112.204.74 with SMTP id kw10mr3750843lbc.13.1383765913396; Wed, 06 Nov 2013 11:25:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.204.74 with SMTP id kw10mr3750832lbc.13.1383765913245; Wed, 06 Nov 2013 11:25:13 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Wed, 6 Nov 2013 11:25:13 -0800 (PST)
Date: Thu, 7 Nov 2013 04:25:13 +0900
Message-ID: <CAEKgtqmfHpzNye_DCgyzJ7PmsGRFWCHAtjX=HOLKo0OEoEi0gQ@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a11c3bb34b629f704ea871bd0
Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= <k-kobara@aist.go.jp>
Subject: [TLS] Augmented PAKE (Re: New Version Notification for draft-shin-tls-augpake-01.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, 06 Nov 2013 19:25:21 -0000

--001a11c3bb34b629f704ea871bd0
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

For anyone who are interested in PAKE, pls see the below I-D regarding
augmented PAKE.

IMO, two reasons that SRP was published as RFC 2945 and included in IEEE
1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the
server's computation cost of SRP is a minimum.
(Though SRP has no provable security)

The AugPAKE in the below I-D is provably secure and more efficient than
other augmented PAKEs (including SRP and AMP).

Of course, augmented PAKE provides additional security property over
(balanced) PAKE.

Best regards,
Shin


On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin <seonghan.shin@aist.go.jp>wrote:

> Dear all,
>
> I submitted a new version of our I-D regarding augmented PAKE (AugPAKE)
> and its integration into TLS.
> I added some features of AugPAKE in Appendix.
> Any comments are welcome!
>
> Best regards,
> Shin
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Wed, Sep 4, 2013 at 6:26 PM
> Subject: New Version Notification for draft-shin-tls-augpake-01.txt
> To: Kazukuni Kobara <kobara_conf-ml@aist.go.jp>, SeongHan Shin <
> seonghan.shin@aist.go.jp>
>
>
>
> A new version of I-D, draft-shin-tls-augpake-01.txt
> has been successfully submitted by SeongHan Shin and posted to the
> IETF repository.
>
> Filename:        draft-shin-tls-augpake
> Revision:        01
> Title:           Augmented Password-Authenticated Key Exchange for
> Transport Layer Security (TLS)
> Creation date:   2013-09-04
> Group:           Individual Submission
> Number of pages: 19
> URL:
> http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-shin-tls-augpake
> Htmlized:        http://tools.ietf.org/html/draft-shin-tls-augpake-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-shin-tls-augpake-01
>
> Abstract:
>    This document describes an efficient augmented password-authenticated
>    key exchange (AugPAKE) protocol where a user remembers a low-entropy
>    password and its verifier is registered in the intended server.  In
>    general, the user password is chosen from a small set of dictionary
>    whose space is within the off-line dictionary attacks.  The AugPAKE
>    protocol described here is secure against passive attacks, active
>    attacks and off-line dictionary attacks (on the obtained messages
>    with passive/active attacks), and also provides resistance to server
>    compromise (in the context of augmented PAKE security).  Based on the
>    AugPAKE protocol, this document also specifies a new password-only
>    authentication handshake for Transport Layer Security (TLS) protocol.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a11c3bb34b629f704ea871bd0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div>Dear all,<br><br></div>For a=
nyone who are interested in PAKE, pls see the below I-D regarding augmented=
 PAKE.<br><br></div>IMO, two reasons that SRP was published as RFC 2945 and=
 included in IEEE 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAK=
E and 2) the server&#39;s computation cost of SRP is a minimum.<br>
</div></div>(Though SRP has no provable security)<br><br></div>The AugPAKE =
in the below I-D is provably secure and more efficient than other augmented=
 PAKEs (including SRP and AMP).<br><br></div><div>Of course, augmented PAKE=
 provides additional security property over (balanced) PAKE.<br>
<br></div><div>Best regards,<br>Shin<br></div><div><div><div><div><div><div=
><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Sep 4, 2013 at 6:39 PM, SeongHan Shin <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:seonghan.shin@aist.go.jp" target=3D"_blank">seonghan.shin@aist.go.jp</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><div>De=
ar all,<br><br></div>I submitted a new version of our I-D regarding augment=
ed PAKE (AugPAKE) and its integration into TLS.<br>
</div>I added some features of AugPAKE in Appendix.<br>
</div>Any comments are welcome!<br><br></div>Best regards,<br></div>Shin<br=
><div><div><div><div><div><div><div><div><div class=3D"h5"><br><div class=
=3D"gmail_quote">---------- Forwarded message ----------<br>From: <b class=
=3D"gmail_sendername"></b> <span dir=3D"ltr">&lt;<a href=3D"mailto:internet=
-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;</span>=
<br>

Date: Wed, Sep 4, 2013 at 6:26 PM<br>Subject: New Version Notification for =
draft-shin-tls-augpake-01.txt<br>To: Kazukuni Kobara &lt;<a href=3D"mailto:=
kobara_conf-ml@aist.go.jp" target=3D"_blank">kobara_conf-ml@aist.go.jp</a>&=
gt;, SeongHan Shin &lt;<a href=3D"mailto:seonghan.shin@aist.go.jp" target=
=3D"_blank">seonghan.shin@aist.go.jp</a>&gt;<br>

<br><br><br>
A new version of I-D, draft-shin-tls-augpake-01.txt<br>
has been successfully submitted by SeongHan Shin and posted to the<br>
IETF repository.<br>
<br>
Filename: =A0 =A0 =A0 =A0draft-shin-tls-augpake<br>
Revision: =A0 =A0 =A0 =A001<br>
Title: =A0 =A0 =A0 =A0 =A0 Augmented Password-Authenticated Key Exchange fo=
r Transport Layer Security (TLS)<br>
Creation date: =A0 2013-09-04<br>
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>
Number of pages: 19<br>
URL: =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.ietf.org/internet-drafts=
/draft-shin-tls-augpake-01.txt" target=3D"_blank">http://www.ietf.org/inter=
net-drafts/draft-shin-tls-augpake-01.txt</a><br>
Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/doc/draft=
-shin-tls-augpake" target=3D"_blank">http://datatracker.ietf.org/doc/draft-=
shin-tls-augpake</a><br>
Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/draft-shin-t=
ls-augpake-01" target=3D"_blank">http://tools.ietf.org/html/draft-shin-tls-=
augpake-01</a><br>
Diff: =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://www.ietf.org/rfcdiff?url2=3D=
draft-shin-tls-augpake-01" target=3D"_blank">http://www.ietf.org/rfcdiff?ur=
l2=3Ddraft-shin-tls-augpake-01</a><br>
<br>
Abstract:<br>
=A0 =A0This document describes an efficient augmented password-authenticate=
d<br>
=A0 =A0key exchange (AugPAKE) protocol where a user remembers a low-entropy=
<br>
=A0 =A0password and its verifier is registered in the intended server. =A0I=
n<br>
=A0 =A0general, the user password is chosen from a small set of dictionary<=
br>
=A0 =A0whose space is within the off-line dictionary attacks. =A0The AugPAK=
E<br>
=A0 =A0protocol described here is secure against passive attacks, active<br=
>
=A0 =A0attacks and off-line dictionary attacks (on the obtained messages<br=
>
=A0 =A0with passive/active attacks), and also provides resistance to server=
<br>
=A0 =A0compromise (in the context of augmented PAKE security). =A0Based on =
the<br>
=A0 =A0AugPAKE protocol, this document also specifies a new password-only<b=
r>
=A0 =A0authentication handshake for Transport Layer Security (TLS) protocol=
.<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
</div><br><br clear=3D"all"><br></div></div><span class=3D"HOEnZb"><font co=
lor=3D"#888888">-- <br><div style=3D"MARGIN:0mm 0mm 0pt"><span style=3D"FON=
T-FAMILY:&#39;MS UI Gothic&#39;;FONT-SIZE:10pt" lang=3D"EN-US">------------=
------------------------------------------------------<br>
SeongHan Shin<br>
</span><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;FONT-SIZE:10pt" la=
ng=3D"EN-US">Research Institute for Secure Systems (RISEC),<br>National Ins=
titute of Advanced Industrial Science and Technology (AIST),<br>Central 2, =
1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>

Tel : +81-29-861-2670/5284<br>Fax : <a href=3D"tel:%2B81-29-861-5285" value=
=3D"+81298615285" target=3D"_blank">+81-29-861-5285</a><br>E-mail : <a href=
=3D"mailto:seonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000=
ff">seonghan.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>

</font></span></div></div></div></div></div></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"MARGIN:0m=
m 0mm 0pt"><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;FONT-SIZE:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>
SeongHan Shin<br></span><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;F=
ONT-SIZE:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div></div></div></div></div></div></div>

--001a11c3bb34b629f704ea871bd0--

From seonghan.shin@aist.go.jp  Wed Nov  6 12:15:14 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 8951321E8175 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 enIwXKiwcdQN for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:15:10 -0800 (PST)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 771A521E808A for <tls@ietf.org>; Wed,  6 Nov 2013 12:15:09 -0800 (PST)
Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUnqjTeWaoeFFfgYy+LYbTBzJ0zVlgcZk@postini.com; Wed, 06 Nov 2013 12:15:09 PST
Received: by mail-la0-f51.google.com with SMTP id ep20so8757lab.10 for <tls@ietf.org>; Wed, 06 Nov 2013 12:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=0YyVjFMv8NSXmD8OMFTIcZYJm7G/uFNR6jgNWEm9C+Y=; b=Q5kJg2QbQv25s7kT6BfeC5BrNdlWpc6OqGbLVF3um0Ov3pCWAHl+NR/clwZmgnvrLt Pzbx5BhJDceiyLbEy0sQE9cKywvkOyBL3oOASmP9Q+4+/TisYZgjiWsAQBbvTZjRw18z ndSuvueI62myvXQoeN7U3mwJzvEqZprFGtm2w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=0YyVjFMv8NSXmD8OMFTIcZYJm7G/uFNR6jgNWEm9C+Y=; b=TO4d5KwJu89evEbErb3p6EVQsRspQUlHcGhT14qo0DVKUS/o9CNPmFhO7wy6WdCAPZ 1d5hgojgS7gNIk1XVWBOCn2PotqNamVXqfPY1v1O1EIOGyePUWogA51zTfDTXZdvZ+PL Ld6swmJjmD2xX1Ewa3WbEYJbAQ/qfZG2BWk7fMe4vC1I49wRuGRV6HZewqKivl/K7fKQ u1AID75snvZFpkzg0clQcyt+T+OpA79b2flAZgdyFBrR5eMELCdx2Qosw7G6RvIIC2Je Z/JqE01dnhpZmGxTr/jDqeuGD10x/yyAZ5HzoWiXML/JuVznQFd90tB5QuK3E5QVqiqP 0eMA==
X-Gm-Message-State: ALoCoQm0znaLqxjA/AihBO8Y+9n38Zc8fBdRb0UNtg+ZwJ17WSgQJe58GCMijdewz9fmjmiqj3cWnuOkEMMqKgFawmVgkxx9UmUKAno4cyiG1mftmXB8F/MZRQytCZqxusSiNDaS4So+WL8soezLfe6JgGkRzZriQg==
X-Received: by 10.152.9.198 with SMTP id c6mr3322879lab.36.1383768907834; Wed, 06 Nov 2013 12:15:07 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.9.198 with SMTP id c6mr3322873lab.36.1383768907706; Wed, 06 Nov 2013 12:15:07 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Wed, 6 Nov 2013 12:15:07 -0800 (PST)
Date: Thu, 7 Nov 2013 05:15:07 +0900
Message-ID: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a1132f83e32053004ea87ced0
Subject: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 20:15:14 -0000

--001a1132f83e32053004ea87ced0
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

The TLS WG is about to issue a LC for tls-pwd.
http://tools.ietf.org/html/draft-ietf-tls-pwd-01

Is there any advantages of tls-pwd over tls-srp?
http://www.ietf.org/mail-archive/web/tls/current/msg09693.html

If anything I've missed, let me know.

Sincerely,
Shin

-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a1132f83e32053004ea87ced0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi all,<br><br></div>The TLS WG is about to issu=
e a LC for tls-pwd.<br><a href=3D"http://tools.ietf.org/html/draft-ietf-tls=
-pwd-01">http://tools.ietf.org/html/draft-ietf-tls-pwd-01</a><br><br></div>=
<div>
Is there any advantages of tls-pwd over tls-srp?<br><a href=3D"http://www.i=
etf.org/mail-archive/web/tls/current/msg09693.html">http://www.ietf.org/mai=
l-archive/web/tls/current/msg09693.html</a><br><br></div><div>If anything I=
&#39;ve missed, let me know.<br>
<br></div><div>Sincerely,<br></div><div>Shin<br></div><div><div><div><br>--=
 <br><div style=3D"margin:0mm 0mm 0pt"><span style=3D"font-family:&#39;MS U=
I Gothic&#39;;font-size:10pt" lang=3D"EN-US">------------------------------=
------------------------------------<br>
SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div></div>

--001a1132f83e32053004ea87ced0--

From nico@cryptonector.com  Wed Nov  6 12:19:04 2013
Return-Path: <nico@cryptonector.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 E387E11E80E2 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level: 
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599]
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 cNZKlUtZjjkX for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:18:59 -0800 (PST)
Received: from homiemail-a66.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA111E80D9 for <tls@ietf.org>; Wed,  6 Nov 2013 12:18:59 -0800 (PST)
Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id EBA2335007F; Wed,  6 Nov 2013 12:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=IepsPuvCzN/5XJ /2pJxfXZ02VBM=; b=x9pmzZ7UzfTK3FdwtvWQ52LtFk3SIYyc3Y4wpUzNG4HX+c 7m5aFjfpvVvjdkAXcTLYNC9ocKDLEiuUtycbEVsy7kUC6iqrKSn2e6Tn9DoY4XDy vKBzbjkN7/ErilcRaE1fBzdVV/0xecvAnIb1KOu4Sd1E3GMF2sDDCedQc2vTs=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id 8846A350079;  Wed,  6 Nov 2013 12:18:58 -0800 (PST)
Date: Wed, 6 Nov 2013 14:18:56 -0600
From: Nico Williams <nico@cryptonector.com>
To: Dr Stephen Henson <lists@drh-consultancy.co.uk>
Message-ID: <20131106201853.GP18713@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com> <527A86A7.5080700@drh-consultancy.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <527A86A7.5080700@drh-consultancy.co.uk>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: tls@ietf.org
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 20:19:05 -0000

On Wed, Nov 06, 2013 at 06:12:55PM +0000, Dr Stephen Henson wrote:
> On 06/11/2013 18:03, Adam Langley wrote:
> > On Wed, Nov 6, 2013 at 1:00 PM, Xiaoyong Wu <X.Wu@f5.com> wrote:
> >> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.
> > 
> > ^^^ Holy crap. I wish I had known that sooner. That might solve the issue.
> > 
> 
> Just did a quick test with OpenSSL on a couple of known "hang" machines. Seems
> to work.

I'm not adding much, but: that sound we hear is the collective sigh of
relief of the TLS WG list!

This will also help with TLSv1.3, assuming we get there.

From y.oiwa@aist.go.jp  Wed Nov  6 12:50:50 2013
Return-Path: <y.oiwa@aist.go.jp>
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 6A0E511E80E2 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.483
X-Spam-Level: 
X-Spam-Status: No, score=-5.483 tagged_above=-999 required=5 tests=[AWL=0.494,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 9DJhsKLxaRFD for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:50:46 -0800 (PST)
Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 807BB11E8119 for <tls@ietf.org>; Wed,  6 Nov 2013 12:50:42 -0800 (PST)
Received: from mail-ve0-f169.google.com ([209.85.128.169]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUnqropb00b4eGw+AePrTm7KTsLzPyfr0@postini.com; Wed, 06 Nov 2013 12:50:42 PST
Received: by mail-ve0-f169.google.com with SMTP id jy13so41517veb.0 for <tls@ietf.org>; Wed, 06 Nov 2013 12:50:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lWp2l2oW4PDruVI+uOECfXVK8/HJHy/BVU2f8wa4o4s=; b=fuoQRMp65aTICSjsluzZq5OCL7rL3Av9mk4n/v83pb+jkiiWSxLa2ywHTtwD7MI8WU HZQlDQF0irRUm3tqlOCrUvCf3r/8gAPczP/u1dXx0UUu0Km9Z+xVIVgfAYD1GrTJnPf5 CallEnORdmFAgwFtf4TVtIECC6iypKgqCsl4o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lWp2l2oW4PDruVI+uOECfXVK8/HJHy/BVU2f8wa4o4s=; b=PrUj+sLQce7JYoKdsQmyY9FH+hjiFBydq+QPebMharaQqBguMxf//vEC/RUs5NMNTW q0WYqV0OcTFdnNlfxLnN9CSlespa22O9lzrYchkqv3v4ERX3o6vw8642jXGCVZlhsger bxKuQJsoNsxqx4gbHDSuJKDrKnEqQbghOZvjtrqgwdTgryh8LbX6VIHb0Aw1uOxuX9h9 aAoDsIQqVV/gHQqlNkYLkD7lVxGniiBNSi4RGEiGXNeH42wBkCjvOrxo6bRvWfqlcbcP cNtH1Q26q2pLq4lnYk6JhhkVs7p6fH7IIf8rioJkuzJZ+9CvLjScHEB0Zky5jlb0v7Gb pb2A==
X-Gm-Message-State: ALoCoQmxDjHqVKoCjDGUKotZM/3jwJO3lW++dfILAgCuwBaUF43nOQEiqFA3jno35Sn/n7ttufkC3vkqrlkHUItrXY7PVIBIWE8JbpvdE5kQy5Z7y804A+8dFv8/LjmyaJ2/AUB/Xp/ffojYjorADw4HxiiBC+7KaQ==
X-Received: by 10.58.108.196 with SMTP id hm4mr3922462veb.28.1383771041466; Wed, 06 Nov 2013 12:50:41 -0800 (PST)
X-Received: by 10.58.108.196 with SMTP id hm4mr3922457veb.28.1383771041315; Wed, 06 Nov 2013 12:50:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.100.145 with HTTP; Wed, 6 Nov 2013 12:50:21 -0800 (PST)
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Thu, 7 Nov 2013 05:50:21 +0900
Message-ID: <CAMeZVwuKKsx+8xphBqxqHFfShmPZXAP_ZbpWeqJ4+LwGpRLHkA@mail.gmail.com>
To: Xiaoyong Wu <X.Wu@f5.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 20:50:50 -0000

> For SSL records, the SSLv3 and TLS ClientHello headers are as follows:
> | 22 | version major | version minor | length high bits | length low bits |
> If this is interpreted as an SSLv2 header, it will be considered as a 3 byte header:
> | v2 header b0 | v2 header b1 | v2 header b2 | message type |

Hmm, if the message is 256-byte TLS 1.2 Handshake message,
the first five bytes will be 0x 22.03.03.01.00.
In SSLv2 context, it means a beginning of a handshake message
containing 0x2203 (8707) bytes with 0x03 (3) bytes of padding.

The V2-aware servers are just waiting for 8000+ more
bytes to arrive, describing why they seems to be silence...


2013/11/7 Xiaoyong Wu <X.Wu@f5.com>:
> It is a little bit more calculation than that and related to some historic reasons, aka SSLv2.
>
> For SSL records, the SSLv3 and TLS ClientHello headers are as follows:
>
> | 22 | version major | version minor | length high bits | length low bits |
>
> If this is interpreted as an SSLv2 header, it will be considered as a 3 byte header:
> | v2 header b0 | v2 header b1 | v2 header b2 | message type |
>
> The value for Client Hello message type is SSLV2_MT_CLIENTHELLO which is 1.
> When there is an SSLv3/TLS client-hello of length 256 - 511 bytes, this is ambiguous as "message type" is 1 or it is the "length high bits" to be 1.
>
> Out implementation before the patch was to prefer SSLv2 and thus the issue.
>
> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.
>
> -Xiaoyong
>
>> -----Original Message-----
>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter
>> Gutmann
>> Sent: Tuesday, November 05, 2013 10:53 PM
>> To: <tls@ietf.org>
>> Subject: Re: [TLS] ALPN concerns
>>
>> Brian Smith <brian@briansmith.org> writes:
>>
>> >I am very concerned about the issues that they've run into where many
>> >web servers are failing to handshake when the ClientHello message is
>> >larger than
>> >255 bytes.
>>
>> I'm curious as to how something like this could come about, is anyone familiar
>> with the code base for something that does this?  Is there actually code out
>> there that explicitly checks:
>>
>>   if( sizeof( client_handshake ) > 255 )
>>     return( -1 );
>>
>> and if so, why?
>>
>> Peter.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

From Andrei.Popov@microsoft.com  Wed Nov  6 12:51:26 2013
Return-Path: <Andrei.Popov@microsoft.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 45C2011E8101 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:51:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.71
X-Spam-Level: 
X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-3.111,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ahhEZMvGUk7R for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:51:22 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id C171721E8193 for <tls@ietf.org>; Wed,  6 Nov 2013 12:51:21 -0800 (PST)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 6 Nov 2013 20:51:20 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.243]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.5]) with mapi id 15.00.0785.001; Wed, 6 Nov 2013 20:51:20 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Yoav Nir <ynir@checkpoint.com>, "tls@ietf.org list" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: AQHO2nVrEJNfUuzvrkqBLee9/27ncJoXaOmAgAADJoCAAUFqQA==
Date: Wed, 6 Nov 2013 20:51:19 +0000
Message-ID: <4ff5300276984a0f883475b05b621f76@BL2PR03MB194.namprd03.prod.outlook.com>
References: <CAFewVt7-+e-e82LA3iPWOuoudRqCCk23uyf0w5+aXSFsAv64GA@mail.gmail.com> <CABkgnnXgUo_g-w=kefQUnFWLtcfdTByCWtSaxJHvLx-gtzZP_A@mail.gmail.com> <C98EE823-C8BD-4ED3-894A-5F562BE329EE@checkpoint.com>
In-Reply-To: <C98EE823-C8BD-4ED3-894A-5F562BE329EE@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(47976001)(50986001)(33646001)(76576001)(4396001)(76796001)(49866001)(54356001)(31966008)(15975445006)(56816003)(79102001)(85306002)(74316001)(74502001)(76786001)(19580405001)(74876001)(74662001)(83322001)(87266001)(76482001)(47736001)(19580395003)(74706001)(77096001)(81686001)(47446002)(81816001)(53806001)(51856001)(83072001)(74366001)(81542001)(77982001)(80976001)(56776001)(54316002)(69226001)(46102001)(80022001)(65816001)(59766001)(81342001)(63696002)(2656002)(87936001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB194; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 20:51:26 -0000

ALPN support in IE11 does not usually trigger the issue with unpatched F5 d=
evices. The combination of cipher suites, TLS extensions, and ALPN protocol=
 IDs that IE11 advertises is such that the ClientHello is typically shorter=
 than 256 bytes. Longer server names passed via SNI can of course still pus=
h IE's ClientHello over the unpatched F5 device's limit.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Yoav =
Nir
Sent: Tuesday, November 5, 2013 5:36 PM
To: tls@ietf.org list
Subject: Re: [TLS] ALPN concerns

One other thing: Microsoft has released IE 11 that has ALPN. So if ALPN mak=
es TLS fail, then those 2.3% of websites are now inaccessible by Internet E=
xplorer. That is one big reason to upgrade their BigIP box.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From lists@drh-consultancy.co.uk  Wed Nov  6 12:56:27 2013
Return-Path: <lists@drh-consultancy.co.uk>
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 D646011E8119 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Rz-caxXFmz3h for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 12:56:20 -0800 (PST)
Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by ietfa.amsl.com (Postfix) with ESMTP id E33C711E8101 for <tls@ietf.org>; Wed,  6 Nov 2013 12:56:19 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:48519 helo=[192.168.7.9]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10465) with esmtpa (authdaemon_plain:drh) id 1VeA99-0005tF-Fe for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Wed, 06 Nov 2013 20:56:16 +0000
Message-ID: <527AACEC.60109@drh-consultancy.co.uk>
Date: Wed, 06 Nov 2013 20:56:12 +0000
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>	<E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>	<CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com> <527A86A7.5080700@drh-consultancy.co.uk>
In-Reply-To: <527A86A7.5080700@drh-consultancy.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 20:56:27 -0000

On 06/11/2013 18:12, Dr Stephen Henson wrote:
> On 06/11/2013 18:03, Adam Langley wrote:
>> On Wed, Nov 6, 2013 at 1:00 PM, Xiaoyong Wu <X.Wu@f5.com> wrote:
>>> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.
>>
>> ^^^ Holy crap. I wish I had known that sooner. That might solve the issue.
>>
> 
> Just did a quick test with OpenSSL on a couple of known "hang" machines. Seems
> to work.
> 

I added this to the OpenSSL master branch in case anyone wants to test it.

If enabled it uses a dummy extension[1] to pad the ClientHello with enough
zeroes to make it long enough.

Steve.
1. Provisional name Workaround TLS Filler aka WTF ;-)
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From agl@google.com  Wed Nov  6 13:01:06 2013
Return-Path: <agl@google.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 1448511E8119 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OFPjFGyUWdVD for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:01:05 -0800 (PST)
Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 82C2711E80E2 for <tls@ietf.org>; Wed,  6 Nov 2013 13:01:05 -0800 (PST)
Received: by mail-vb0-f41.google.com with SMTP id w8so43783vbj.28 for <tls@ietf.org>; Wed, 06 Nov 2013 13:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9RRlowEYzN1Drp26MaprAqqmIymiiUpD3kKy3gKJ7ZA=; b=PAxG2cVUaZhy4MewIZSr494LHm4SXa6ofBOiuCBJEwkM/rPe5t/Fm2tb5GGi6vvA4y i02zT92wsGo85r6wbwYqb1q8UBJjkJhSnuN3KftqI/WDKGvaGCPojjyjza7sG/OjxSqJ NOOiOaHp27keAWv7sx2Bm8OfEQAX21Xvw5i2dm0BZUHktU+YRuovZOHZOAwOUP/wHxXC x6cSZLa+ty6QFqQXQx1H6MtE38Xm7Aqaf1NmI1HNr2lSjDC2SdyEGuw2+/qbkYPuXr3d d9AAvXSe9Shcz+C2l4OOZAauYuUsJ0VotZrIV6Eg0JrVRye5IdCJM6nICwSrFt68V6nP J+jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9RRlowEYzN1Drp26MaprAqqmIymiiUpD3kKy3gKJ7ZA=; b=IjWzydk+Tx+G+MclqQkQ3XTmR8NYnYI7FWBhHWP9QqxwKLBDAa737vP/Ica5QZmw+2 l8KQoZn4t2MCJ9nJXzVpDOf3bgq1iXn+mhD3CDCv0fqYLAVUdjKTlxn/ICnypYBF8rze w3b4Ei3bJQxwwKqen2SHqb9CibYc40xpoVsP2ELAqtUhuaPR50G6dFKSv6oC8Xxny3Fx q1fVItXrHc3W79e9zCIkiawdiHR8cNLR2QGsvz11ipOu62mdeS1WhuKBjaYRZBMLNQ8L cTFPJwzh14RDPIH16/xbdOvrPNIeFQv9HwM0Cibt6Dvzl1OrTUu54MXinDaBgzN8Zujt 1tsw==
X-Gm-Message-State: ALoCoQnAd6DfONi33/kO++eDKHuCS+JxFVhDKWV8cvRsxPIZ+UIrouPe3EIsqiZHXjKz5E3ndNyXJwTFJ9beGRj7/flalSLcXDRVs0/YONdZrLZ9npj10byGNel419PXtvjZLwo/BOtgXvC+Zyen2fC0n/Wb2+celopI6Wd5TK9spxD3ll6LoWHclUTwxDOf7QQbK3aNbIh/
X-Received: by 10.221.6.195 with SMTP id ol3mr173078vcb.34.1383771664908; Wed, 06 Nov 2013 13:01:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 6 Nov 2013 13:00:44 -0800 (PST)
In-Reply-To: <527AACEC.60109@drh-consultancy.co.uk>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com> <527A86A7.5080700@drh-consultancy.co.uk> <527AACEC.60109@drh-consultancy.co.uk>
From: Adam Langley <agl@google.com>
Date: Wed, 6 Nov 2013 16:00:44 -0500
Message-ID: <CAL9PXLxEh50MTaixVrmm2-1KXUkfoiCz+r=jTqvUwQ9D9_Bwag@mail.gmail.com>
To: Dr Stephen Henson <lists@drh-consultancy.co.uk>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 21:01:06 -0000

On Wed, Nov 6, 2013 at 3:56 PM, Dr Stephen Henson
<lists@drh-consultancy.co.uk> wrote:
> I added this to the OpenSSL master branch in case anyone wants to test it.
>
> If enabled it uses a dummy extension[1] to pad the ClientHello with enough
> zeroes to make it long enough.

Likewise for Chrome: https://codereview.chromium.org/62103003


Cheers

AGL

From dharkins@lounge.org  Wed Nov  6 13:02:12 2013
Return-Path: <dharkins@lounge.org>
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 D04B011E8101 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.079
X-Spam-Level: 
X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 IZephne72BGP for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:02:08 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id B0F0111E80E2 for <tls@ietf.org>; Wed,  6 Nov 2013 13:02:08 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3CD47A888120; Wed,  6 Nov 2013 13:02:08 -0800 (PST)
Received: from 31.133.163.31 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Nov 2013 13:02:08 -0800 (PST)
Message-ID: <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net>
In-Reply-To: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com>
Date: Wed, 6 Nov 2013 13:02:08 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "SeongHan Shin" <seonghan.shin@aist.go.jp>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 21:02:12 -0000

  Hi Shin,

On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:
> Hi all,
>
> The TLS WG is about to issue a LC for tls-pwd.
> http://tools.ietf.org/html/draft-ietf-tls-pwd-01
>
> Is there any advantages of tls-pwd over tls-srp?

  TLS-srp binds the password to a particular finite cyclic group
and the user must use that group for the life of the password.
TLS-pwd does not do this. With TLS-pwd you use the existing
TLS mechanisms to select any of the existing FFC or ECC groups
to use (and when new groups get defined they will automatically
work). By divorcing the key generation parameters from the
password it also allows for more consistent cipher suite plus
group establishment-- e.g. use the brainpoolP256 group with
SHA256 and AES-128-- to establish a certain security level
for the connection.

  regards,

  Dan.




From mnot@mnot.net  Wed Nov  6 13:23:54 2013
Return-Path: <mnot@mnot.net>
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 9E81711E8143 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.492
X-Spam-Level: 
X-Spam-Status: No, score=-104.492 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 2VJ1mH1mkOg7 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:23:50 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 152EB11E8140 for <tls@ietf.org>; Wed,  6 Nov 2013 13:23:50 -0800 (PST)
Received: from dhcp-b71c.meeting.ietf.org (unknown [31.133.183.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5B1E322E253; Wed,  6 Nov 2013 16:23:29 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
Date: Wed, 6 Nov 2013 13:23:27 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A14A6849-71C9-42ED-98D2-E547DE264E7D@mnot.net>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
To: Xiaoyong Wu <X.Wu@F5.com>
X-Mailer: Apple Mail (2.1816)
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
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, 06 Nov 2013 21:23:54 -0000

For whatever it=92s worth =97 thank you (personally and F5) for being =
open about it. You may have just saved us a LOT of pain / gnashing of =
teeth.

Cheers,


On 6 Nov 2013, at 10:00 am, Xiaoyong Wu <X.Wu@F5.com> wrote:

> It is a little bit more calculation than that and related to some =
historic reasons, aka SSLv2.
>=20
> For SSL records, the SSLv3 and TLS ClientHello headers are as follows:
>=20
> | 22 | version major | version minor | length high bits | length low =
bits |
>=20
> If this is interpreted as an SSLv2 header, it will be considered as a =
3 byte header:
> | v2 header b0 | v2 header b1 | v2 header b2 | message type |=20
>=20
> The value for Client Hello message type is SSLV2_MT_CLIENTHELLO which =
is 1.
> When there is an SSLv3/TLS client-hello of length 256 - 511 bytes, =
this is ambiguous as "message type" is 1 or it is the "length high bits" =
to be 1.
>=20
> Out implementation before the patch was to prefer SSLv2 and thus the =
issue.
>=20
> As I am explaining this in detail, I would say that another work =
around on this would be making a client hello that exceeds 512 in =
length.
>=20
> -Xiaoyong
>=20
>> -----Original Message-----
>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of =
Peter
>> Gutmann
>> Sent: Tuesday, November 05, 2013 10:53 PM
>> To: <tls@ietf.org>
>> Subject: Re: [TLS] ALPN concerns
>>=20
>> Brian Smith <brian@briansmith.org> writes:
>>=20
>>> I am very concerned about the issues that they've run into where =
many
>>> web servers are failing to handshake when the ClientHello message is
>>> larger than
>>> 255 bytes.
>>=20
>> I'm curious as to how something like this could come about, is anyone =
familiar
>> with the code base for something that does this?  Is there actually =
code out
>> there that explicitly checks:
>>=20
>>  if( sizeof( client_handshake ) > 255 )
>>    return( -1 );
>>=20
>> and if so, why?
>>=20
>> Peter.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
Mark Nottingham   http://www.mnot.net/




From seonghan.shin@aist.go.jp  Wed Nov  6 13:24:06 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 E9D0911E8184 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 ChpTBlmsAEbC for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:24:02 -0800 (PST)
Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 078D211E815A for <tls@ietf.org>; Wed,  6 Nov 2013 13:24:02 -0800 (PST)
Received: from mail-la0-f46.google.com ([209.85.215.46]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUnqzcaCIi0HJtG6zKVEbcte6ItW03Fuc@postini.com; Wed, 06 Nov 2013 13:24:02 PST
Received: by mail-la0-f46.google.com with SMTP id el20so72028lab.5 for <tls@ietf.org>; Wed, 06 Nov 2013 13:24:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ayUunYqsQjnqoy41uMMJmCQEyURQhh020OHeuLxV46I=; b=OZPOFj3Ooj4Jv44/+ci7U7GzwSVlsnei3/ND4zuoDEdAdRl/7udnJ3rybyTN7qAUZZ IQbpSbYmLMI6iOURBmIC7uHYi4jhnzgb6HNToekum/aJtktmAKBgEe369p608tpWhgVH 9BQ1xZO+Z3X7Uwb1GSlI+cPcB5y7qIyJ97ueA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ayUunYqsQjnqoy41uMMJmCQEyURQhh020OHeuLxV46I=; b=MT/XpX7XIr1jcq6ZTbf8beWRBFOz/WpAxS1nV4oTSaNaFXWDh9tQBMqtszqLTAmDww QiSZ/BLVvIynrWE3ZBG9Rg3J8d9ROUAFTNt+B0tVvsE1l7BLzUwThLWI/OWniblzbpuv oIJmFXY/ZdpeNfoiZVkmkS7MxNaPMc9qboYBa5efuOyMFNWbSxmspC3UjrohOMlo2cbG HnbzEVuYgB4D4RKcZAriMWJi0OEWWYilkrNfh00kFhBM6RYZko401Hg2RRHTfWxna8ja ElQhvGmUU0BuVrb5eXGv5Q7+Kaedf4ZgMznzUXGcKCgm0ABpNsNfTyCLUZYjGXr4Xd+o BFtQ==
X-Gm-Message-State: ALoCoQndO0V6aSJmyFHtgY8BIPuf6IX26wIeohlRzr4MFurPBSoHzayL6V+j0BF+IqZYHjhuDvOWi1IRN8udveZgwFWBpYKU/KGpqj5H44K1MdbPZ+ySwUla80Q4Hwe4LE+mejcN5wlKCvOsU1qXaH+Vl3XGEWf0Fw==
X-Received: by 10.152.28.9 with SMTP id x9mr92241lag.27.1383773040220; Wed, 06 Nov 2013 13:24:00 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.28.9 with SMTP id x9mr92239lag.27.1383773040071; Wed, 06 Nov 2013 13:24:00 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Wed, 6 Nov 2013 13:24:00 -0800 (PST)
In-Reply-To: <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net>
Date: Thu, 7 Nov 2013 06:24:00 +0900
Message-ID: <CAEKgtqm5pKf+Ky2jazGpDan02yjdtAOhiwfCyAiT_uEHHhEnuA@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: tls@ietf.org, Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=089e0160b8fe80e71404ea88c408
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 21:24:07 -0000

--089e0160b8fe80e71404ea88c408
Content-Type: text/plain; charset=ISO-8859-1

Hi Dan,

Here comes the next question:
Is there any advantages of tls-pwd over tls-augpake and SPEKE?
https://tools.ietf.org/html/draft-shin-tls-augpake-01
http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29

Regards,
Shin


On Thu, Nov 7, 2013 at 6:02 AM, Dan Harkins <dharkins@lounge.org> wrote:

>
>   Hi Shin,
>
> On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:
> > Hi all,
> >
> > The TLS WG is about to issue a LC for tls-pwd.
> > http://tools.ietf.org/html/draft-ietf-tls-pwd-01
> >
> > Is there any advantages of tls-pwd over tls-srp?
>
>   TLS-srp binds the password to a particular finite cyclic group
> and the user must use that group for the life of the password.
> TLS-pwd does not do this. With TLS-pwd you use the existing
> TLS mechanisms to select any of the existing FFC or ECC groups
> to use (and when new groups get defined they will automatically
> work). By divorcing the key generation parameters from the
> password it also allows for more consistent cipher suite plus
> group establishment-- e.g. use the brainpoolP256 group with
> SHA256 and AES-128-- to establish a certain security level
> for the connection.
>
>   regards,
>
>   Dan.
>
>
>
>


-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--089e0160b8fe80e71404ea88c408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi Dan,<br><br></div>Here comes the next questio=
n:<br>Is there any advantages of tls-pwd over tls-augpake and SPEKE?<br><a =
href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01">https://tool=
s.ietf.org/html/draft-shin-tls-augpake-01</a><br>
<a href=3D"http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29">http://en=
.wikipedia.org/wiki/SPEKE_%28cryptography%29</a><br><br></div>Regards,<br>S=
hin<br><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Thu, Nov 7, 2013 at 6:02 AM, Dan Harkins <span dir=3D"ltr">&lt;<a href=3D=
"mailto:dharkins@lounge.org" target=3D"_blank">dharkins@lounge.org</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
=A0 Hi Shin,<br>
<div class=3D"im"><br>
On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; The TLS WG is about to issue a LC for tls-pwd.<br>
&gt; <a href=3D"http://tools.ietf.org/html/draft-ietf-tls-pwd-01" target=3D=
"_blank">http://tools.ietf.org/html/draft-ietf-tls-pwd-01</a><br>
&gt;<br>
&gt; Is there any advantages of tls-pwd over tls-srp?<br>
<br>
</div>=A0 TLS-srp binds the password to a particular finite cyclic group<br=
>
and the user must use that group for the life of the password.<br>
TLS-pwd does not do this. With TLS-pwd you use the existing<br>
TLS mechanisms to select any of the existing FFC or ECC groups<br>
to use (and when new groups get defined they will automatically<br>
work). By divorcing the key generation parameters from the<br>
password it also allows for more consistent cipher suite plus<br>
group establishment-- e.g. use the brainpoolP256 group with<br>
SHA256 and AES-128-- to establish a certain security level<br>
for the connection.<br>
<br>
=A0 regards,<br>
<br>
=A0 Dan.<br>
<br>
<br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margin:0m=
m 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>
SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div>

--089e0160b8fe80e71404ea88c408--

From fabrice.gautier@gmail.com  Wed Nov  6 13:45:24 2013
Return-Path: <fabrice.gautier@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 3D60521E81A2 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:45:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 ViB1TLFQJwIB for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 13:45:23 -0800 (PST)
Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB2D11E816F for <tls@ietf.org>; Wed,  6 Nov 2013 13:43:41 -0800 (PST)
Received: by mail-pb0-f48.google.com with SMTP id mc8so105985pbc.21 for <tls@ietf.org>; Wed, 06 Nov 2013 13:43:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+1S8uvVO90ZzxU/dHUkMy67Jv/eA3fRFFWT87RUzYRc=; b=xk122Bvu6R+RUHEZ1PBNlUA05HblptbGeK2PaNntMBB33w+kOdaE6aeZenlEQ+NmTw fum+K7lu8oQQv0AgqPSWx7YRZF1kESO35HzDmT4LnGhhEobwQ6ZcLsmIheIwc09qI93U jtp0vTu2Q1zNhLxb9wE1vL07S59KdQH8sIL5KkxYzwGCyG1i79kq5G1Bt+eL0TKgbrKJ Yn+yNq+taEjMJi9aPMBBdeo9TTaDCjmNmBGv8s4PvyVcFKPq6dkU+4F2zETTRuETGHv8 7ttrv7LKORC0pj9k8JpsrG7jbIJAr6s5NjvuR2dP6EvdUxpiSblO7UJUQ8nIj5d6vnB1 NdyA==
X-Received: by 10.66.65.134 with SMTP id x6mr6056338pas.142.1383774209008; Wed, 06 Nov 2013 13:43:29 -0800 (PST)
Received: from [17.244.27.134] ([17.244.27.134]) by mx.google.com with ESMTPSA id ye1sm892251pab.19.2013.11.06.13.43.27 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 13:43:27 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (11B504)
In-Reply-To: <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net>
Date: Wed, 6 Nov 2013 13:43:36 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B54E2EF-0E1C-4E1E-B5FD-D98236A53640@gmail.com>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net>
To: Dan Harkins <dharkins@lounge.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 21:45:24 -0000

> On Nov 6, 2013, at 13:02, "Dan Harkins" <dharkins@lounge.org> wrote:
>=20
>=20
>  Hi Shin,
>=20
>> On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:
>> Hi all,
>>=20
>> The TLS WG is about to issue a LC for tls-pwd.
>> http://tools.ietf.org/html/draft-ietf-tls-pwd-01
>>=20
>> Is there any advantages of tls-pwd over tls-srp?
>=20
>  TLS-srp binds the password to a particular finite cyclic group
> and the user must use that group for the life of the password.

Isn't that required for every protocol that only stores a verifier on the se=
rver, rather than a password equivalent?

My understanding of TLS-PWD is that the server need to store a password equi=
valent (called the "base" in the TLS-PWD drafts), and as such does not have s=
ome of the desirable properties of SRP (or AugPAKE) related to server compro=
mises.

  Fabrice


> TLS-pwd does not do this. With TLS-pwd you use the existing
> TLS mechanisms to select any of the existing FFC or ECC groups
> to use (and when new groups get defined they will automatically
> work). By divorcing the key generation parameters from the
> password it also allows for more consistent cipher suite plus
> group establishment-- e.g. use the brainpoolP256 group with
> SHA256 and AES-128-- to establish a certain security level
> for the connection.
>=20
>  regards,
>=20
>  Dan.
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From dharkins@lounge.org  Wed Nov  6 14:29:50 2013
Return-Path: <dharkins@lounge.org>
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 BE1E721F9E45 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.103
X-Spam-Level: 
X-Spam-Status: No, score=-6.103 tagged_above=-999 required=5 tests=[AWL=0.162,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 wOUN1pXRroJT for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:29:46 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A754721F9DAF for <tls@ietf.org>; Wed,  6 Nov 2013 14:29:46 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4936B10224008; Wed,  6 Nov 2013 14:29:46 -0800 (PST)
Received: from 31.133.163.31 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Nov 2013 14:29:46 -0800 (PST)
Message-ID: <bf5dbb3dcab3910aebd859c1ae231363.squirrel@www.trepanning.net>
In-Reply-To: <3B54E2EF-0E1C-4E1E-B5FD-D98236A53640@gmail.com>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net> <3B54E2EF-0E1C-4E1E-B5FD-D98236A53640@gmail.com>
Date: Wed, 6 Nov 2013 14:29:46 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Fabrice" <fabrice.gautier@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 22:29:50 -0000

On Wed, November 6, 2013 1:43 pm, Fabrice wrote:
>> On Nov 6, 2013, at 13:02, "Dan Harkins" <dharkins@lounge.org> wrote:
>>
>>
>>  Hi Shin,
>>
>>> On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:
>>> Hi all,
>>>
>>> The TLS WG is about to issue a LC for tls-pwd.
>>> http://tools.ietf.org/html/draft-ietf-tls-pwd-01
>>>
>>> Is there any advantages of tls-pwd over tls-srp?
>>
>>  TLS-srp binds the password to a particular finite cyclic group
>> and the user must use that group for the life of the password.
>
> Isn't that required for every protocol that only stores a verifier on the
> server, rather than a password equivalent?
>
> My understanding of TLS-PWD is that the server need to store a password
> equivalent (called the "base" in the TLS-PWD drafts), and as such does not
> have some of the desirable properties of SRP (or AugPAKE) related to
> server compromises.

  Your understanding is correct. There are drawbacks with the "desirable
properties" of both TLS-srp and TLS-pwd. Now you have a choice based on
what you value more.

  Dan.




From dharkins@lounge.org  Wed Nov  6 14:32:30 2013
Return-Path: <dharkins@lounge.org>
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 1061A21F9EB5 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.121
X-Spam-Level: 
X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 oo-seWPGQFPv for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:32:12 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D946C21E808F for <tls@ietf.org>; Wed,  6 Nov 2013 14:32:11 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8A00B10224008; Wed,  6 Nov 2013 14:32:11 -0800 (PST)
Received: from 31.133.163.31 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 6 Nov 2013 14:32:11 -0800 (PST)
Message-ID: <de8e217085c2cc62290e9dad107c84ed.squirrel@www.trepanning.net>
In-Reply-To: <CAEKgtqm5pKf+Ky2jazGpDan02yjdtAOhiwfCyAiT_uEHHhEnuA@mail.gmail.com>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net> <CAEKgtqm5pKf+Ky2jazGpDan02yjdtAOhiwfCyAiT_uEHHhEnuA@mail.gmail.com>
Date: Wed, 6 Nov 2013 14:32:11 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "SeongHan Shin" <seonghan.shin@aist.go.jp>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 22:32:30 -0000

  Hi Shin,

On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:
> Hi Dan,
>
> Here comes the next question:
> Is there any advantages of tls-pwd over tls-augpake and SPEKE?
> https://tools.ietf.org/html/draft-shin-tls-augpake-01
> http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29

  Mrs. Harkins didn't raise a moron. I really do not want to
repeat the debacle that occurred on the IPsec mailing list
regarding PAKE schemes.

  If you would like to rehash all those exchanges I suggest
you go look at the archives.

  regards,

  Dan.




From seonghan.shin@aist.go.jp  Wed Nov  6 14:36:41 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 C969B21E80A6 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 x328gFM0VE8J for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:36:37 -0800 (PST)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id C21DF21E808A for <tls@ietf.org>; Wed,  6 Nov 2013 14:36:36 -0800 (PST)
Received: from mail-lb0-f176.google.com ([209.85.217.176]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUnrEdJ0E+r13gcyGF620HD8Aahbk3icx@postini.com; Wed, 06 Nov 2013 14:36:36 PST
Received: by mail-lb0-f176.google.com with SMTP id z5so263328lbh.21 for <tls@ietf.org>; Wed, 06 Nov 2013 14:36:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wne6zWxmBGwgLpoUTGVFr++VZeUO/qiFgmciXBqUtYU=; b=Po9umfFg7XX+t1P6DI2hgXxIZpOUXirXhHhOg2qN1wrfXb45qLWcevCzRQCZ85cwDN NLjD2N4SRZgmmfsg5kqZGZOjjbpbhzWyZUCSGWd+OBWpugBitdGMjQf3Ht+d8mOnxa+U xdYteTzKygvEapwIbaeUHoYWLZznVjaTtTuuI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Wne6zWxmBGwgLpoUTGVFr++VZeUO/qiFgmciXBqUtYU=; b=PYBkGCqBsLz45v0m/bhahNcaS8faBNkmnjpBxqpXN9YnGvm2RGBMN7ZhFZBj5yRQHK KUZmNrCh/8p81GmCBCCG2v4cKCFI5BFdm8BpFxIJzhlwbhB7tfUEadxcedPHSUkh94yc bzFJhhjw5ozTx6CPLhfRKQveHvKf0ZuF5IP1v5NWr/NHbSvvO1n+y0Wf8CjEBamrgn1R a49vzjjLC/SrYSVdCqCSJN1k5BtZAu1ZxyDqFlz0k4jP+quxlzBEPWPKK7OfwKq/IHwj XJA6M2IP1oQeFNd/xz6kVfSiamdypq+FXr9f4GNxGVN5r1LuXJzQGMugrvPT9/yerewu SXvA==
X-Gm-Message-State: ALoCoQmzKjNN5BXzMBHSWrOgJFcgmCewcOffEtfpzdvXWT37eZkLlnpvaelLGdeknnQ1pUJygPuqR4vLp5Jkv1wJ2opBd2A6WwCORHefGJf0lceL5zsD7HapnbYrHqqCFS5ETek5ZA8wPnimq4U0Hjnu/HXZFt3wjg==
X-Received: by 10.112.140.137 with SMTP id rg9mr4100982lbb.19.1383777394751; Wed, 06 Nov 2013 14:36:34 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.140.137 with SMTP id rg9mr4100978lbb.19.1383777394639; Wed, 06 Nov 2013 14:36:34 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Wed, 6 Nov 2013 14:36:34 -0800 (PST)
In-Reply-To: <bf5dbb3dcab3910aebd859c1ae231363.squirrel@www.trepanning.net>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net> <3B54E2EF-0E1C-4E1E-B5FD-D98236A53640@gmail.com> <bf5dbb3dcab3910aebd859c1ae231363.squirrel@www.trepanning.net>
Date: Thu, 7 Nov 2013 07:36:34 +0900
Message-ID: <CAEKgtqnh-nSJO7Z-gUv+uA619jbAsJ_V-6uiM3W2Fzyn9uRzyQ@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2b3460e568f04ea89c875
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 22:36:42 -0000

--001a11c2b3460e568f04ea89c875
Content-Type: text/plain; charset=ISO-8859-1

FYI
AugPAKE can be implemented over any dl/ec groups and it provides resistance
to server compromise (like SRP).

Regards,
Shin


On Thu, Nov 7, 2013 at 7:29 AM, Dan Harkins <dharkins@lounge.org> wrote:

>
> On Wed, November 6, 2013 1:43 pm, Fabrice wrote:
> >> On Nov 6, 2013, at 13:02, "Dan Harkins" <dharkins@lounge.org> wrote:
> >>
> >>
> >>  Hi Shin,
> >>
> >>> On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:
> >>> Hi all,
> >>>
> >>> The TLS WG is about to issue a LC for tls-pwd.
> >>> http://tools.ietf.org/html/draft-ietf-tls-pwd-01
> >>>
> >>> Is there any advantages of tls-pwd over tls-srp?
> >>
> >>  TLS-srp binds the password to a particular finite cyclic group
> >> and the user must use that group for the life of the password.
> >
> > Isn't that required for every protocol that only stores a verifier on the
> > server, rather than a password equivalent?
> >
> > My understanding of TLS-PWD is that the server need to store a password
> > equivalent (called the "base" in the TLS-PWD drafts), and as such does
> not
> > have some of the desirable properties of SRP (or AugPAKE) related to
> > server compromises.
>
>   Your understanding is correct. There are drawbacks with the "desirable
> properties" of both TLS-srp and TLS-pwd. Now you have a choice based on
> what you value more.
>
>   Dan.
>
>
>
>


-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a11c2b3460e568f04ea89c875
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>FYI<br></div>AugPAKE can be implemented over any=
 dl/ec groups and it provides resistance to server compromise (like SRP).<b=
r><br></div>Regards,<br>Shin<br><div><div><div><div class=3D"gmail_extra"><=
br>
<br><div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 7:29 AM, Dan Harkins =
<span dir=3D"ltr">&lt;<a href=3D"mailto:dharkins@lounge.org" target=3D"_bla=
nk">dharkins@lounge.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div class=3D"im"><br>
On Wed, November 6, 2013 1:43 pm, Fabrice wrote:<br>
&gt;&gt; On Nov 6, 2013, at 13:02, &quot;Dan Harkins&quot; &lt;<a href=3D"m=
ailto:dharkins@lounge.org">dharkins@lounge.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =A0Hi Shin,<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Wed, November 6, 2013 12:15 pm, SeongHan Shin wrote:<br>
&gt;&gt;&gt; Hi all,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; The TLS WG is about to issue a LC for tls-pwd.<br>
&gt;&gt;&gt; <a href=3D"http://tools.ietf.org/html/draft-ietf-tls-pwd-01" t=
arget=3D"_blank">http://tools.ietf.org/html/draft-ietf-tls-pwd-01</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Is there any advantages of tls-pwd over tls-srp?<br>
&gt;&gt;<br>
&gt;&gt; =A0TLS-srp binds the password to a particular finite cyclic group<=
br>
&gt;&gt; and the user must use that group for the life of the password.<br>
&gt;<br>
&gt; Isn&#39;t that required for every protocol that only stores a verifier=
 on the<br>
&gt; server, rather than a password equivalent?<br>
&gt;<br>
&gt; My understanding of TLS-PWD is that the server need to store a passwor=
d<br>
&gt; equivalent (called the &quot;base&quot; in the TLS-PWD drafts), and as=
 such does not<br>
&gt; have some of the desirable properties of SRP (or AugPAKE) related to<b=
r>
&gt; server compromises.<br>
<br>
</div>=A0 Your understanding is correct. There are drawbacks with the &quot=
;desirable<br>
properties&quot; of both TLS-srp and TLS-pwd. Now you have a choice based o=
n<br>
what you value more.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=A0 Dan.<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div styl=
e=3D"MARGIN:0mm 0mm 0pt"><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;=
FONT-SIZE:10pt" lang=3D"EN-US">--------------------------------------------=
----------------------<br>
SeongHan Shin<br></span><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;F=
ONT-SIZE:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div></div></div>

--001a11c2b3460e568f04ea89c875--

From seonghan.shin@aist.go.jp  Wed Nov  6 14:44:30 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 5A33D21F9F9E for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 dLgRpQB597lD for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 14:44:22 -0800 (PST)
Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id 9347811E80E2 for <tls@ietf.org>; Wed,  6 Nov 2013 14:44:21 -0800 (PST)
Received: from mail-la0-f42.google.com ([209.85.215.42]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUnrGPcr9pw9Ib4riFgB4LUzLP1GVpE/B@postini.com; Wed, 06 Nov 2013 14:44:21 PST
Received: by mail-la0-f42.google.com with SMTP id ep20so136737lab.29 for <tls@ietf.org>; Wed, 06 Nov 2013 14:44:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AQnvDuxTy2IsQNfTelkSibqSRKEhgLVrld7nnEs2EG8=; b=v27nC6J0E7PRGjxqQbnGWP+66vMGym0FoPkRMMlNzPqzJkTeFxn84tKWqCbCMJZ3hO 58aJjXtSHS6Iv1dguYIuUzpgyMaZlYgvLHCMkxdnKUP54ToM16z7NDLHzOiuCejYwg2c cGVdGrpg/R01TEI/oPO+WFPPed87cm7/2xx5s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AQnvDuxTy2IsQNfTelkSibqSRKEhgLVrld7nnEs2EG8=; b=X5wXwOalNtV4TT0ZE/jh/yIPvSJsuenoBgYu4PcwWpLW0kH2e52ycjHd/godkiL3fo JCcMX55i/vo1JmQRuTIqunQdmvU0u31vmyz2tGuzMhBEfz2svNZCpgvIzQnBwQWDFEdN Gc2CwxqqTkWvww3syKPDSOA1CHic+d8Hgn1N+WTLVzt1fnVyuyJbOM8SitwwDk5E3/DL IVZrERRnVmPdY9oGEvKJCphIOCdw/57THn6zSTGgi2m+6Si9KHMspucWoUvM43lHrJzg r8O/sdox5bc7TP3Vxcz7tb/Ccb79U5pP/zTANVufHp2Diqlp9xaJQcZwNdGryPMnonDi oA4Q==
X-Gm-Message-State: ALoCoQnBajYy3QLpqAcJdXgV3G6ttMwBBBh887SIDoOA3wfgt1jtn7mWwK8CX2140tnoKOKWWeqSVqR6Nti8xP4lh+0sokh5PDkzfrTOplvWwP4bY6lRR/2R23uSNHfvaaAJq5NWlGsjciJ9J4x3x2ittKBSG49oog==
X-Received: by 10.152.37.229 with SMTP id b5mr327535lak.53.1383777851929; Wed, 06 Nov 2013 14:44:11 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.37.229 with SMTP id b5mr327531lak.53.1383777851812; Wed, 06 Nov 2013 14:44:11 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Wed, 6 Nov 2013 14:44:11 -0800 (PST)
In-Reply-To: <de8e217085c2cc62290e9dad107c84ed.squirrel@www.trepanning.net>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net> <CAEKgtqm5pKf+Ky2jazGpDan02yjdtAOhiwfCyAiT_uEHHhEnuA@mail.gmail.com> <de8e217085c2cc62290e9dad107c84ed.squirrel@www.trepanning.net>
Date: Thu, 7 Nov 2013 07:44:11 +0900
Message-ID: <CAEKgtqmBu2tOtJ1yUQtaTF3umtHpauFqL2XsSGtDNew-fFcWiw@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: Dan Harkins <dharkins@lounge.org>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e0141a74e4e3c7904ea89e377
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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, 06 Nov 2013 22:44:30 -0000

--089e0141a74e4e3c7904ea89e377
Content-Type: text/plain; charset=ISO-8859-1

Hi Dan,

I also was in the IPsec mailing list through all discussions of PAKE
schemes.
But, I don't remember any advantages of pwd over augpake and speke.
Do you mean patent issue that pwd is patent-free and speke isn't?

Regards,
Shin

On Thu, Nov 7, 2013 at 7:32 AM, Dan Harkins <dharkins@lounge.org> wrote:

>
>   Hi Shin,
>
> On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:
> > Hi Dan,
> >
> > Here comes the next question:
> > Is there any advantages of tls-pwd over tls-augpake and SPEKE?
> > https://tools.ietf.org/html/draft-shin-tls-augpake-01
> > http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29
>
>   Mrs. Harkins didn't raise a moron. I really do not want to
> repeat the debacle that occurred on the IPsec mailing list
> regarding PAKE schemes.
>
>   If you would like to rehash all those exchanges I suggest
> you go look at the archives.
>
>   regards,
>
>   Dan.
>
>
>
>


-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--089e0141a74e4e3c7904ea89e377
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi Dan,<br><br></div>I also was in the IPse=
c mailing list through all discussions of PAKE schemes.<br></div>But, I don=
&#39;t remember any advantages of pwd over augpake and speke.<br></div>Do y=
ou mean patent issue that pwd is patent-free and speke isn&#39;t?<br>
<div><div><div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">Regards,<br></div><div class=3D"gmail_extra">Shin<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 7:32=
 AM, Dan Harkins <span dir=3D"ltr">&lt;<a href=3D"mailto:dharkins@lounge.or=
g" target=3D"_blank">dharkins@lounge.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
=A0 Hi Shin,<br>
<div class=3D"im"><br>
On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:<br>
&gt; Hi Dan,<br>
&gt;<br>
&gt; Here comes the next question:<br>
&gt; Is there any advantages of tls-pwd over tls-augpake and SPEKE?<br>
&gt; <a href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01" targ=
et=3D"_blank">https://tools.ietf.org/html/draft-shin-tls-augpake-01</a><br>
&gt; <a href=3D"http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29" targ=
et=3D"_blank">http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29</a><br>
<br>
</div>=A0 Mrs. Harkins didn&#39;t raise a moron. I really do not want to<br=
>
repeat the debacle that occurred on the IPsec mailing list<br>
regarding PAKE schemes.<br>
<br>
=A0 If you would like to rehash all those exchanges I suggest<br>
you go look at the archives.<br>
<br>
=A0 regards,<br>
<br>
=A0 Dan.<br>
<br>
<br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"MARGIN:0m=
m 0mm 0pt"><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;FONT-SIZE:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>
SeongHan Shin<br></span><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;F=
ONT-SIZE:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div></div></div>

--089e0141a74e4e3c7904ea89e377--

From seonghan.shin@aist.go.jp  Wed Nov  6 17:15:11 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 DEBBA11E820E for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 17:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 4GgTS8eMopOt for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 17:15:07 -0800 (PST)
Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id E2CF511E81E3 for <tls@ietf.org>; Wed,  6 Nov 2013 17:15:06 -0800 (PST)
Received: from mail-la0-f41.google.com ([209.85.215.41]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUnrpmlMuAxvy70EmUhvhEEbO8Gxv8Bgt@postini.com; Wed, 06 Nov 2013 17:15:07 PST
Received: by mail-la0-f41.google.com with SMTP id ea20so236167lab.28 for <tls@ietf.org>; Wed, 06 Nov 2013 17:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+JDXFz4C6hkPf7R6ncd4LQTpGHvNFxiwMqcdzbENoao=; b=h6ildmo4h0RFG8KAEzisB8h+fFA71Yuk1xBPIYOyuuZmiSwKe/eiSFT2eWnKMiIAik FXS/Qv+5xe4bKHi9pqlG9t2UOXwg0ENpXAbFnetWQZvgcq9OSdSUgRJdXyaERXnF2aKI CZInp4nsdZaqs2F0wg3ghzekf7NUIFpcBMfHI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+JDXFz4C6hkPf7R6ncd4LQTpGHvNFxiwMqcdzbENoao=; b=R1n8GrEjpqRcfuL6xyj6ZBj+r+CQu6QHYWtW8kfiGf1ddWgKdzzsfiojDzbumpCVAE pGIDxqI9LSwGI0/S62LVE+hxe+/6xWzdO9sTdlvXaFtvaq89T9p69wPlmDqf1fUuHyHC yQxmXFausvGCtVh9HxS4r5js1N1+ReWQEI0Cr0+stg/0Cp2aFsWyXKpwjTQb5G391kCC axe5DEM9n9kYKDjY/1M3WeLC7qc2JDK8jFc5bAmzci9yWfZZiLtrhXAJPVJeqf/Batmm btP/O49cIdXNf0+xxbNEq3EIcveNGXIX/NYXEr8z/mzIjJOD9AdGUu4KOnvnQvuK8ZBl b9qA==
X-Gm-Message-State: ALoCoQlGAfFlt31uM7y8b2fZx3yhFO5r0MXcD6kDOfaA+dUpfuojUBkAWqk9Lg34GAsg5jTNnlGQYqVIZoNhXyBs/ZD+6Ytwv+s8mNU8Ish7HjrEFZKkhvWkzy5fec+hYIyCeVkqrs+zeNlJrrw9r1UWPCSKaiaXcQ==
X-Received: by 10.152.216.167 with SMTP id or7mr4309757lac.10.1383786904991; Wed, 06 Nov 2013 17:15:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.216.167 with SMTP id or7mr4309752lac.10.1383786904843; Wed, 06 Nov 2013 17:15:04 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Wed, 6 Nov 2013 17:15:04 -0800 (PST)
In-Reply-To: <CAEKgtqmBu2tOtJ1yUQtaTF3umtHpauFqL2XsSGtDNew-fFcWiw@mail.gmail.com>
References: <CAEKgtqmAvR3FoWqE8HxxTWSGrmzEGVKGih4k0+iGXDtodDaMFw@mail.gmail.com> <2fde1fc4aa651cb7bcb38749fb24fa25.squirrel@www.trepanning.net> <CAEKgtqm5pKf+Ky2jazGpDan02yjdtAOhiwfCyAiT_uEHHhEnuA@mail.gmail.com> <de8e217085c2cc62290e9dad107c84ed.squirrel@www.trepanning.net> <CAEKgtqmBu2tOtJ1yUQtaTF3umtHpauFqL2XsSGtDNew-fFcWiw@mail.gmail.com>
Date: Thu, 7 Nov 2013 10:15:04 +0900
Message-ID: <CAEKgtqkDbpF84mELSfYdFoff+dVQxyPnVE1rwXbBsFKdYRrGOw@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a1135e318e8885504ea8bfea3
Subject: Re: [TLS] TLS-PWD vs. TLS-SRP
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: Thu, 07 Nov 2013 01:15:12 -0000

--001a1135e318e8885504ea8bfea3
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

> Is there any advantages of tls-pwd over tls-srp?
> Is there any advantages of tls-pwd over tls-augpake and SPEKE?
These are clarifying questions because TLS WG is going with PWD towards
"standard RFC" though PWD has no provable security and is less efficient
(compared to SPEKE and AugPAKE).
Are all tls wg members already clarified with advantages of using tls-pwd?
If so, just let me know.

For patent issues between SPEKE and PWD, there was no conclusions in the
earlier IPsec meetings to my understanding.

Best regards,
Shin


On Thu, Nov 7, 2013 at 7:44 AM, SeongHan Shin <seonghan.shin@aist.go.jp>wrote:

> Hi Dan,
>
> I also was in the IPsec mailing list through all discussions of PAKE
> schemes.
> But, I don't remember any advantages of pwd over augpake and speke.
> Do you mean patent issue that pwd is patent-free and speke isn't?
>
> Regards,
> Shin
>
> On Thu, Nov 7, 2013 at 7:32 AM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>>   Hi Shin,
>>
>> On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:
>> > Hi Dan,
>> >
>> > Here comes the next question:
>> > Is there any advantages of tls-pwd over tls-augpake and SPEKE?
>> > https://tools.ietf.org/html/draft-shin-tls-augpake-01
>> > http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29
>>
>>   Mrs. Harkins didn't raise a moron. I really do not want to
>> repeat the debacle that occurred on the IPsec mailing list
>> regarding PAKE schemes.
>>
>>   If you would like to rehash all those exchanges I suggest
>> you go look at the archives.
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a1135e318e8885504ea8bfea3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear all,<br><div class=3D"gmail_extra"><br>&gt; Is there =
any advantages of tls-pwd over tls-srp?<br>&gt; Is there any advantages of =
tls-pwd over tls-augpake and SPEKE?<br></div><div class=3D"gmail_extra">The=
se are clarifying questions because TLS WG is going with PWD towards &quot;=
standard RFC&quot; though PWD has no provable security and is less efficien=
t (compared to SPEKE and AugPAKE).<br>
</div><div class=3D"gmail_extra">Are all tls wg members already clarified w=
ith advantages of using tls-pwd?<br></div><div class=3D"gmail_extra">If so,=
 just let me know.<br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">
For patent issues between SPEKE and PWD, there was no conclusions in the ea=
rlier IPsec meetings to my understanding.<br><br></div><div class=3D"gmail_=
extra">Best regards,<br></div><div class=3D"gmail_extra">Shin<br></div><div=
 class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 7:44 AM, SeongHan=
 Shin <span dir=3D"ltr">&lt;<a href=3D"mailto:seonghan.shin@aist.go.jp" tar=
get=3D"_blank">seonghan.shin@aist.go.jp</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div>Hi Dan,<br><br></div>I also was in the IPsec mailing list through al=
l discussions of PAKE schemes.<br>

</div>But, I don&#39;t remember any advantages of pwd over augpake and spek=
e.<br></div>Do you mean patent issue that pwd is patent-free and speke isn&=
#39;t?<br>
<div><div><div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">Regards,<br></div><div class=3D"gmail_extra">Shin<br></div><div class=
=3D"gmail_extra"><div><div><br><div class=3D"gmail_quote">On Thu, Nov 7, 20=
13 at 7:32 AM, Dan Harkins <span dir=3D"ltr">&lt;<a href=3D"mailto:dharkins=
@lounge.org" target=3D"_blank">dharkins@lounge.org</a>&gt;</span> wrote:<br=
>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
=A0 Hi Shin,<br>
<div><br>
On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:<br>
&gt; Hi Dan,<br>
&gt;<br>
&gt; Here comes the next question:<br>
&gt; Is there any advantages of tls-pwd over tls-augpake and SPEKE?<br>
&gt; <a href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01" targ=
et=3D"_blank">https://tools.ietf.org/html/draft-shin-tls-augpake-01</a><br>
&gt; <a href=3D"http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29" targ=
et=3D"_blank">http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29</a><br>
<br>
</div>=A0 Mrs. Harkins didn&#39;t raise a moron. I really do not want to<br=
>
repeat the debacle that occurred on the IPsec mailing list<br>
regarding PAKE schemes.<br>
<br>
=A0 If you would like to rehash all those exchanges I suggest<br>
you go look at the archives.<br>
<br>
=A0 regards,<br>
<br>
=A0 Dan.<br>
<br>
<br>
<br>
</blockquote></div><br><br clear=3D"all"><br></div></div><div>-- <br><div s=
tyle=3D"margin:0mm 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#3=
9;;font-size:10pt" lang=3D"EN-US">-----------------------------------------=
-------------------------<br>


SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>


Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+812=
98615285" target=3D"_blank">+81-29-861-5285</a><br>E-mail : <a href=3D"mail=
to:seonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seon=
ghan.shin@aist.go.jp</font></a><br>


------------------------------------------------------------------</span></=
div>
</div></div></div></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margin:0m=
m 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>

SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>

Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+812=
98615285" target=3D"_blank">+81-29-861-5285</a><br>E-mail : <a href=3D"mail=
to:seonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seon=
ghan.shin@aist.go.jp</font></a><br>

------------------------------------------------------------------</span></=
div>
</div></div>

--001a1135e318e8885504ea8bfea3--

From wtc@google.com  Wed Nov  6 23:27:32 2013
Return-Path: <wtc@google.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 B749D21F9E12 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 23:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 a-huJr5IwJkT for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 23:27:31 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBB921E8063 for <tls@ietf.org>; Wed,  6 Nov 2013 23:27:27 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id db12so108960veb.9 for <tls@ietf.org>; Wed, 06 Nov 2013 23:27:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VSVu4IyzWQa4cemtzIVv6v7wK83shBlpkuf+2DOxxtk=; b=aHUS6owaNusimwp78VINRvv5geSuanH0JzqQ96eGHBkcjsVsKOMU1a0IR2LIJg+cv2 6xX3771l68129bPd16ckFVPULi32nUfx5DtM/bPkZ/AJ/Lra26cC+1A5cGIPsQX2+3b/ QAapMhFcNJ+WeYvmlicvY6R3p1wQByEgScDA4zX9x/7HXmcaLbOpg+KIdkNckNZpUdov 1MbAUODVmd4HdQyPwLHR6m+ED52WBRQYepN7JYx3p/PXam5QPrqwfVGGQ88uJHvB9n0x qVlZoUN16+qOHYJg3YVxMJN3Mvv7riHXafwMYKaxp5/2Il0Fm3jbnxKcTWNAkcIxzJZw uIZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VSVu4IyzWQa4cemtzIVv6v7wK83shBlpkuf+2DOxxtk=; b=IVt4JLTbBZ1TDH42d6YG+cnnLaOqqkZsx+WA0xlsd40+zKE17WVJBH5FBAh1FZQAMb 1P0espwWSoDBHRwRdfU3k7I4OCt5EViK2AIAQk30wnmjq146/V/X3IT4Sc/8GJ/aQ9Pu Wa36u67mwYe1RaXbY/cyLxF2t16JIduR2DRIYUqIoOYJRPb6twLIcdRfq555m2zU9wIp XlY0+iBKU4J61R6Qu7zWb8keRoXbtkg8arHhld4xsCkI2Qp4SXOFLja/otbXcvoNZKhu rbTbZfyxP2FAr7p79ULsUmtaShw7Q3zVOZbiNT1Tn0sU2rd/dzAmbKOOyPTGa6DzOK3H /m9Q==
X-Gm-Message-State: ALoCoQnnbaLNLhWItLHxiBk13idbvsQJVFEg7NmjYLQ39dunECA5KbKk/rVdF09aXU/C3cXWplTBisnjdXri5VTiLjMOM5UCPDBnJZT3GsyMkc7x66u5mQgUtotOOVowqOlQaugRNMxbyd0KsTbBGviirjxvGNVNZEg8osSf3w+blvuliMCuC/X6z9N3bsBK337BCw/ppldz
MIME-Version: 1.0
X-Received: by 10.220.244.132 with SMTP id lq4mr130917vcb.31.1383809246880; Wed, 06 Nov 2013 23:27:26 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Wed, 6 Nov 2013 23:27:26 -0800 (PST)
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
Date: Wed, 6 Nov 2013 23:27:26 -0800
Message-ID: <CALTJjxH5ev6GmMymg9kxR6OGO6aYG20zn72qjwMkOMgDbnOPkg@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Xiaoyong Wu <X.Wu@f5.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
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: Thu, 07 Nov 2013 07:27:32 -0000

On Wed, Nov 6, 2013 at 10:00 AM, Xiaoyong Wu <X.Wu@f5.com> wrote:
> It is a little bit more calculation than that and related to some historic reasons, aka SSLv2.
>
> For SSL records, the SSLv3 and TLS ClientHello headers are as follows:
>
> | 22 | version major | version minor | length high bits | length low bits |
>
> If this is interpreted as an SSLv2 header, it will be considered as a 3 byte header:
> | v2 header b0 | v2 header b1 | v2 header b2 | message type |
>
> The value for Client Hello message type is SSLV2_MT_CLIENTHELLO which is 1.
> When there is an SSLv3/TLS client-hello of length 256 - 511 bytes, this is ambiguous as "message type" is 1 or it is the "length high bits" to be 1.
>
> Out implementation before the patch was to prefer SSLv2 and thus the issue.
>
> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.

Hi Xiaoyong,

Thank you very much for explaining the bug and suggesting a workaround.

Could you also explain a related bug in F5 BIG-IP? This bug is
described in the OpenSSL ChangeLog as follows:

   *) Workarounds for some broken servers that "hang" if a client hello
     record length exceeds 255 bytes.

     1. Do not use record version number > TLS 1.0 in initial client
        hello: some (but not all) hanging servers will now work.
     ...
     [Steve Henson]

To work around this F5 BIG-IP bug, the third byte in a TLS ClientHello
record (which is the protocol minor version) needs to be 0 or 1 and
cannot be 2 or 3. Is this bug also caused by interpreting the record
as an SSLv2 ClientHello? In SSLv2 if the first byte of a record is 22
(0x16), then the third byte is PADDING.

Thanks,
Wan-Teh

From wtc@google.com  Wed Nov  6 23:30:15 2013
Return-Path: <wtc@google.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 8D6E111E8242 for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 23:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 yBjZCrH7Szlc for <tls@ietfa.amsl.com>; Wed,  6 Nov 2013 23:30:15 -0800 (PST)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E81B111E820D for <tls@ietf.org>; Wed,  6 Nov 2013 23:30:14 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id x16so101275vbf.37 for <tls@ietf.org>; Wed, 06 Nov 2013 23:30:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FXHMOsDBD0MOi/pAQthsokIeBU9gc207t4NYzmfY/N4=; b=jFm/JyCZeM6jNlgS9QK4unGC0yS+JIOHqJtOGmOUXoxogqu5RmusX+1N6hwX6ukRZc uVVuqCW6BbI7i37a9I4qLtKjZg+0VctrfZ2F6v6o4HGuUNcc+9A4OJ33b+TqtPsNXO9t /BDn+F5LiKbX7aUOf0eJwL9yHmveRc3iiW1j+m2wJnqdJQUjHWfLcAjos/6nHdb22zDe RQSIoy2etPO57vrqoteB7Fj9FYt58D8dgzWn/ZXGZ8khCiA3UU/JY+DUCxU0a8z/jTt5 deKyv1jVrTvu5HgVqH4sfWerhLS3Eh4sQzBn3Xs2PmayY0rdzQpO6p9y+f+J4pcghygC mWYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FXHMOsDBD0MOi/pAQthsokIeBU9gc207t4NYzmfY/N4=; b=QtmANrCCqvz6qQyLPbAgl3Bt4+gMz04aRwIF7jv9QXH6cX46K0XEX0XRYqQVMCBkzn kLmOaN/VdDV7epfyBpZ5wMvD10QAFOSj4ttw/vZmnv+z2qJsq3NMk9oIWL5UyQZbfzoY Oq4VeLu+b2+s3LshcQMsn64F572acN0bM/PkHGnz1lzfXnH2uZdGsbZHngBWhEr9pH0R QrAsitbJN3TMaO5v5vpWOgQs/8O7JL28XHnSWcULDw0ZY78MIxFZwAVmeK+rSI9/k5iy IrapjeezQKhMB33kbyCQXTGgZu8W/MOpCPRYsyoO6hzjsVGmahLvr8sYhAOMggk5wASJ 2WYQ==
X-Gm-Message-State: ALoCoQnwKaGAJevfUD9JKjFMrbZbuwQqg8BdnQqz6XvALK+FRcmcjeCUxQCbeXOaKO5LvOtayU/82I0spJdbNdAxLXuJYgWRd5zMsbokpDBw/bpvw4ys6Pocgg5Vrf7gsvO0O8WwGVtb8gwrdjpB2F2e3rwPNaxWk+b618oqqretCLsWdxBiPdpyEGY0BT4lo+/NB4IXaIj0
MIME-Version: 1.0
X-Received: by 10.220.47.10 with SMTP id l10mr32673vcf.32.1383809413357; Wed, 06 Nov 2013 23:30:13 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Wed, 6 Nov 2013 23:30:13 -0800 (PST)
In-Reply-To: <CAL9PXLxEh50MTaixVrmm2-1KXUkfoiCz+r=jTqvUwQ9D9_Bwag@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAL9PXLzLrCygvS5o-uBAdMbz0U7bZf_L-eQZsbK+Z-eY-XWtRA@mail.gmail.com> <527A86A7.5080700@drh-consultancy.co.uk> <527AACEC.60109@drh-consultancy.co.uk> <CAL9PXLxEh50MTaixVrmm2-1KXUkfoiCz+r=jTqvUwQ9D9_Bwag@mail.gmail.com>
Date: Wed, 6 Nov 2013 23:30:13 -0800
Message-ID: <CALTJjxETdv_t_TJXeQTW1U5EA195xewYW0q8GRic7w=UMUsk5g@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ALPN concerns
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: Thu, 07 Nov 2013 07:30:15 -0000

On Wed, Nov 6, 2013 at 1:00 PM, Adam Langley <agl@google.com> wrote:
> On Wed, Nov 6, 2013 at 3:56 PM, Dr Stephen Henson
> <lists@drh-consultancy.co.uk> wrote:
>> I added this to the OpenSSL master branch in case anyone wants to test it.
>>
>> If enabled it uses a dummy extension[1] to pad the ClientHello with enough
>> zeroes to make it long enough.
>
> Likewise for Chrome: https://codereview.chromium.org/62103003

It would be nice if we could all use the same extension number for
this dummy extension.

Wan-Teh

From X.Wu@f5.com  Thu Nov  7 00:19:07 2013
Return-Path: <X.Wu@f5.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 1A9AF21F9D98 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 00:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 jTspyD94l0kF for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 00:19:00 -0800 (PST)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1738821E80CD for <tls@ietf.org>; Thu,  7 Nov 2013 00:18:56 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208";a="86581871"
X-IPAS-Result: AqEEABhMe1LAqArr/2dsb2JhbABZhBK/DYE5dIIlAQEFOj8MBAIBCA0EBAEBAR4JBzIUCQgBAQQOBQjFXRePKAYrBwaDGoEQA55wjkyCKg
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 07 Nov 2013 08:18:56 +0000
Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 00:18:55 -0800
From: Xiaoyong Wu <X.Wu@F5.com>
To: Wan-Teh Chang <wtc@google.com>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2dskaCaL/Q4ufEA6jUw/n4gAWXiRAAC3mgwAAD0VRYA==
Date: Thu, 7 Nov 2013 08:18:54 +0000
Message-ID: <E774C81546D66E429BF56B1474C7EBBA012CE34992@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CALTJjxH5ev6GmMymg9kxR6OGO6aYG20zn72qjwMkOMgDbnOPkg@mail.gmail.com>
In-Reply-To: <CALTJjxH5ev6GmMymg9kxR6OGO6aYG20zn72qjwMkOMgDbnOPkg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.16.250]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
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: Thu, 07 Nov 2013 08:19:07 -0000

The work around I proposed should work in either cases.=20

Some of our earlier releases do not support TLS 1.1 and 1.2. During the dev=
elopment of the patch, we mistakenly only fixed the issue explicitly for SS=
L 3.0/TLS 1.0 (aka, preferring these 2 versions instead of SSLv2 and not th=
e others) on these releases. This is the reason why using SSL 3.0/TLS 1.0 h=
elped some times.

-Xiaoyong

> -----Original Message-----
> From: Wan-Teh Chang [mailto:wtc@google.com]
> Sent: Wednesday, November 06, 2013 11:27 PM
> To: Xiaoyong Wu
> Cc: Peter Gutmann; <tls@ietf.org>
> Subject: Re: [TLS] ALPN concerns
>=20
> On Wed, Nov 6, 2013 at 10:00 AM, Xiaoyong Wu <X.Wu@f5.com> wrote:
> > It is a little bit more calculation than that and related to some histo=
ric
> reasons, aka SSLv2.
> >
> > For SSL records, the SSLv3 and TLS ClientHello headers are as follows:
> >
> > | 22 | version major | version minor | length high bits | length low
> > | bits |
> >
> > If this is interpreted as an SSLv2 header, it will be considered as a 3=
 byte
> header:
> > | v2 header b0 | v2 header b1 | v2 header b2 | message type |
> >
> > The value for Client Hello message type is SSLV2_MT_CLIENTHELLO which
> is 1.
> > When there is an SSLv3/TLS client-hello of length 256 - 511 bytes, this=
 is
> ambiguous as "message type" is 1 or it is the "length high bits" to be 1.
> >
> > Out implementation before the patch was to prefer SSLv2 and thus the
> issue.
> >
> > As I am explaining this in detail, I would say that another work around=
 on
> this would be making a client hello that exceeds 512 in length.
>=20
> Hi Xiaoyong,
>=20
> Thank you very much for explaining the bug and suggesting a workaround.
>=20
> Could you also explain a related bug in F5 BIG-IP? This bug is described =
in
> the OpenSSL ChangeLog as follows:
>=20
>    *) Workarounds for some broken servers that "hang" if a client hello
>      record length exceeds 255 bytes.
>=20
>      1. Do not use record version number > TLS 1.0 in initial client
>         hello: some (but not all) hanging servers will now work.
>      ...
>      [Steve Henson]
>=20
> To work around this F5 BIG-IP bug, the third byte in a TLS ClientHello re=
cord
> (which is the protocol minor version) needs to be 0 or 1 and cannot be 2 =
or 3.
> Is this bug also caused by interpreting the record as an SSLv2 ClientHell=
o? In
> SSLv2 if the first byte of a record is 22 (0x16), then the third byte is
> PADDING.
>=20
> Thanks,
> Wan-Teh

From dkg@fifthhorseman.net  Thu Nov  7 01:33:44 2013
Return-Path: <dkg@fifthhorseman.net>
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 0389421E80ED for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 01:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 tvDlW5CVBmBd for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 01:33:38 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D94E321E80AA for <tls@ietf.org>; Thu,  7 Nov 2013 01:33:37 -0800 (PST)
Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 7FB2CF984 for <tls@ietf.org>; Thu,  7 Nov 2013 04:33:35 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 508ED1FECB; Thu,  7 Nov 2013 04:33:35 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: TLS Mailing List <tls@ietf.org>
In-Reply-To: <523E763C.1010701@pobox.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com>
User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Thu, 07 Nov 2013 04:33:32 -0500
Message-ID: <87d2mcy2s3.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Subject: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: TLS Mailing List <tls@ietf.org>
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: Thu, 07 Nov 2013 09:33:44 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun 2013-09-22 00:46:52 -0400, Michael D'Errico wrote:
> Yoav Nir wrote:
>> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier <code@funwithsoftware.org=
> wrote:
>>=20
>>> We *do* know how to move to 2048 bits without breaking anything: add
>>> an extension to negotiate DH size, just like how ECC curves are
>>> negotiated.  Although yes, this will take a while to deploy
>>> universally, it at least means early adopters can start using 2048
>>> now, without breaking the stragglers like Java.
>>=20
>> Perhaps it would be better to have the client suggest the actual
>> group rather than bit length in that case. Perhaps we could reuse the
>> IKE numbering of groups, or else have the client specify it similar
>> to ServerDHParams struct.
>
> If the client chooses, then I'd prefer they choose from a list of
> standardized groups similar to RFC 3526 rather than requiring the
> server to (try to) verify that the parameters are usable.  We could
> also sneak in a 256-bit q parameter to speed up the computations.

I'm happy to see the ongoing thinking about TLS 1.3, but i would like to
be able to address the ability to negotiate DH group size with
less-invasive patches to existing implementations too, so i want to try
to flesh out what this DH group negotiation extension would look like.

Here are sketches of three different proposals for consideration:

The minmalist proposal:
=2D----------------------

 * compliant clients advertising a ciphersuite using EDH would include
   an extension indicating the smallest and largest EDH group sizes they
   are willing to accept.

 * compliant servers seeing this extension (and knowing what EDH
   group(s) they have been configured to use) will select or reject the
   EDH ciphersuite based on whether their group falls within the
   client's guidelines.

 * the rest of the key exchange continues as normal.  If the client
   receives an EDH ciphersuite with a group outside its declared range,
   then it terminates the connection (this is being done today by many
   TLS client libraries when they encounter too-weak EDH parameters
   anyway) and decides whether to retry (a new connection) without
   offering any EDH ciphersuites.

The standard-groups proposal:
=2D----------------------------

 * compliant clients advertising a ciphersuite using EDH would include
   an extension indicating which of the standard groups they prefer, via
   a series of bytes matching the identifiers of MODP groups listed in
   RFC 3526, listed in order of preference for the client.

 * compliant servers are configured to accept a subset of the well-known
   enumerated groups.  A server seeing this extension and selecting an
   EDH ciphersuite would select and use the first DH group from the set
   offered that the server is configured to use.  If there is no
   intersection, the server should not select an EDH ciphersuite.  when
   an EDH ciphersuite is selected, either:

   (a) the Server Key Exchange record would contain that group's
       parameters explicitly, like in a standard handshake, or

   (b) the server would offer a modified Server Key Exchange record that
       only indicates the group ID

   (i see these as two variants of the standard-groups proposal, not as
   two options within the standard-groups proposal -- if we go with
   this, we should pick one)

 * the rest of the key exchange continues as normal.  If the client gets
   a Server Key Exchange record that does not match one of the groups it
   specified, the client decides (as it does today) whether to accept
   the connection or to terminate the connection and/or to fall back to
   a reconnection without offering any EDH modes.
=20

The client-chooses proposal:
=2D---------------------------

 * compliant clients advertising a ciphersuite using EDH would include
   an extension indicating a single standard group they use, along with
   a freshly-picked ephemeral public key associated with that group.

 * compliant servers are configured to accept a subset of the well-known
   enumerated groups.  A server seeing this extension and configured to
   accept the offered group responds with a customized Server Key
   Exchange record indicating acceptance of the group, and offering its
   own public key.  A compliant server seeing this extension but not
   configured to accept the offered group should not select an EDH
   ciphersuite.

 * If a compliant client sees the customized Server Key Exchange record,
   it does not send a Client Key Exchange record.  If a compliant client
   sees a normal Server Key Exchange record, then it assumes the server
   is ignorant of the extension, and decides (as it does today) whether
   to accept the group, or to terminate the connection and/or fall back
   to a reconnection without offering any EDH modes.


(i've omitted a client-chooses proposal that does not involve standard
groups due to Michael's point about wanting to avoid requiring tha tthe
server validate the group)

I can imagine mixing elements of the above three proposals to create a
hybrid proposal, but i'll leave it at these three for now in hopes of
commentary.  What did i miss?

Some observations:
=2D-----------------

 A) the client-chooses extension is also likely to be much larger than
    the other two proposals.  I'm not so worried about this.

 B) the client-chooses proposal alters the handshake flow and connection
    state logic much more radically than the other two proposals.  This
    makes me much more nervous.

 C) the main gain of any of these proposals is that they allow/encourage
    an otherwise-conservative server implementation to use stronger DH
    groups without worrying about incurring a connection failure from
    non-compliant clients.  A compliant server implementation would
    still need to decide what to do when it hears from a client that
    does not offer the extension.  It would be great to be able to point
    to something like draft-sheffer-tls-bcp for guidance in this
    situation.

 D) settling on standard groups means a few things:
=20
    * we'll have to either choose an existing registry or make up a new
      one.  I've mentioned RFC 3526 above because it seems like a
      reasonable existing registry
=20
    * implementations adopting the registry won't need to bother with
      primality testing or length testing when using groups from the
      registry.

    * choosing standard groups smells a lot like the choice of which ECC
      curves to use, but i don't think i ever heard quite as much of a
      brouhaha over the groups in RFC 3526 as i've heard over the suiteB
      curves.  Does going with standard curves mean inviting this kind
      of struggle all over again in a different domain?  What kinds of
      mathematical assurances do we have to ensure that the standard
      groups themselves aren't somehow deliberately weakened by their
      selector?  Are there pre-computation or large-data attacks that a
      powerful adversary could use to target a widely-used group more
      effectively than an ever-changing sea of different DH groups? I
      don't know the math literature well enough to comment on any of
      this, but i would be curious to hear other people's thoughts.

 E) the client-side configuration options required for the minimalist
    proposal are a strict subset of the configuration options of the
    other proposals, since the other proposals still need to have DH
    group size limits to deal with servers unaware of the extension.


All of the observations above make me think that the minimalist proposal
seems to be the least likely to cause controversy and the simplest to
patch into existing implementations quickly and safely.

Also, none of these proposals preclude any of the other ones, so it's
conceivable that we could aim for a relatively rapid rollout of the
minimalist proposal while shooting for longer-term adoption of one of
the others.

So i'm currently leaning toward the minimalist proposal, because i think
it gives us much of the gains described in (C) without too much
additional implementation hand-wringing or controversy.

Thoughts?  I'd be willing to write up a draft of one of these proposals
and implement it if there's sufficient interest.

        --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQJ8BAEBCgBmBQJSe15sXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcZkMP/3GNNp22hPADlxA+EI7Hgio2
HlfA794C2H1fHwoRiVMxnQM1CPF0wVYpWJX6WXI6Vt5g6w3WoSUCRGxgFzFQEdOB
mvG2u+NlSDW+yzOdbffx50xkQbNZvK5cG8DtefqgIAbn8/zV+ZZltvu2M9PjdLZJ
+Mq/TwgJBvds1VuKXrTvhl2/jJFckkw6gUqDlPJSMmvpRdf1nUVAQc/Wl8GHQREl
wZKRY5wGAUclv3X6QgIGAN60WYaQs7dFD+aoOi+xrJmy/dkW9MjlZCfXdA9sytMZ
QnP8rR7xwOzYuIui5LGjGsNxMTeHKI2Cbje2u0zeB/+23BKvBKkWMmNIuIzYdaTO
BfHyCBm99ljXdzFLqqyaLaFF+SNKLcewDr7usaZKn5XWA2y32hPe+bBJZZAjfzEl
Za2NXr71+PI0Pjr/l9hHsNPHQbBlCQshdqOgQdwCZuH/trrvYXjhOQMJbWmMfMef
hlpT0C74FUR8jLSuUenQzMaPF5j9l32HvIeRuf4pT7xS1NtZQUq+9WQRCCrKgfGV
d2Mw26XzBrDlQGBm8WMwYC0rnYyOdq6lOgmiT3Mhve0LMUTWJpsjy6pfN1dFrhuG
Srs7t7e2uQHlH1DAYpvGXEZlx/YAMKVCuqNYyphuWy4wdvdBlZh6cXbkwzqRxvKN
dgRVJh9MvywxycCTgj0a
=5HlA
-----END PGP SIGNATURE-----
--=-=-=--

From quynh.dang@nist.gov  Thu Nov  7 06:14:04 2013
Return-Path: <quynh.dang@nist.gov>
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 8EBB611E8268 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 06:14:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8n-yBGp60IaT for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 06:13:58 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5437711E824D for <tls@ietf.org>; Thu,  7 Nov 2013 06:13:58 -0800 (PST)
Received: from BLUPR09MB039.namprd09.prod.outlook.com (10.255.211.153) by BLUPR09MB037.namprd09.prod.outlook.com (10.255.211.139) with Microsoft SMTP Server (TLS) id 15.0.815.6; Thu, 7 Nov 2013 14:13:50 +0000
Received: from BLUPR09MB039.namprd09.prod.outlook.com ([169.254.10.11]) by BLUPR09MB039.namprd09.prod.outlook.com ([169.254.10.209]) with mapi id 15.00.0815.000; Thu, 7 Nov 2013 14:13:50 +0000
From: "Dang, Quynh" <quynh.dang@nist.gov>
To: TLS Mailing List <tls@ietf.org>
Thread-Topic: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
Thread-Index: AQHO25x776A78UevjE6My2wkqQqIg5oZzvXx
Date: Thu, 7 Nov 2013 14:13:49 +0000
Message-ID: <bc97bae5fe504945b73e83fe3db0713b@BLUPR09MB039.namprd09.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com>	<523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com>,<87d2mcy2s3.fsf@alice.fifthhorseman.net>
In-Reply-To: <87d2mcy2s3.fsf@alice.fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [129.6.222.57]
x-forefront-prvs: 00235A1EEF
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(51704005)(377454003)(43544003)(24454002)(377424004)(65816001)(66066001)(80022001)(74662001)(80976001)(2656002)(74706001)(74316001)(81816001)(76482001)(85306002)(74876001)(33646001)(69226001)(81686001)(56776001)(54316002)(81342001)(59766001)(79102001)(81542001)(74366001)(53806001)(51856001)(46102001)(87266001)(19580395003)(77096001)(47446002)(50986001)(47736001)(74502001)(56816003)(63696002)(77982001)(54356001)(83072001)(19580405001)(47976001)(83322001)(4396001)(76786001)(31966008)(49866001)(561944002)(224303002)(76576001)(76796001)(87936001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR09MB037; H:BLUPR09MB039.namprd09.prod.outlook.com; CLIP:129.6.222.57; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
Subject: Re: [TLS] DH group negotiation extension [was: Re:	draft-sheffer-tls-bcp: DH recommendations]
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: Thu, 07 Nov 2013 14:14:04 -0000

I discussed a little bit about DH key sizes issue in TLS before. I would su=
pport and review any draft trying to take care of this issue.=0A=
=0A=
Quynh. =0A=
________________________________________=0A=
From: tls-bounces@ietf.org <tls-bounces@ietf.org> on behalf of Daniel Kahn =
Gillmor <dkg@fifthhorseman.net>=0A=
Sent: Thursday, November 07, 2013 4:33 AM=0A=
To: TLS Mailing List=0A=
Subject: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-b=
cp: DH recommendations]=0A=
=0A=
On Sun 2013-09-22 00:46:52 -0400, Michael D'Errico wrote:=0A=
> Yoav Nir wrote:=0A=
>> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier <code@funwithsoftware.org=
> wrote:=0A=
>>=0A=
>>> We *do* know how to move to 2048 bits without breaking anything: add=0A=
>>> an extension to negotiate DH size, just like how ECC curves are=0A=
>>> negotiated.  Although yes, this will take a while to deploy=0A=
>>> universally, it at least means early adopters can start using 2048=0A=
>>> now, without breaking the stragglers like Java.=0A=
>>=0A=
>> Perhaps it would be better to have the client suggest the actual=0A=
>> group rather than bit length in that case. Perhaps we could reuse the=0A=
>> IKE numbering of groups, or else have the client specify it similar=0A=
>> to ServerDHParams struct.=0A=
>=0A=
> If the client chooses, then I'd prefer they choose from a list of=0A=
> standardized groups similar to RFC 3526 rather than requiring the=0A=
> server to (try to) verify that the parameters are usable.  We could=0A=
> also sneak in a 256-bit q parameter to speed up the computations.=0A=
=0A=
I'm happy to see the ongoing thinking about TLS 1.3, but i would like to=0A=
be able to address the ability to negotiate DH group size with=0A=
less-invasive patches to existing implementations too, so i want to try=0A=
to flesh out what this DH group negotiation extension would look like.=0A=
=0A=
Here are sketches of three different proposals for consideration:=0A=
=0A=
The minmalist proposal:=0A=
-----------------------=0A=
=0A=
 * compliant clients advertising a ciphersuite using EDH would include=0A=
   an extension indicating the smallest and largest EDH group sizes they=0A=
   are willing to accept.=0A=
=0A=
 * compliant servers seeing this extension (and knowing what EDH=0A=
   group(s) they have been configured to use) will select or reject the=0A=
   EDH ciphersuite based on whether their group falls within the=0A=
   client's guidelines.=0A=
=0A=
 * the rest of the key exchange continues as normal.  If the client=0A=
   receives an EDH ciphersuite with a group outside its declared range,=0A=
   then it terminates the connection (this is being done today by many=0A=
   TLS client libraries when they encounter too-weak EDH parameters=0A=
   anyway) and decides whether to retry (a new connection) without=0A=
   offering any EDH ciphersuites.=0A=
=0A=
The standard-groups proposal:=0A=
-----------------------------=0A=
=0A=
 * compliant clients advertising a ciphersuite using EDH would include=0A=
   an extension indicating which of the standard groups they prefer, via=0A=
   a series of bytes matching the identifiers of MODP groups listed in=0A=
   RFC 3526, listed in order of preference for the client.=0A=
=0A=
 * compliant servers are configured to accept a subset of the well-known=0A=
   enumerated groups.  A server seeing this extension and selecting an=0A=
   EDH ciphersuite would select and use the first DH group from the set=0A=
   offered that the server is configured to use.  If there is no=0A=
   intersection, the server should not select an EDH ciphersuite.  when=0A=
   an EDH ciphersuite is selected, either:=0A=
=0A=
   (a) the Server Key Exchange record would contain that group's=0A=
       parameters explicitly, like in a standard handshake, or=0A=
=0A=
   (b) the server would offer a modified Server Key Exchange record that=0A=
       only indicates the group ID=0A=
=0A=
   (i see these as two variants of the standard-groups proposal, not as=0A=
   two options within the standard-groups proposal -- if we go with=0A=
   this, we should pick one)=0A=
=0A=
 * the rest of the key exchange continues as normal.  If the client gets=0A=
   a Server Key Exchange record that does not match one of the groups it=0A=
   specified, the client decides (as it does today) whether to accept=0A=
   the connection or to terminate the connection and/or to fall back to=0A=
   a reconnection without offering any EDH modes.=0A=
=0A=
=0A=
The client-chooses proposal:=0A=
----------------------------=0A=
=0A=
 * compliant clients advertising a ciphersuite using EDH would include=0A=
   an extension indicating a single standard group they use, along with=0A=
   a freshly-picked ephemeral public key associated with that group.=0A=
=0A=
 * compliant servers are configured to accept a subset of the well-known=0A=
   enumerated groups.  A server seeing this extension and configured to=0A=
   accept the offered group responds with a customized Server Key=0A=
   Exchange record indicating acceptance of the group, and offering its=0A=
   own public key.  A compliant server seeing this extension but not=0A=
   configured to accept the offered group should not select an EDH=0A=
   ciphersuite.=0A=
=0A=
 * If a compliant client sees the customized Server Key Exchange record,=0A=
   it does not send a Client Key Exchange record.  If a compliant client=0A=
   sees a normal Server Key Exchange record, then it assumes the server=0A=
   is ignorant of the extension, and decides (as it does today) whether=0A=
   to accept the group, or to terminate the connection and/or fall back=0A=
   to a reconnection without offering any EDH modes.=0A=
=0A=
=0A=
(i've omitted a client-chooses proposal that does not involve standard=0A=
groups due to Michael's point about wanting to avoid requiring tha tthe=0A=
server validate the group)=0A=
=0A=
I can imagine mixing elements of the above three proposals to create a=0A=
hybrid proposal, but i'll leave it at these three for now in hopes of=0A=
commentary.  What did i miss?=0A=
=0A=
Some observations:=0A=
------------------=0A=
=0A=
 A) the client-chooses extension is also likely to be much larger than=0A=
    the other two proposals.  I'm not so worried about this.=0A=
=0A=
 B) the client-chooses proposal alters the handshake flow and connection=0A=
    state logic much more radically than the other two proposals.  This=0A=
    makes me much more nervous.=0A=
=0A=
 C) the main gain of any of these proposals is that they allow/encourage=0A=
    an otherwise-conservative server implementation to use stronger DH=0A=
    groups without worrying about incurring a connection failure from=0A=
    non-compliant clients.  A compliant server implementation would=0A=
    still need to decide what to do when it hears from a client that=0A=
    does not offer the extension.  It would be great to be able to point=0A=
    to something like draft-sheffer-tls-bcp for guidance in this=0A=
    situation.=0A=
=0A=
 D) settling on standard groups means a few things:=0A=
=0A=
    * we'll have to either choose an existing registry or make up a new=0A=
      one.  I've mentioned RFC 3526 above because it seems like a=0A=
      reasonable existing registry=0A=
=0A=
    * implementations adopting the registry won't need to bother with=0A=
      primality testing or length testing when using groups from the=0A=
      registry.=0A=
=0A=
    * choosing standard groups smells a lot like the choice of which ECC=0A=
      curves to use, but i don't think i ever heard quite as much of a=0A=
      brouhaha over the groups in RFC 3526 as i've heard over the suiteB=0A=
      curves.  Does going with standard curves mean inviting this kind=0A=
      of struggle all over again in a different domain?  What kinds of=0A=
      mathematical assurances do we have to ensure that the standard=0A=
      groups themselves aren't somehow deliberately weakened by their=0A=
      selector?  Are there pre-computation or large-data attacks that a=0A=
      powerful adversary could use to target a widely-used group more=0A=
      effectively than an ever-changing sea of different DH groups? I=0A=
      don't know the math literature well enough to comment on any of=0A=
      this, but i would be curious to hear other people's thoughts.=0A=
=0A=
 E) the client-side configuration options required for the minimalist=0A=
    proposal are a strict subset of the configuration options of the=0A=
    other proposals, since the other proposals still need to have DH=0A=
    group size limits to deal with servers unaware of the extension.=0A=
=0A=
=0A=
All of the observations above make me think that the minimalist proposal=0A=
seems to be the least likely to cause controversy and the simplest to=0A=
patch into existing implementations quickly and safely.=0A=
=0A=
Also, none of these proposals preclude any of the other ones, so it's=0A=
conceivable that we could aim for a relatively rapid rollout of the=0A=
minimalist proposal while shooting for longer-term adoption of one of=0A=
the others.=0A=
=0A=
So i'm currently leaning toward the minimalist proposal, because i think=0A=
it gives us much of the gains described in (C) without too much=0A=
additional implementation hand-wringing or controversy.=0A=
=0A=
Thoughts?  I'd be willing to write up a draft of one of these proposals=0A=
and implement it if there's sufficient interest.=0A=
=0A=
        --dkg=0A=

From fabrice.gautier@gmail.com  Thu Nov  7 08:20:35 2013
Return-Path: <fabrice.gautier@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 9837A21E8120 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 08:20:35 -0800 (PST)
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 BrSHe8gCJPYZ for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 08:20:34 -0800 (PST)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 59BAD11E8168 for <tls@ietf.org>; Thu,  7 Nov 2013 08:20:33 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id p61so760508wes.5 for <tls@ietf.org>; Thu, 07 Nov 2013 08:20:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SIAI9begOI8s8kKcv9D+qfy01CXmni6N1GxBFQd/IwM=; b=lA1FJpvS3f8iZZ8ygSZXVxymAU2Mhbeky3AiFMjbIpVcc+x3orVJ2JS+cZcq4APrCi XPd5Y/r5E6SgIXQCrbi87omj6Y+QREHz5tFJFgO3dm+wuADi/+egioI2A9c+MzMVbFLB xCyMjV0wi3Jb0xO6yTCBK9PZ82EExahHsev5MRYyHnOaOz7+3nYLeHkBGqodf3tFRBOU C8/AHjJ/pNkff5cjvm8MXZpyaiqR0R1LBMsvlXXLTno6JVQHdix0TcoAoav0VsA8nCUY hbL0U418D+YB7fohzD2zLHJht5Qlt/cqyKDuCmOWLgoh8enobYURC1qCNlY4QZzPOCeP u8Yg==
X-Received: by 10.180.85.42 with SMTP id e10mr3419878wiz.1.1383841226128; Thu, 07 Nov 2013 08:20:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.176.135 with HTTP; Thu, 7 Nov 2013 08:20:06 -0800 (PST)
In-Reply-To: <CAEKgtqmfHpzNye_DCgyzJ7PmsGRFWCHAtjX=HOLKo0OEoEi0gQ@mail.gmail.com>
References: <CAEKgtqmfHpzNye_DCgyzJ7PmsGRFWCHAtjX=HOLKo0OEoEi0gQ@mail.gmail.com>
From: Fabrice Gautier <fabrice.gautier@gmail.com>
Date: Thu, 7 Nov 2013 08:20:06 -0800
Message-ID: <CANOyrg-LzPbft+DMH8h3HatAJAwTqx6PRBG_n=3MrSfWHcMSqg@mail.gmail.com>
To: SeongHan Shin <seonghan.shin@aist.go.jp>
Content-Type: text/plain; charset=ISO-8859-1
Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= <k-kobara@aist.go.jp>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Augmented PAKE (Re: New Version Notification for draft-shin-tls-augpake-01.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: Thu, 07 Nov 2013 16:20:35 -0000

Hi,

How does the client knows which group to use ?

As the client would need to know the group before sending the
ClientHello, it seems that the client needs to remember the groups
parameters along with the password, which seems impractical.


-- Fabrice


On Wed, Nov 6, 2013 at 11:25 AM, SeongHan Shin <seonghan.shin@aist.go.jp> wrote:
> Dear all,
>
> For anyone who are interested in PAKE, pls see the below I-D regarding
> augmented PAKE.
>
> IMO, two reasons that SRP was published as RFC 2945 and included in IEEE
> 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the
> server's computation cost of SRP is a minimum.
> (Though SRP has no provable security)
>
> The AugPAKE in the below I-D is provably secure and more efficient than
> other augmented PAKEs (including SRP and AMP).
>
> Of course, augmented PAKE provides additional security property over
> (balanced) PAKE.
>
> Best regards,
> Shin
>
>
> On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin <seonghan.shin@aist.go.jp>
> wrote:
>>
>> Dear all,
>>
>> I submitted a new version of our I-D regarding augmented PAKE (AugPAKE)
>> and its integration into TLS.
>> I added some features of AugPAKE in Appendix.
>> Any comments are welcome!
>>
>> Best regards,
>> Shin
>>
>> ---------- Forwarded message ----------
>> From: <internet-drafts@ietf.org>
>> Date: Wed, Sep 4, 2013 at 6:26 PM
>> Subject: New Version Notification for draft-shin-tls-augpake-01.txt
>> To: Kazukuni Kobara <kobara_conf-ml@aist.go.jp>, SeongHan Shin
>> <seonghan.shin@aist.go.jp>
>>
>>
>>
>> A new version of I-D, draft-shin-tls-augpake-01.txt
>> has been successfully submitted by SeongHan Shin and posted to the
>> IETF repository.
>>
>> Filename:        draft-shin-tls-augpake
>> Revision:        01
>> Title:           Augmented Password-Authenticated Key Exchange for
>> Transport Layer Security (TLS)
>> Creation date:   2013-09-04
>> Group:           Individual Submission
>> Number of pages: 19
>> URL:
>> http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-01.txt
>> Status:          http://datatracker.ietf.org/doc/draft-shin-tls-augpake
>> Htmlized:        http://tools.ietf.org/html/draft-shin-tls-augpake-01
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=draft-shin-tls-augpake-01
>>
>> Abstract:
>>    This document describes an efficient augmented password-authenticated
>>    key exchange (AugPAKE) protocol where a user remembers a low-entropy
>>    password and its verifier is registered in the intended server.  In
>>    general, the user password is chosen from a small set of dictionary
>>    whose space is within the off-line dictionary attacks.  The AugPAKE
>>    protocol described here is secure against passive attacks, active
>>    attacks and off-line dictionary attacks (on the obtained messages
>>    with passive/active attacks), and also provides resistance to server
>>    compromise (in the context of augmented PAKE security).  Based on the
>>    AugPAKE protocol, this document also specifies a new password-only
>>    authentication handshake for Transport Layer Security (TLS) protocol.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------------
>> SeongHan Shin
>> Research Institute for Secure Systems (RISEC),
>> National Institute of Advanced Industrial Science and Technology (AIST),
>> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> Tel : +81-29-861-2670/5284
>> Fax : +81-29-861-5285
>> E-mail : seonghan.shin@aist.go.jp
>> ------------------------------------------------------------------
>
>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From skyper@thc.org  Thu Nov  7 08:32:58 2013
Return-Path: <skyper@thc.org>
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 DDF4F21F9CC2 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 08:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 DdjC29mmBtZb for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 08:32:52 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0110621F9CA8 for <tls@ietf.org>; Thu,  7 Nov 2013 08:32:51 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id tp5so1187337ieb.2 for <tls@ietf.org>; Thu, 07 Nov 2013 08:32:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=njgYh7HQTmNlpsHxEQjHSJLDlltiPANpLbstWd/x5s8=; b=QpxZte2PkxZcyZAP00NGpdCivDsXvDSPUa8vPaO+ANG3srqfk9IxWOXtzcPSbOW1w6 pje9bpyqC8ckz1CFBYmdDQUc7v3k5QLyt9vWJKKS1J6IBCXXqmUIWw5JimVK9k/VUsG4 g0BQJFBxQ6BB9Bw/FyeQViR2q4/v6YPyFNJhc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=njgYh7HQTmNlpsHxEQjHSJLDlltiPANpLbstWd/x5s8=; b=LmKNvU9qNE66JO6jYwBPimijdguysuYzi/2yRwQ7MwqkrgJcaAXZM99sty+6425ukI ld3QHstw226RDrdqdb6ECAobVveOuesBO1ywDGLMHelSfXLlE4yO1X0VAcE8AyAiphvg bq7CDYh45BpB4TKw/+P2G9+wZjOrwqM34u/I+/m+O8pfopTi+8eCP/e8vdhjWD3TO1jW WATqybo7jE2evsfBsWCzpITiU5wyE4aiH5HKATOnIv05SpBUZe+TqM8e7kYH75Get49u wn7Hbj7bkqmWdSVB8koTcKH2aHFY3ALsMaCWRDEeZil1lyYiXgTX1APzY8L3yHG6hEq3 Akpg==
X-Gm-Message-State: ALoCoQnAh1LL0ERMhIS3nIh9UVmc4fPu9sBKnu4obDIiUOfQ2k5kZcXB7UaXudCnXUMMqHaKcuKt
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr2640581igb.46.1383841971053; Thu, 07 Nov 2013 08:32:51 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Thu, 7 Nov 2013 08:32:50 -0800 (PST)
X-Originating-IP: [70.42.240.24]
Date: Thu, 7 Nov 2013 16:32:50 +0000
Message-ID: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e0d1f1cd61004ea98d12f
Subject: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 16:32:59 -0000

--047d7b2e0d1f1cd61004ea98d12f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

Thank you for the helpful TLS WG meeting yesterday at
the IETF88 and to the WG for the excellent work on
TLS.


No consensus was reached on =91Reduced RT handshake with
privacy=94.


Some thoughts why SNI (host name) and ALPN should be
transmitted encrypted and not in clear.


1. Meta-data is important. Meta-data tells a lot about a person.
Meta-data can get a user killed or worse. Transmitting the host-name
(meta-data) in clear in TLS is not good (as in =91not good because it
can get you killed=92 and there is no alternative for the user =96 unless
the user is a tech-wizard.).


2. What is the message to the user? TLS is secure =96 well, kind=92a.
TLS secures some things but that you read freedom4gays.com,
secure.washingtonpost.com or myfavoritepoliticalparty.com is
leaked =96 but we still call it secure???


3. Governments just love filtering by site. (Block secure.twitter.com
but not blub.com). Same goes for filtering by application (ALPN).
Transmitting this information in clear plays into the hands of the
adversary.



There are other ways how an adversary can extract the same meta-data.
This should not deter us from fixing it in TLS. Maybe we will find a
solution for the other problems as well (like confidential DNS).


Fixing this in TLS increases the cost of surveillance. This is the goal.


An adversary can no longer use passive surveillance to extract SNI/ALPN.
The adversary is forced to do detectable active surveillance to get the
meta-data).


Those who give up security for a little bit of performance neither
deserve security nor performance.



Regards,



Ralf

--047d7b2e0d1f1cd61004ea98d12f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><br>Thank you for the helpful TLS WG meeting yester=
day at<br>the IETF88 and to the WG for the excellent work on<br>TLS.<br>=A0=
<br><br>No consensus was reached on =91Reduced RT handshake with<br>privacy=
=94.<br>
<br>=A0<br>Some thoughts why SNI (host name) and ALPN should be<br>transmit=
ted encrypted and not in clear.<br><br>=A0<br>1. Meta-data is important. Me=
ta-data tells a lot about a person.<br>Meta-data can get a user killed or w=
orse. Transmitting the host-name<br>
(meta-data) in clear in TLS is not good (as in =91not good because it<br>ca=
n get you killed=92 and there is no alternative for the user =96 unless<br>=
the user is a tech-wizard.).<br><br>=A0<br>2. What is the message to the us=
er? TLS is secure =96 well, kind=92a.<br>
TLS secures some things but that you read <a href=3D"http://freedom4gays.co=
m">freedom4gays.com</a>,<br><a href=3D"http://secure.washingtonpost.com">se=
cure.washingtonpost.com</a> or <a href=3D"http://myfavoritepoliticalparty.c=
om">myfavoritepoliticalparty.com</a> is<br>
leaked =96 but we still call it secure???<br><br><br>3. Governments just lo=
ve filtering by site. (Block <a href=3D"http://secure.twitter.com">secure.t=
witter.com</a><br>but not <a href=3D"http://blub.com">blub.com</a>). Same g=
oes for filtering by application (ALPN).<br>
Transmitting this information in clear plays into the hands of the<br>adver=
sary.<br><br>=A0<br><br>There are other ways how an adversary can extract t=
he same meta-data.<br>This should not deter us from fixing it in TLS. Maybe=
 we will find a<br>
solution for the other problems as well (like confidential DNS).<br><br>=A0=
<br>Fixing this in TLS increases the cost of surveillance. This is the goal=
.<br>=A0<br><br>An adversary can no longer use passive surveillance to extr=
act SNI/ALPN.<br>
The adversary is forced to do detectable active surveillance to get the<br>=
meta-data).<br><br>=A0<br>Those who give up security for a little bit of pe=
rformance neither<br>deserve security nor performance.<br><br>=A0<br><br>Re=
gards,<br>
<br>=A0<br><br>Ralf<br><br>=A0<br></div>

--047d7b2e0d1f1cd61004ea98d12f--

From watsonbladd@gmail.com  Thu Nov  7 08:40:06 2013
Return-Path: <watsonbladd@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 7841111E81D9 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 08:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.056,  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 nv08WD50TaVz for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 08:40:05 -0800 (PST)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AA34D11E825B for <tls@ietf.org>; Thu,  7 Nov 2013 08:39:57 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id q58so799519wes.28 for <tls@ietf.org>; Thu, 07 Nov 2013 08:39:53 -0800 (PST)
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:content-transfer-encoding; bh=QRGrr+OuDRvDRdpOk2kADRfEgN1RortCCOoTRSt859Q=; b=VJkw7IffTvALgtm7v1ZQB2Ih9SzXgiSWjMMI8rx5N2cwNikmf0kehyhTjNFqCLUZZE PVXJ5bZL++YNx0SRKpoUoAzsQxi2YpZqqmHuXthNhXfwW4C3xUpE/EpjEFZ2haBWX9a8 pDkVF4u7Q4MYbYhsg+ue4LeAXVWdojA83GrMkgh1dP3eiHPBTYfs8mFZzmBS3MLm4f51 S1dZZeXYCDE7tpy1MJHr4GBok03amR+HN6qoC0eAWlJvWmT9eGnOY/VyeX1oLFflZdd6 P1QHQV3O3ZDBFbhUufWf6MkPbTIUUS5hIrCZAFWUQyr+Ls642Ke1NvV+4jjPgCZWhCaz NgtQ==
MIME-Version: 1.0
X-Received: by 10.194.93.3 with SMTP id cq3mr8343077wjb.26.1383842393483; Thu, 07 Nov 2013 08:39:53 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 7 Nov 2013 08:39:53 -0800 (PST)
In-Reply-To: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>
Date: Thu, 7 Nov 2013 08:39:53 -0800
Message-ID: <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 16:40:06 -0000

On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> Hi,
>
> Thank you for the helpful TLS WG meeting yesterday at
> the IETF88 and to the WG for the excellent work on
> TLS.
>
>
> No consensus was reached on =E2=80=98Reduced RT handshake with
> privacy=E2=80=9D.
>
>
> Some thoughts why SNI (host name) and ALPN should be
> transmitted encrypted and not in clear.
>
>
> 1. Meta-data is important. Meta-data tells a lot about a person.
> Meta-data can get a user killed or worse. Transmitting the host-name
> (meta-data) in clear in TLS is not good (as in =E2=80=98not good because =
it
> can get you killed=E2=80=99 and there is no alternative for the user =E2=
=80=93 unless
> the user is a tech-wizard.).
They can use Tor. They need to anyway: reverse DNS lookups are not
rocket science.
>
>
> 2. What is the message to the user? TLS is secure =E2=80=93 well, kind=E2=
=80=99a.
> TLS secures some things but that you read freedom4gays.com,
> secure.washingtonpost.com or myfavoritepoliticalparty.com is
> leaked =E2=80=93 but we still call it secure???
This is as secure as sending a sealed envelope through the mail.
>
>
> 3. Governments just love filtering by site. (Block secure.twitter.com
> but not blub.com). Same goes for filtering by application (ALPN).
> Transmitting this information in clear plays into the hands of the
> adversary.
>
>
>
> There are other ways how an adversary can extract the same meta-data.
> This should not deter us from fixing it in TLS. Maybe we will find a
> solution for the other problems as well (like confidential DNS).
No, the other problem is you connect to the server and ask it to show
you a page,
and learn what the server is. The sole exception is multihosting,
which is getting
less common for various reasons.
>
> Fixing this in TLS increases the cost of surveillance. This is the goal.
>
>
> An adversary can no longer use passive surveillance to extract SNI/ALPN.
> The adversary is forced to do detectable active surveillance to get the
> meta-data).
>
>
> Those who give up security for a little bit of performance neither
> deserve security nor performance.
>
>
>
> Regards,
>
>
>
> Ralf
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From skyper@thc.org  Thu Nov  7 09:03:08 2013
Return-Path: <skyper@thc.org>
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 F1E3D21E81D1 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 sgOWdh7pCWcA for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:03:04 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F48D11E821C for <tls@ietf.org>; Thu,  7 Nov 2013 09:03:02 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id x13so1323896ief.9 for <tls@ietf.org>; Thu, 07 Nov 2013 09:03:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=grNzsMpQ/QOXg0Z/nVWUe1e1Ohx8WRnM/aM7VrktwN4=; b=X7Pba+DF26WA2ftO3LDibwxmT6V7hTNzAzgjALN4Ke7JZGcGjsQOGpsxcvLdgltY/2 qPPrHZM1ehP3eamdnsrIIiGSNg5RvnDUQT9T+Uva/ULVjqNH63A5ik0DUCpOJR4FH6lj LrwZ7ZkCQBI+iftyfd9/pdyXuP75K38pz0lxA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=grNzsMpQ/QOXg0Z/nVWUe1e1Ohx8WRnM/aM7VrktwN4=; b=basGXahYltGM8LCxht6ETWu2MmngMrpKe1wPHdjAVAWDmgXRTH1wjkq4t2LYXtXUFm 6jJ1FgbEXo0oRyYHGGMtoYCIBY9jCzmeUMg83q2Iep5aHsKuQLNAYFa9D1D+7Ght9kTy 0ZXncrP/RE8gezS7cxJSNQPEk4EwDvhNCMETbEwHJ10JbTg+D2mEJqfEus5cpPdko/2P kosa2SAsLfKpdLcR657Rb0YqDyFoKKux/QAVxNEcA35RaJOoW4cDFMjVYUQgNDH/FsGI fwjbwG9KIXtSYdUHg6gvfk8qnqROgs7FCuR4dA4Yai5rm2HXcTxowLU94BeR1so8q8px Yt4A==
X-Gm-Message-State: ALoCoQlQrlCyMuDhAORhDUE/orzKgg5qt4XLZANKhtHRMzzzrEt9/7SQTO6WmK7PTBtYP9jVGytO
MIME-Version: 1.0
X-Received: by 10.51.16.35 with SMTP id ft3mr2754867igd.46.1383843781825; Thu, 07 Nov 2013 09:03:01 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Thu, 7 Nov 2013 09:03:01 -0800 (PST)
X-Originating-IP: [70.42.240.24]
In-Reply-To: <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com>
Date: Thu, 7 Nov 2013 17:03:01 +0000
Message-ID: <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134bc1e0b03aa04ea993d98
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 17:03:08 -0000

--001a1134bc1e0b03aa04ea993d98
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote=
:
> >
> >
> > 1. Meta-data is important. Meta-data tells a lot about a person.
> > Meta-data can get a user killed or worse. Transmitting the host-name
> > (meta-data) in clear in TLS is not good (as in =91not good because it
> > can get you killed=92 and there is no alternative for the user =96 unle=
ss
> > the user is a tech-wizard.).
> They can use Tor. They need to anyway: reverse DNS lookups are not
> rocket science.
>

[...]

>
> > There are other ways how an adversary can extract the same meta-data.
> > This should not deter us from fixing it in TLS. Maybe we will find a
> > solution for the other problems as well (like confidential DNS).
> No, the other problem is you connect to the server and ask it to show
> you a page,
> and learn what the server is. The sole exception is multihosting,
> which is getting
> less common for various reasons.
>

As a hacker I would love TLS to leak the host information. It would enable
me
to find out which user connects to admin.blubb.com and who connects just to
www.blubb.com (both domains hosted on same server).

Your comments are wrong in this scenario: Connecting to the server does not
help
the hacker to gain above information. Neither does reverse lookup.

TLS leaks it and there is no other way the hacker would get this
information if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the
problem.



regards,

ralf

--001a1134bc1e0b03aa04ea993d98
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <span dir=3D"ltr">&lt;<a href=
=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail.com</=
a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Nov 7, 2013 at 8:3=
2 AM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyper@thc.org">skyper@thc.o=
rg</a>&gt; wrote:<br>

&gt;<br>
&gt;<br>
&gt; 1. Meta-data is important. Meta-data tells a lot about a person.<br>
&gt; Meta-data can get a user killed or worse. Transmitting the host-name<b=
r>
&gt; (meta-data) in clear in TLS is not good (as in =91not good because it<=
br>
&gt; can get you killed=92 and there is no alternative for the user =96 unl=
ess<br>
&gt; the user is a tech-wizard.).<br>
</div>They can use Tor. They need to anyway: reverse DNS lookups are not<br=
>
rocket science.<br></blockquote><div>=A0<br>[...] <br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">&gt;<br><div class=3D"im">
&gt; There are other ways how an adversary can extract the same meta-data.<=
br>
&gt; This should not deter us from fixing it in TLS. Maybe we will find a<b=
r>
&gt; solution for the other problems as well (like confidential DNS).<br>
</div>No, the other problem is you connect to the server and ask it to show=
<br>
you a page,<br>
and learn what the server is. The sole exception is multihosting,<br>
which is getting<br>
less common for various reasons.<br></blockquote></div><br></div><div class=
=3D"gmail_extra">As a hacker I would love TLS to leak the host information.=
 It would enable me<br>to find out which user connects to <a href=3D"http:/=
/admin.blubb.com">admin.blubb.com</a> and who connects just to<br>
</div><div class=3D"gmail_extra"><a href=3D"http://www.blubb.com">www.blubb=
.com</a> (both domains hosted on same server).<br><br></div><div class=3D"g=
mail_extra">Your comments are wrong in this scenario: Connecting to the ser=
ver does not help<br>
the hacker to gain above information. Neither does reverse lookup.</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">TLS leaks it a=
nd there is no other way the hacker would get this information if<br>TLS wo=
uld not leak it. Transport Layer Kind-off-Security protocol is the problem.=
</div>
<br><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br>reg=
ards,<br><br>ralf<br><br></div></div>

--001a1134bc1e0b03aa04ea993d98--

From ynir@checkpoint.com  Thu Nov  7 09:30:32 2013
Return-Path: <ynir@checkpoint.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 6C6DA11E81E6 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:30:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.522
X-Spam-Level: 
X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 tueSc0uKCuo0 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:30:27 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1406311E81D1 for <tls@ietf.org>; Thu,  7 Nov 2013 09:30:15 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7HUBGN007596; Thu, 7 Nov 2013 19:30:11 +0200
X-CheckPoint: {527BCCA0-1-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 19:30:11 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAA==
Date: Thu, 7 Nov 2013 17:30:11 +0000
Message-ID: <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com>
In-Reply-To: <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.53]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_EEF0FE5030324C7BBA071845CDEDA155checkpointcom_"
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 17:30:32 -0000

--_000_EEF0FE5030324C7BBA071845CDEDA155checkpointcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi, Ralf.

I'm not disagreeing with you regarding 1.3. At least in the long version of=
 the handshake (which you should be able to enable in any browser, if you w=
ant a little more privacy in exchange for an extra roundtrip).

But ordinarily, the sites that can get you killed are not collocated with b=
enign sites. And even when sites are collocated, the servers demux not base=
d on the SNI parameter in the TLS handshake, but based on the Server header=
 in HTTP. The only use of the SNI parameter is for selecting the right cert=
ificate. So if you try to go to https://www.gmail.com , you get a certifica=
te for www.gmail.com<http://www.gmail.com> , before being redirected to the=
 same server, but this time with the URI https://mail.google.com .

It would be much nicer if we could update HTTPS (RFC 2818) to support this =
kind of multi-homing so as to make SNI superfluous. For example, if the ser=
ver certificate could list the different domain names that it was valid for=
. Yes, I know there's an economic side to this as well. I'm sure the CAs co=
uld charge by alternate name if needed.

Yoav

On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:skype=
r@thc.org>> wrote:


On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <watsonbladd@gmail.com<mailto:w=
atsonbladd@gmail.com>> wrote:
On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:s=
kyper@thc.org>> wrote:
>
>
> 1. Meta-data is important. Meta-data tells a lot about a person.
> Meta-data can get a user killed or worse. Transmitting the host-name
> (meta-data) in clear in TLS is not good (as in =91not good because it
> can get you killed=92 and there is no alternative for the user =96 unless
> the user is a tech-wizard.).
They can use Tor. They need to anyway: reverse DNS lookups are not
rocket science.

[...]

>
> There are other ways how an adversary can extract the same meta-data.
> This should not deter us from fixing it in TLS. Maybe we will find a
> solution for the other problems as well (like confidential DNS).
No, the other problem is you connect to the server and ask it to show
you a page,
and learn what the server is. The sole exception is multihosting,
which is getting
less common for various reasons.

As a hacker I would love TLS to leak the host information. It would enable =
me
to find out which user connects to admin.blubb.com<http://admin.blubb.com/>=
 and who connects just to
www.blubb.com<http://www.blubb.com/> (both domains hosted on same server).

Your comments are wrong in this scenario: Connecting to the server does not=
 help
the hacker to gain above information. Neither does reverse lookup.

TLS leaks it and there is no other way the hacker would get this informatio=
n if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the pr=
oblem.



regards,

ralf

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls


--_000_EEF0FE5030324C7BBA071845CDEDA155checkpointcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <F2636F77F82469409914A800421ED321@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
Hi, Ralf.
<div><br>
</div>
<div>I'm not disagreeing with you regarding 1.3. At least in the long versi=
on of the handshake (which you should be able to enable in any browser, if =
you want a little more privacy in exchange for an extra roundtrip).</div>
<div><br>
</div>
<div>But ordinarily, the sites that can get you killed are not collocated w=
ith benign sites. And even when sites are collocated, the servers demux not=
 based on the SNI parameter in the TLS handshake, but based on the Server h=
eader in HTTP. The only use of the
 SNI parameter is for selecting the right certificate. So if you try to go =
to <a href=3D"https://www.gmail.com">
https://www.gmail.com</a> , you get a certificate for <a href=3D"http://www=
.gmail.com">
www.gmail.com</a> , before being redirected to the same server, but this ti=
me with the URI
<a href=3D"https://mail.google.com">https://mail.google.com</a> .</div>
<div><br>
</div>
<div>It would be much nicer if we could update HTTPS (RFC 2818) to support =
this kind of multi-homing so as to make SNI superfluous. For example, if th=
e server certificate could list the different domain names that it was vali=
d for. Yes, I know there's an economic
 side to this as well. I'm sure the CAs could charge by alternate name if n=
eeded.</div>
<div><br>
</div>
<div>Yoav</div>
<div><br>
</div>
<div>
<div>
<div>On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:s=
kyper@thc.org">skyper@thc.org</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <spa=
n dir=3D"ltr">
&lt;<a href=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@=
gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"im">On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser &lt;<a=
 href=3D"mailto:skyper@thc.org">skyper@thc.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; 1. Meta-data is important. Meta-data tells a lot about a person.<br>
&gt; Meta-data can get a user killed or worse. Transmitting the host-name<b=
r>
&gt; (meta-data) in clear in TLS is not good (as in =91not good because it<=
br>
&gt; can get you killed=92 and there is no alternative for the user =96 unl=
ess<br>
&gt; the user is a tech-wizard.).<br>
</div>
They can use Tor. They need to anyway: reverse DNS lookups are not<br>
rocket science.<br>
</blockquote>
<div>&nbsp;<br>
[...] <br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
&gt;<br>
<div class=3D"im">&gt; There are other ways how an adversary can extract th=
e same meta-data.<br>
&gt; This should not deter us from fixing it in TLS. Maybe we will find a<b=
r>
&gt; solution for the other problems as well (like confidential DNS).<br>
</div>
No, the other problem is you connect to the server and ask it to show<br>
you a page,<br>
and learn what the server is. The sole exception is multihosting,<br>
which is getting<br>
less common for various reasons.<br>
</blockquote>
</div>
<br>
</div>
<div class=3D"gmail_extra">As a hacker I would love TLS to leak the host in=
formation. It would enable me<br>
to find out which user connects to <a href=3D"http://admin.blubb.com/">admi=
n.blubb.com</a> and who connects just to<br>
</div>
<div class=3D"gmail_extra"><a href=3D"http://www.blubb.com/">www.blubb.com<=
/a> (both domains hosted on same server).<br>
<br>
</div>
<div class=3D"gmail_extra">Your comments are wrong in this scenario: Connec=
ting to the server does not help<br>
the hacker to gain above information. Neither does reverse lookup.</div>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">TLS leaks it and there is no other way the hacke=
r would get this information if<br>
TLS would not leak it. Transport Layer Kind-off-Security protocol is the pr=
oblem.</div>
<br>
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra"><br>
regards,<br>
<br>
ralf<br>
<br>
</div>
</div>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
https://www.ietf.org/mailman/listinfo/tls<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>

--_000_EEF0FE5030324C7BBA071845CDEDA155checkpointcom_--

From rsalz@akamai.com  Thu Nov  7 09:39:56 2013
Return-Path: <rsalz@akamai.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 54FC121E81C2 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 DwJ7nGGPRDBx for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:39:48 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 141F321F9A2E for <tls@ietf.org>; Thu,  7 Nov 2013 09:39:09 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D40E84742D; Thu,  7 Nov 2013 17:39:08 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C73204742C; Thu,  7 Nov 2013 17:39:08 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id BD41C2038; Thu,  7 Nov 2013 17:39:08 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 7 Nov 2013 12:39:08 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Yoav Nir <ynir@checkpoint.com>
Date: Thu, 7 Nov 2013 12:39:07 -0500
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAIAAI6dw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14F@USMBX1.msg.corp.akamai.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
In-Reply-To: <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14FUSMBX1msgcorp_"
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 17:39:56 -0000

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14FUSMBX1msgcorp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=D8  For example, if the server certificate could list the different domain=
 names that it was valid for.

Like subjectAltName?  But unlike SNI, that requires the hosted parties to c=
ooperate in getting the certificate. SNI does not.

                /r$

--
Principal Security Engineer
Akamai Technology
Cambridge, MA

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14FUSMBX1msgcorp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-=
1">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta name=3DGenerator content=3D"Microso=
ft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1887713937;
	mso-list-type:hybrid;
	mso-list-template-ids:-217426990 -1844541514 67698691 67698693 67698689 67=
698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:2013;
	mso-level-number-format:bullet;
	mso-level-text:\F0D8;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoListParagraph style=3D'=
text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span styl=
e=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'><span style=3D'm=
so-list:Ignore'>=D8<span style=3D'font:7.0pt "Times New Roman"'>&nbsp; </sp=
an></span></span><![endif]>For example, if the server certificate could lis=
t the different domain names that it was valid for.<span style=3D'font-size=
:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span=
></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cali=
bri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=3DMso=
Normal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";c=
olor:#1F497D'>Like subjectAltName?=A0 But unlike SNI, that requires the hos=
ted parties to cooperate in getting the certificate. SNI does not.<o:p></o:=
p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami=
ly:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p cla=
ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-=
serif";color:#1F497D'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$<o:p=
></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font=
-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><=
div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calib=
ri","sans-serif";color:#1F497D'>--=A0 <o:p></o:p></span></p><p class=3DMsoN=
ormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";co=
lor:#1F497D'>Principal Security Engineer<o:p></o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";=
color:#1F497D'>Akamai Technology<o:p></o:p></span></p><p class=3DMsoNormal>=
<span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1=
F497D'>Cambridge, MA<o:p></o:p></span></p></div></div></body></html>=

--_000_2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14FUSMBX1msgcorp_--

From ryan.hurst@globalsign.com  Thu Nov  7 09:48:31 2013
Return-Path: <ryan.hurst@globalsign.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 2BDFD11E825F for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9Mxp644byMPo for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 09:48:07 -0800 (PST)
Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A057921F9FB9 for <tls@ietf.org>; Thu,  7 Nov 2013 09:47:58 -0800 (PST)
Received: by mail-bk0-f43.google.com with SMTP id mz13so365637bkb.2 for <tls@ietf.org>; Thu, 07 Nov 2013 09:47:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=from:references:in-reply-to:thread-index:mime-version:date :message-id:subject:to:cc:content-type; bh=REjRXWyIzq3pxYOQiYnB0DHkBhJp4q8xdLNAJguiqJM=; b=dCsFS165unFCA7NIqhvy6MVtkdutKtChYDiiC6rKn11J/VD+faPgwpAgInQDMQq3eF eiDWGqK/5Jzv1ClnFmQSPm4YPNC30p9HHVkYFYZCYI1ObRc3mXvkoQyCbnDO+tSKsSCb QzmbUleHbfxKiAaxxnf20VmJP41Q5lcVny6Uc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:thread-index :mime-version:date:message-id:subject:to:cc:content-type; bh=REjRXWyIzq3pxYOQiYnB0DHkBhJp4q8xdLNAJguiqJM=; b=An5dXQsnXreFKc2kDrY2dnR0S75irHWR9nojA1tcypHtqerwVK/RKsrwS+Y28pkUkf cDCgbwCf5E1N5P1XUNqHi9OR1ZhYXrNLwqbcM9QXSG3tINSgFCWUj4SARDDzTMMYOe0O XyPWq7tOft3d6qS6KVS4zQLijmMJafIM2zCBzkyZIzp5rGUq0ZWANA/7itEsplJQS21q nmLxrOiHRA38q8xMCZZz8/HYtHrfVKz/YAJOh1oUxH21PeqxvDuwSqsFW6out0vOAtS8 6UTt4yCj2t+XJO1sQQ8nhZRCQvqGc/HgNNe6fJ/8IznzlsrlzJJpz2Xn4OzCDn75Fz+U Zj/g==
X-Gm-Message-State: ALoCoQn9C1iOXHldi8SrmogZrv64DtzksYOBR1wRb5tBXP3G26nK7U7Tltd6iSXHxOghtzmNl59z
X-Received: by 10.204.171.17 with SMTP id f17mr3144736bkz.38.1383846476877; Thu, 07 Nov 2013 09:47:56 -0800 (PST)
From: Ryan Hurst <ryan.hurst@globalsign.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
In-Reply-To: <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHXUrcERbrmR2U3TIwftBPbZ7f3aQKDdKchAo1MQUgB+s+n3pnQwCPQ
MIME-Version: 1.0
Date: Thu, 7 Nov 2013 09:47:51 -0800
Message-ID: <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>, Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: multipart/mixed; boundary=bcaec52c6937ade0e404ea99dd7a
Cc: tls@ietf.org
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 17:48:31 -0000

--bcaec52c6937ade0e404ea99dd7a
Content-Type: multipart/alternative; boundary=bcaec52c6937ade0e004ea99dd78

--bcaec52c6937ade0e004ea99dd78
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I don=92t think the economic issues should be a consideration here, just
whats the right solution.



CAs are already required to include all the domain names in the SAN (
https://www.cabforum.org/Baseline_Requirements_V1.pdf) and all CAs have
models for doing this.



The core issue is that SNI doesn=92t require shared keys across parties or
cooperation of any type, using multi-san certificates does. This works in
some cases, for example when the arbitrator (like a CDN) manages that
cooperation but in some cases its not possible for them to.



In such cases they need a dedicated IP or SNI.



Ryan





*From:* tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] *On Behalf Of *Y=
oav
Nir
*Sent:* Thursday, November 7, 2013 9:30 AM
*To:* Ralf Skyper Kaiser
*Cc:* tls@ietf.org
*Subject:* Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS
1.3



Hi, Ralf.



I'm not disagreeing with you regarding 1.3. At least in the long version of
the handshake (which you should be able to enable in any browser, if you
want a little more privacy in exchange for an extra roundtrip).



But ordinarily, the sites that can get you killed are not collocated with
benign sites. And even when sites are collocated, the servers demux not
based on the SNI parameter in the TLS handshake, but based on the Server
header in HTTP. The only use of the SNI parameter is for selecting the
right certificate. So if you try to go to https://www.gmail.com , you get a
certificate for www.gmail.com , before being redirected to the same server,
but this time with the URI https://mail.google.com .



It would be much nicer if we could update HTTPS (RFC 2818) to support this
kind of multi-homing so as to make SNI superfluous. For example, if the
server certificate could list the different domain names that it was valid
for. Yes, I know there's an economic side to this as well. I'm sure the CAs
could charge by alternate name if needed.



Yoav



On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:





On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>
>
> 1. Meta-data is important. Meta-data tells a lot about a person.
> Meta-data can get a user killed or worse. Transmitting the host-name
> (meta-data) in clear in TLS is not good (as in =91not good because it
> can get you killed=92 and there is no alternative for the user =96 unless
> the user is a tech-wizard.).

They can use Tor. They need to anyway: reverse DNS lookups are not
rocket science.


[...]

>

> There are other ways how an adversary can extract the same meta-data.
> This should not deter us from fixing it in TLS. Maybe we will find a
> solution for the other problems as well (like confidential DNS).

No, the other problem is you connect to the server and ask it to show
you a page,
and learn what the server is. The sole exception is multihosting,
which is getting
less common for various reasons.



As a hacker I would love TLS to leak the host information. It would enable
me
to find out which user connects to admin.blubb.com and who connects just to

www.blubb.com (both domains hosted on same server).

Your comments are wrong in this scenario: Connecting to the server does not
help
the hacker to gain above information. Neither does reverse lookup.



TLS leaks it and there is no other way the hacker would get this
information if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the
problem.






regards,

ralf

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--bcaec52c6937ade0e004ea99dd78
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3Dus-ascii"><meta name=3D"Generator" content=3D"Microsoft Word 15 (filtere=
d medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"><div =
class=3D"WordSection1"><p class=3D"MsoNormal"><span style=3D"font-size:11.0=
pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I =
don=92t think the economic issues should be a consideration here, just what=
s the right solution.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:#1f497d">CAs are already required to include =
all the domain names in the SAN (<a href=3D"https://www.cabforum.org/Baseli=
ne_Requirements_V1.pdf">https://www.cabforum.org/Baseline_Requirements_V1.p=
df</a>) and all CAs have models for doing this.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:#1f497d">The core issue is that SNI doesn=92t=
 require shared keys across parties or cooperation of any type, using multi=
-san certificates does. This works in some cases, for example when the arbi=
trator (like a CDN) manages that cooperation but in some cases its not poss=
ible for them to.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:#1f497d">In such cases they need a dedicated =
IP or SNI.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:#1f497d">Ryan</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;=
,&quot;sans-serif&quot;;color:#1f497d">=A0</span></p>
<div><div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt=
 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;fon=
t-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span =
style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&=
quot;"> <a href=3D"mailto:tls-bounces@ietf.org">tls-bounces@ietf.org</a> [m=
ailto:<a href=3D"mailto:tls-bounces@ietf.org">tls-bounces@ietf.org</a>] <b>=
On Behalf Of </b>Yoav Nir<br>
<b>Sent:</b> Thursday, November 7, 2013 9:30 AM<br><b>To:</b> Ralf Skyper K=
aiser<br><b>Cc:</b> <a href=3D"mailto:tls@ietf.org">tls@ietf.org</a><br><b>=
Subject:</b> Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in T=
LS 1.3</span></p>
</div></div><p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal">Hi, Ralf. =
</p><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">I&=
#39;m not disagreeing with you regarding 1.3. At least in the long version =
of the handshake (which you should be able to enable in any browser, if you=
 want a little more privacy in exchange for an extra roundtrip).</p>
</div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">=
But ordinarily, the sites that can get you killed are not collocated with b=
enign sites. And even when sites are collocated, the servers demux not base=
d on the SNI parameter in the TLS handshake, but based on the Server header=
 in HTTP. The only use of the SNI parameter is for selecting the right cert=
ificate. So if you try to go to <a href=3D"https://www.gmail.com">https://w=
ww.gmail.com</a> , you get a certificate for <a href=3D"http://www.gmail.co=
m">www.gmail.com</a> , before being redirected to the same server, but this=
 time with the URI <a href=3D"https://mail.google.com">https://mail.google.=
com</a> .</p>
</div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">=
It would be much nicer if we could update HTTPS (RFC 2818) to support this =
kind of multi-homing so as to make SNI superfluous. For example, if the ser=
ver certificate could list the different domain names that it was valid for=
. Yes, I know there&#39;s an economic side to this as well. I&#39;m sure th=
e CAs could charge by alternate name if needed.</p>
</div><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">=
Yoav</p></div><div><p class=3D"MsoNormal">=A0</p></div><div><div><div><p cl=
ass=3D"MsoNormal">On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser &lt;<a hre=
f=3D"mailto:skyper@thc.org">skyper@thc.org</a>&gt; wrote:</p>
</div><p class=3D"MsoNormal"><br><br></p><blockquote style=3D"margin-top:5.=
0pt;margin-bottom:5.0pt"><div><div><p class=3D"MsoNormal">=A0</p><div><p cl=
ass=3D"MsoNormal">On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd &lt;<a href=
=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail.com</=
a>&gt; wrote:</p>
<blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><p class=3D"MsoNor=
mal">On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser &lt;<a href=3D"mail=
to:skyper@thc.org">skyper@thc.org</a>&gt; wrote:<br>
&gt;<br>&gt;<br>&gt; 1. Meta-data is important. Meta-data tells a lot about=
 a person.<br>&gt; Meta-data can get a user killed or worse. Transmitting t=
he host-name<br>&gt; (meta-data) in clear in TLS is not good (as in =91not =
good because it<br>
&gt; can get you killed=92 and there is no alternative for the user =96 unl=
ess<br>&gt; the user is a tech-wizard.).</p></div><p class=3D"MsoNormal">Th=
ey can use Tor. They need to anyway: reverse DNS lookups are not<br>rocket =
science.</p>
</blockquote><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">=A0=
<br>[...] </p></div><blockquote style=3D"border:none;border-left:solid #ccc=
ccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p =
class=3D"MsoNormal">
&gt;=A0</p><div><p class=3D"MsoNormal">&gt; There are other ways how an adv=
ersary can extract the same meta-data.<br>&gt; This should not deter us fro=
m fixing it in TLS. Maybe we will find a<br>&gt; solution for the other pro=
blems as well (like confidential DNS).</p>
</div><p class=3D"MsoNormal">No, the other problem is you connect to the se=
rver and ask it to show<br>you a page,<br>and learn what the server is. The=
 sole exception is multihosting,<br>which is getting<br>less common for var=
ious reasons.</p>
</blockquote></div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"Mso=
Normal">As a hacker I would love TLS to leak the host information. It would=
 enable me<br>to find out which user connects to <a href=3D"http://admin.bl=
ubb.com/">admin.blubb.com</a> and who connects just to</p>
</div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><a href=3D=
"http://www.blubb.com/">www.blubb.com</a> (both domains hosted on same serv=
er).</p></div><div><p class=3D"MsoNormal">Your comments are wrong in this s=
cenario: Connecting to the server does not help<br>
the hacker to gain above information. Neither does reverse lookup.</p></div=
><div><p class=3D"MsoNormal">=A0</p></div><div><p class=3D"MsoNormal">TLS l=
eaks it and there is no other way the hacker would get this information if<=
br>
TLS would not leak it. Transport Layer Kind-off-Security protocol is the pr=
oblem.</p></div><p class=3D"MsoNormal">=A0</p><div><p class=3D"MsoNormal">=
=A0</p></div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br=
>regards,<br>
<br>ralf</p></div></div><p class=3D"MsoNormal">____________________________=
___________________<br>TLS mailing list<br><a href=3D"mailto:TLS@ietf.org">=
TLS@ietf.org</a><br><a href=3D"https://www.ietf.org/mailman/listinfo/tls">h=
ttps://www.ietf.org/mailman/listinfo/tls</a></p>
</blockquote></div><p class=3D"MsoNormal">=A0</p></div></div></body></html>

--bcaec52c6937ade0e004ea99dd78--
--bcaec52c6937ade0e404ea99dd7a
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
X-Attachment-Id: f031707b12a7187a_0.1

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM3jCCA3Uw
ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD
VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT
aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC
RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS
R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O
o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9
CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU
uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF
Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq
wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB
ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6
76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s
uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW
MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY
24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggRXMIIDP6ADAgECAgsEAAAAAAEvTuExRjAN
BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ
MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw
MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M
tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h
0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l
1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM
oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA
AaOCASUwggEhMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBQ/
FdJtfC/nMZ5DCgaolGwsO8XuZTBHBgNVHSAEQDA+MDwGBFUdIAAwNDAyBggrBgEFBQcCARYmaHR0
cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0
cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUH
MAGGIWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAyFjhfKEB6SONcDttXFL4xPNfY7rhmtOR
ecivxEqlvvbYfb34RvdnmgUi1YkyCVe4HwhW7ddVnsXyv+ODXoiTH4ucF+rCu157fECCuZR+2V9V
oP8ytXF464EWmFDl/zAPj5rkZuIFldMxcGDitrr+DhYGjJla/vHp+ytWkGNnnCPWIRGg1jnEho+k
jfA78z3ROBuLQZOP2iLFIHnfbBg6kWMHipWty0zY1z6bNWPs7FW4By7Y3TiAdGGdYa5QEHGNi/2/
lfmMqIuwjHTrZptUZuiYeSC28EE45VApILuclXX7PSwynDNEj3gpXZI32hlUnfp1ETDlMt4X8bDF
bsffhTCCBQYwggPuoAMCAQICEhEhb640/F3CUxHuqwZT6bSC5TANBgkqhkiG9w0BAQUFADBUMQsw
CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2ln
biBQZXJzb25hbFNpZ24gMiBDQSAtIEcyMB4XDTEyMDEyMzE2MzY1OVoXDTE1MDEyMzE2MzY1OVow
gZQxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1OZXcgSGFtc3BoaXJlMRMwEQYDVQQHEwpQb3J0c21v
dXRoMRkwFwYDVQQKExBHbG9iYWxTaWduLCBJbmMuMRMwEQYDVQQDEwpSeWFuIEh1cnN0MSgwJgYJ
KoZIhvcNAQkBFhlyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAuAEkk72r5rBUAKG+tLpEksDgC/Z0/7PfZbTVAgH+Xzx+YzXHjCsWkLHtpojp
kUSF2spHKtaf02yO9GbXHt/K9pmzsKgxxz1YtdxsSRMlF1oGkQbXgzLuThsljRtZHIVbBlqW7LU9
GeL9JneZtQWBZ8QdtHmycjkdpVw8bBStvJ5ylfuXjI++lPAaT0OEgh+8kzBustF17Ad3AqwSq9qN
0zmIBCr/qDZ22qDLd1MTLfZ0n/Y8iLIY6n50+QHsNwlDTGrTueYORV13SLpAMHoNWEm9ZbNOalt7
FtNE93e3ULPf+zbsQoPwNnpZlSUqMvPjC0fCUhRH/2jIIzv08i4P4wIDAQABo4IBjzCCAYswDgYD
VR0PAQH/BAQDAgWgME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRw
czovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAkBgNVHREEHTAbgRlyeWFuLmh1cnN0
QGdsb2JhbHNpZ24uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25h
bHNpZ24yZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5n
bG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBRVohAn
tPy+9nlWKnFmJy1ekko84TAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG
9w0BAQUFAAOCAQEAIUIuoSz3rnZn9yAReCA8wr0SNBWmHQSn6a0pPx9Dw3muL6bC21qQNLdEmoo4
iWLcSo5TOGz3ftnIW+3o2rQ3cq2SM5g1cquHN9P8TJ4pxiqJKWANdf1Xvotnb47pbuuamrK7UERs
mwLrmeu5a6fytzjBYI1eTQtwB2C87zVOA8HOEENQWjDoOis2EqymwAUWWo366Qvbonj7L+5gyFy8
f7aAT8VjZWubyZuQ62XZ+7h3bwQhOpDMpGzizeaZhCtFCJcCoekIuVw9Kc5VZBGZYhZATCYLm3f3
he8XoO0yj1guccjhafUnTKJSTOy0wt8J0jt36wQHr/qv5xrPV8cr7DGCA4AwggN8AgEBMGowVDEL
MAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNp
Z24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMAkGBSsOAwIaBQCg
ggHrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEwNzE3NDc1
MVowIwYJKoZIhvcNAQkEMRYEFH6SoQV57e/mydJnIiwJI+/EzEW+MHkGCSsGAQQBgjcQBDFsMGow
VDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2Jh
bFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMHsGCyqGSIb3
DQEJEAILMWygajBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgG
A1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhIRIW+uNPxdwlMR7qsGU+m0
guUwgZMGCSqGSIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3
DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhow
CwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEA
DH+yFDY4vHcbcjSwkKhud13qvAe6piZYqff6bd+ObmXJ6P7iuJDCZSblIYN9K9PPaCv4Xbk0vVSz
elx0WrsVGhO5ejEtbq8aEBJ36WiKJdXCV5MgYmTBy8uCvwyT0QYpVDDXC6ae4luE6Qk7tf/otBho
F6j5ejeXfomcVq1UZ6WGX59PClWxhdEY+hMz9kGOFNTW4Pnv3sv19Ax50JvGQ2QpGytSYAc4D1Xg
/0uFQvuPIlFSaarCh/VFYvAOgDRNRj8azVWVHN5V61tzrLL3sREm40b0wkPVrvQun3UlXEuRAiuL
d7M9vXLOmE5dtbfY4u6DyuhtLttI18eOfUCZVgAAAAAAAA==
--bcaec52c6937ade0e404ea99dd7a--

From seonghan.shin@aist.go.jp  Thu Nov  7 10:36:22 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 1782521E81F1 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 10:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 F0atY+kRnoNl for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 10:36:12 -0800 (PST)
Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7436B11E81CC for <tls@ietf.org>; Thu,  7 Nov 2013 10:36:06 -0800 (PST)
Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUnvdlW0drpJPAkTQsoaT0KPgcQ2KUtjg@postini.com; Thu, 07 Nov 2013 10:36:06 PST
Received: by mail-lb0-f181.google.com with SMTP id x18so758954lbi.40 for <tls@ietf.org>; Thu, 07 Nov 2013 10:36:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UFke42bfE39c2r9RnRcocrCQUGpmoDhLbJindTCu1fI=; b=LsU5K/CDUhmbau3+ekRqEy9vSxI8W9D718xoQkBZnAqSmG5pQmpUZ47w3YSd15wZEg vAvzjjLHSQOZFh1Lt2xqo09IYzTjDh/0qTsAFaX8zyYBkJxGiz/8hdhl6EjBxClHrODR LWXSyRe5J3f3qnsaE7rF6V7YzoawkoCz1W4+0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UFke42bfE39c2r9RnRcocrCQUGpmoDhLbJindTCu1fI=; b=dVWyc3VmKhWIUoklTGoZOswM671uSkWip1gRyXrmorNqHkUsAsVOztEeT9+MbwUv6U GBPX2+gspW4hjCQgp+qrCfsluORxdcopsML+bswosuDeGqwSYiAEuI8obWMYSEWV3OOr Gp1S9Is1sPbUKX3qhtRr+VKYW4ZWSTIRddXQ9k+3O6NWqGUsFJxfYCzfMu+27ba5lbts 8OzixzflPZwR/cIQu22LbCmzbo4ykQwaJN3X/Zux+wv2ZSd9HoBAaxX2bCmTnCBlRBI/ G6oXIk2jSLMwzBGSm6bcGad/+lyQIKhQO1ex+07xvCzvTvZiO9HPg5NMdADOxoK6ARhY cI1g==
X-Gm-Message-State: ALoCoQmmlYNkRQiJ227f1AGWy9KbTZp/fo2zPr/6oXhfGW0kZ4BGe1XIpteo0dsZ7PevlWX7JlS2Yv20l5qehEKD1X4OhAA/+So+ySiQfExj4xAOks6HwlCdSAG3sPWT9roCBJxXWX5H5YCOGrLOTDImNo/mjpkbiQ==
X-Received: by 10.152.184.198 with SMTP id ew6mr7339251lac.34.1383849364503; Thu, 07 Nov 2013 10:36:04 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.184.198 with SMTP id ew6mr7339243lac.34.1383849364383; Thu, 07 Nov 2013 10:36:04 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Thu, 7 Nov 2013 10:36:04 -0800 (PST)
In-Reply-To: <CANOyrg-LzPbft+DMH8h3HatAJAwTqx6PRBG_n=3MrSfWHcMSqg@mail.gmail.com>
References: <CAEKgtqmfHpzNye_DCgyzJ7PmsGRFWCHAtjX=HOLKo0OEoEi0gQ@mail.gmail.com> <CANOyrg-LzPbft+DMH8h3HatAJAwTqx6PRBG_n=3MrSfWHcMSqg@mail.gmail.com>
Date: Fri, 8 Nov 2013 03:36:04 +0900
Message-ID: <CAEKgtqnSgdouYAmSa5DbN1sME=65wi3PpM17b2+Bybsz8PzBow@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: Fabrice Gautier <fabrice.gautier@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134693ac97c7204ea9a8950
Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= <k-kobara@aist.go.jp>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Augmented PAKE (Re: New Version Notification for draft-shin-tls-augpake-01.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: Thu, 07 Nov 2013 18:36:22 -0000

--001a1134693ac97c7204ea9a8950
Content-Type: text/plain; charset=ISO-8859-1

Hi Fabrice,

Thank you for your comment!

Section 5.1 can be used in TLS 1.3 handshake (?) as in Eric's presentation
:)

>How does the client knows which group to use ?
As you pointed out, we need to change Section 5.1 for the current tls
version.
A naive approach is to add one round exchange after ServerHello.
Any other good ideas?

Regards,
Shin


On Fri, Nov 8, 2013 at 1:20 AM, Fabrice Gautier
<fabrice.gautier@gmail.com>wrote:

> Hi,
>
> How does the client knows which group to use ?
>
> As the client would need to know the group before sending the
> ClientHello, it seems that the client needs to remember the groups
> parameters along with the password, which seems impractical.
>
>
> -- Fabrice
>
>
> On Wed, Nov 6, 2013 at 11:25 AM, SeongHan Shin <seonghan.shin@aist.go.jp>
> wrote:
> > Dear all,
> >
> > For anyone who are interested in PAKE, pls see the below I-D regarding
> > augmented PAKE.
> >
> > IMO, two reasons that SRP was published as RFC 2945 and included in IEEE
> > 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the
> > server's computation cost of SRP is a minimum.
> > (Though SRP has no provable security)
> >
> > The AugPAKE in the below I-D is provably secure and more efficient than
> > other augmented PAKEs (including SRP and AMP).
> >
> > Of course, augmented PAKE provides additional security property over
> > (balanced) PAKE.
> >
> > Best regards,
> > Shin
> >
> >
> > On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin <seonghan.shin@aist.go.jp>
> > wrote:
> >>
> >> Dear all,
> >>
> >> I submitted a new version of our I-D regarding augmented PAKE (AugPAKE)
> >> and its integration into TLS.
> >> I added some features of AugPAKE in Appendix.
> >> Any comments are welcome!
> >>
> >> Best regards,
> >> Shin
> >>
> >> ---------- Forwarded message ----------
> >> From: <internet-drafts@ietf.org>
> >> Date: Wed, Sep 4, 2013 at 6:26 PM
> >> Subject: New Version Notification for draft-shin-tls-augpake-01.txt
> >> To: Kazukuni Kobara <kobara_conf-ml@aist.go.jp>, SeongHan Shin
> >> <seonghan.shin@aist.go.jp>
> >>
> >>
> >>
> >> A new version of I-D, draft-shin-tls-augpake-01.txt
> >> has been successfully submitted by SeongHan Shin and posted to the
> >> IETF repository.
> >>
> >> Filename:        draft-shin-tls-augpake
> >> Revision:        01
> >> Title:           Augmented Password-Authenticated Key Exchange for
> >> Transport Layer Security (TLS)
> >> Creation date:   2013-09-04
> >> Group:           Individual Submission
> >> Number of pages: 19
> >> URL:
> >> http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-01.txt
> >> Status:          http://datatracker.ietf.org/doc/draft-shin-tls-augpake
> >> Htmlized:        http://tools.ietf.org/html/draft-shin-tls-augpake-01
> >> Diff:
> >> http://www.ietf.org/rfcdiff?url2=draft-shin-tls-augpake-01
> >>
> >> Abstract:
> >>    This document describes an efficient augmented password-authenticated
> >>    key exchange (AugPAKE) protocol where a user remembers a low-entropy
> >>    password and its verifier is registered in the intended server.  In
> >>    general, the user password is chosen from a small set of dictionary
> >>    whose space is within the off-line dictionary attacks.  The AugPAKE
> >>    protocol described here is secure against passive attacks, active
> >>    attacks and off-line dictionary attacks (on the obtained messages
> >>    with passive/active attacks), and also provides resistance to server
> >>    compromise (in the context of augmented PAKE security).  Based on the
> >>    AugPAKE protocol, this document also specifies a new password-only
> >>    authentication handshake for Transport Layer Security (TLS) protocol.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >>
> >> --
> >> ------------------------------------------------------------------
> >> SeongHan Shin
> >> Research Institute for Secure Systems (RISEC),
> >> National Institute of Advanced Industrial Science and Technology (AIST),
> >> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> >> Tel : +81-29-861-2670/5284
> >> Fax : +81-29-861-5285
> >> E-mail : seonghan.shin@aist.go.jp
> >> ------------------------------------------------------------------
> >
> >
> >
> >
> > --
> > ------------------------------------------------------------------
> > SeongHan Shin
> > Research Institute for Secure Systems (RISEC),
> > National Institute of Advanced Industrial Science and Technology (AIST),
> > Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> > Tel : +81-29-861-2670/5284
> > Fax : +81-29-861-5285
> > E-mail : seonghan.shin@aist.go.jp
> > ------------------------------------------------------------------
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a1134693ac97c7204ea9a8950
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Fabrice,<br><br></div><div>Thank you for your comm=
ent!<br><br></div>Section 5.1 can be used in TLS 1.3 handshake (?) as in Er=
ic&#39;s presentation :)<br><br>&gt;How does the client knows which group t=
o use ?<br>
<div><div class=3D"gmail_extra">As you pointed out, we need to change Secti=
on 5.1 for the current tls version.<br></div><div class=3D"gmail_extra">A n=
aive approach is to add one round exchange after ServerHello.<br></div><div=
 class=3D"gmail_extra">
Any other good ideas?<br><br></div><div class=3D"gmail_extra">Regards,<br><=
/div><div class=3D"gmail_extra">Shin<br></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Fri, Nov 8, 2013 at 1:20 AM, Fabrice Ga=
utier <span dir=3D"ltr">&lt;<a href=3D"mailto:fabrice.gautier@gmail.com" ta=
rget=3D"_blank">fabrice.gautier@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
How does the client knows which group to use ?<br>
<br>
As the client would need to know the group before sending the<br>
ClientHello, it seems that the client needs to remember the groups<br>
parameters along with the password, which seems impractical.<br>
<br>
<br>
-- Fabrice<br>
<div><div class=3D"h5"><br>
<br>
On Wed, Nov 6, 2013 at 11:25 AM, SeongHan Shin &lt;<a href=3D"mailto:seongh=
an.shin@aist.go.jp">seonghan.shin@aist.go.jp</a>&gt; wrote:<br>
&gt; Dear all,<br>
&gt;<br>
&gt; For anyone who are interested in PAKE, pls see the below I-D regarding=
<br>
&gt; augmented PAKE.<br>
&gt;<br>
&gt; IMO, two reasons that SRP was published as RFC 2945 and included in IE=
EE<br>
&gt; 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the<=
br>
&gt; server&#39;s computation cost of SRP is a minimum.<br>
&gt; (Though SRP has no provable security)<br>
&gt;<br>
&gt; The AugPAKE in the below I-D is provably secure and more efficient tha=
n<br>
&gt; other augmented PAKEs (including SRP and AMP).<br>
&gt;<br>
&gt; Of course, augmented PAKE provides additional security property over<b=
r>
&gt; (balanced) PAKE.<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Shin<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin &lt;<a href=3D"mailto:se=
onghan.shin@aist.go.jp">seonghan.shin@aist.go.jp</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Dear all,<br>
&gt;&gt;<br>
&gt;&gt; I submitted a new version of our I-D regarding augmented PAKE (Aug=
PAKE)<br>
&gt;&gt; and its integration into TLS.<br>
&gt;&gt; I added some features of AugPAKE in Appendix.<br>
&gt;&gt; Any comments are welcome!<br>
&gt;&gt;<br>
&gt;&gt; Best regards,<br>
&gt;&gt; Shin<br>
&gt;&gt;<br>
&gt;&gt; ---------- Forwarded message ----------<br>
&gt;&gt; From: &lt;<a href=3D"mailto:internet-drafts@ietf.org">internet-dra=
fts@ietf.org</a>&gt;<br>
&gt;&gt; Date: Wed, Sep 4, 2013 at 6:26 PM<br>
&gt;&gt; Subject: New Version Notification for draft-shin-tls-augpake-01.tx=
t<br>
&gt;&gt; To: Kazukuni Kobara &lt;<a href=3D"mailto:kobara_conf-ml@aist.go.j=
p">kobara_conf-ml@aist.go.jp</a>&gt;, SeongHan Shin<br>
&gt;&gt; &lt;<a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@aist=
.go.jp</a>&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; A new version of I-D, draft-shin-tls-augpake-01.txt<br>
&gt;&gt; has been successfully submitted by SeongHan Shin and posted to the=
<br>
&gt;&gt; IETF repository.<br>
&gt;&gt;<br>
&gt;&gt; Filename: =A0 =A0 =A0 =A0draft-shin-tls-augpake<br>
&gt;&gt; Revision: =A0 =A0 =A0 =A001<br>
&gt;&gt; Title: =A0 =A0 =A0 =A0 =A0 Augmented Password-Authenticated Key Ex=
change for<br>
&gt;&gt; Transport Layer Security (TLS)<br>
&gt;&gt; Creation date: =A0 2013-09-04<br>
&gt;&gt; Group: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>
&gt;&gt; Number of pages: 19<br>
&gt;&gt; URL:<br>
&gt;&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-shin-tls-augp=
ake-01.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-shi=
n-tls-augpake-01.txt</a><br>
&gt;&gt; Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/=
doc/draft-shin-tls-augpake" target=3D"_blank">http://datatracker.ietf.org/d=
oc/draft-shin-tls-augpake</a><br>
&gt;&gt; Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/dra=
ft-shin-tls-augpake-01" target=3D"_blank">http://tools.ietf.org/html/draft-=
shin-tls-augpake-01</a><br>
&gt;&gt; Diff:<br>
&gt;&gt; <a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-shin-tls-augpa=
ke-01" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-shin-tls-=
augpake-01</a><br>
&gt;&gt;<br>
&gt;&gt; Abstract:<br>
&gt;&gt; =A0 =A0This document describes an efficient augmented password-aut=
henticated<br>
&gt;&gt; =A0 =A0key exchange (AugPAKE) protocol where a user remembers a lo=
w-entropy<br>
&gt;&gt; =A0 =A0password and its verifier is registered in the intended ser=
ver. =A0In<br>
&gt;&gt; =A0 =A0general, the user password is chosen from a small set of di=
ctionary<br>
&gt;&gt; =A0 =A0whose space is within the off-line dictionary attacks. =A0T=
he AugPAKE<br>
&gt;&gt; =A0 =A0protocol described here is secure against passive attacks, =
active<br>
&gt;&gt; =A0 =A0attacks and off-line dictionary attacks (on the obtained me=
ssages<br>
&gt;&gt; =A0 =A0with passive/active attacks), and also provides resistance =
to server<br>
&gt;&gt; =A0 =A0compromise (in the context of augmented PAKE security). =A0=
Based on the<br>
&gt;&gt; =A0 =A0AugPAKE protocol, this document also specifies a new passwo=
rd-only<br>
&gt;&gt; =A0 =A0authentication handshake for Transport Layer Security (TLS)=
 protocol.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Please note that it may take a couple of minutes from the time of<=
br>
&gt;&gt; submission<br>
&gt;&gt; until the htmlized version and diff are available at <a href=3D"ht=
tp://tools.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
&gt;&gt;<br>
&gt;&gt; The IETF Secretariat<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; ------------------------------------------------------------------=
<br>
&gt;&gt; SeongHan Shin<br>
&gt;&gt; Research Institute for Secure Systems (RISEC),<br>
&gt;&gt; National Institute of Advanced Industrial Science and Technology (=
AIST),<br>
&gt;&gt; Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br=
>
&gt;&gt; Tel : +81-29-861-2670/5284<br>
&gt;&gt; Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+81298615285">+81=
-29-861-5285</a><br>
&gt;&gt; E-mail : <a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin=
@aist.go.jp</a><br>
&gt;&gt; ------------------------------------------------------------------=
<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; ------------------------------------------------------------------<br>
&gt; SeongHan Shin<br>
&gt; Research Institute for Secure Systems (RISEC),<br>
&gt; National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
&gt; Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>
&gt; Tel : +81-29-861-2670/5284<br>
&gt; Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+81298615285">+81-29-=
861-5285</a><br>
&gt; E-mail : <a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@ais=
t.go.jp</a><br>
&gt; ------------------------------------------------------------------<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; TLS mailing list<br>
&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margin:0m=
m 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>
SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div>

--001a1134693ac97c7204ea9a8950--

From mrex@sap.com  Thu Nov  7 11:02:30 2013
Return-Path: <mrex@sap.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 1311821E814E for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.122
X-Spam-Level: 
X-Spam-Status: No, score=-10.122 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 FZasUZSEqkBd for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:02:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E721E8172 for <tls@ietf.org>; Thu,  7 Nov 2013 11:00:07 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rA7IxvFK018930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 19:59:57 +0100 (MET)
In-Reply-To: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Thu, 7 Nov 2013 19:59:57 +0100 (CET)
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: <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 07 Nov 2013 19:02:30 -0000

Ralf Skyper Kaiser wrote:
> 
> Some thoughts why SNI (host name) should be
> transmitted encrypted and not in clear.

But you are aware that there is no such thing as a
"confidential DNS lookup" (confidential towards whom anyways),
so that in general, what your browser is connecting will be
directly preceded by a cleartext DNS lookup with that very name...

(Not revealing the "next protocol" or client certs/identities
 is a different issue.)

-Martin

From dkg@fifthhorseman.net  Thu Nov  7 11:08:00 2013
Return-Path: <dkg@fifthhorseman.net>
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 9CC0611E81B3 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 aog+g4zUsrTR for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:07:55 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB7411E81BD for <tls@ietf.org>; Thu,  7 Nov 2013 11:07:54 -0800 (PST)
Received: from [192.168.13.154] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 6774FF984; Thu,  7 Nov 2013 14:07:50 -0500 (EST)
Message-ID: <527BE507.6090507@fifthhorseman.net>
Date: Thu, 07 Nov 2013 14:07:51 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: mrex@sap.com, Ralf Skyper Kaiser <skyper@thc.org>
References: <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp>
In-Reply-To: <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:08:00 -0000

On 11/07/2013 01:59 PM, Martin Rex wrote:

> But you are aware that there is no such thing as a
> "confidential DNS lookup" (confidential towards whom anyways),
> so that in general, what your browser is connecting will be
> directly preceded by a cleartext DNS lookup with that very name...

Sure, but that is a bug in DNS, not a bug in TLS, and there are 
proposals (however farfetched) to work around that, like DNSCurve [0]. 
But fixing DNS leakage is out-of-scope for this working group.

Fixing TLS is in-scope, though, and TLS shouldn't leak information just 
because other related protocols also leak information.

Putting SNI info in an encrypted handshake would make that information 
unavailable to passive attackers.  Despite still being vulnerable to 
active attackers (possibly at the cost of a connection failure) this is 
a win, and if we can offer this protection in the protocol, we should.

	--dkg

[0] http://dnscurve.org/

From skyper@thc.org  Thu Nov  7 11:36:29 2013
Return-Path: <skyper@thc.org>
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 24A0921E8181 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 lgVGndZzYC8P for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:36:23 -0800 (PST)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7683C21E814E for <tls@ietf.org>; Thu,  7 Nov 2013 11:36:18 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id aq17so1602351iec.38 for <tls@ietf.org>; Thu, 07 Nov 2013 11:36:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kW8MO6n2pvtfTOOe3f0OK5FS8UT0gmBkSC9NOt0L0w8=; b=K4cuOcBqM5MMO37bJqVO4LgdD0p+nYQKoyLYJ6ms3GgPqof7xTZynDLSJJD/aHI0uY t/nO2Qx+2wScuCGsWFhuD4PtxQXfcckB8jng6zl0jWx9v2aDDxmDN3jm2APjNbHAlLww AQf2aNEt/pEawSKZmN8zjlvtkUHLeZ9pabcsk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kW8MO6n2pvtfTOOe3f0OK5FS8UT0gmBkSC9NOt0L0w8=; b=gWDUL21yfz5rxsvxGL4vmlwL4KPCG85A3sHtiGwSQYbuu2/atr/sLmm1fq9m1bUESq /XkY3EtPwARbahxzFLZgHUhawecT47q+kONn4Wn4DsvXHgPOHcIWwUhssjOYE3vSTg62 NNTuUwpPtEA426FamW/GPfrwzCv2eES3f+W0377EifuJs5k57wrxK3KMKiE2rfQgwJma +KkgnF3Gn0jMBPf1jW5aCrgmT29bQlFzCjnCcDSxqDDTbzPPrUyIu5y3FYxRFyS/KjBh bT4gZ1KzBYdEMAMX8AYA2GEbiTMRq3uo1ozss1rVJtEtOy4+knwSmRAZdIOUyJFfAPv+ Gk1A==
X-Gm-Message-State: ALoCoQkl9ZmTQOWrtN/OtaD4FGUPzINQMTncr/hIUnfYs8Ab9hu46lboLQohQVCBZtj+3RoSeJn7
MIME-Version: 1.0
X-Received: by 10.50.106.20 with SMTP id gq20mr3327367igb.36.1383852977175; Thu, 07 Nov 2013 11:36:17 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Thu, 7 Nov 2013 11:36:17 -0800 (PST)
X-Originating-IP: [70.102.70.79]
In-Reply-To: <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp>
Date: Thu, 7 Nov 2013 19:36:17 +0000
Message-ID: <CA+BZK2qvGS-UewoqGzn7YF15tk6JCOvytie7F=ankjia-W+L7Q@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bea343420f27304ea9b6142
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:36:30 -0000

--047d7bea343420f27304ea9b6142
Content-Type: text/plain; charset=ISO-8859-1

Hi Martin,

(see also my full email further below where I mention DNS and why the
shortfall of current DNS should not stop us from fixing TLS - because
otherwise the DNS guys say there is no need to fix DNS because SNI in TLS
is cleartext as well...we have to start somewhere.......Please also see
comment on how just having DNS leaking this information raises the cost for
surveillance and in some cases makes it impractical if not impossible -
that's the goal.)

regards,

ralf



On Thu, Nov 7, 2013 at 6:59 PM, Martin Rex <mrex@sap.com> wrote:

> Ralf Skyper Kaiser wrote:
> >
> > Some thoughts why SNI (host name) should be
> > transmitted encrypted and not in clear.
>
> But you are aware that there is no such thing as a
> "confidential DNS lookup" (confidential towards whom anyways),
> so that in general, what your browser is connecting will be
> directly preceded by a cleartext DNS lookup with that very name...
>
> (Not revealing the "next protocol" or client certs/identities
>  is a different issue.)
>
> -Martin
>

--047d7bea343420f27304ea9b6142
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Martin,<br><br></div>(see also my full email furth=
er below where I mention DNS and why the shortfall of current DNS should no=
t stop us from fixing TLS - because otherwise the DNS guys say there is no =
need to fix DNS because SNI in TLS is cleartext as well...we have to start =
somewhere.......Please also see comment on how just having DNS leaking this=
 information raises the cost for surveillance and in some cases makes it im=
practical if not impossible - that&#39;s the goal.)<br>
<br>regards,<br><br>ralf<br><br></div><div class=3D"gmail_extra"><br><br><d=
iv class=3D"gmail_quote">On Thu, Nov 7, 2013 at 6:59 PM, Martin Rex <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ralf Skyper Kaiser wrote:<br>
&gt;<br>
&gt; Some thoughts why SNI (host name) should be<br>
<div class=3D"im">&gt; transmitted encrypted and not in clear.<br>
<br>
</div>But you are aware that there is no such thing as a<br>
&quot;confidential DNS lookup&quot; (confidential towards whom anyways),<br=
>
so that in general, what your browser is connecting will be<br>
directly preceded by a cleartext DNS lookup with that very name...<br>
<br>
(Not revealing the &quot;next protocol&quot; or client certs/identities<br>
=A0is a different issue.)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span></blockquote></div><br></div>

--047d7bea343420f27304ea9b6142--

From ynir@checkpoint.com  Thu Nov  7 11:47:13 2013
Return-Path: <ynir@checkpoint.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 DC58F11E8188 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.525
X-Spam-Level: 
X-Spam-Status: No, score=-10.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 R3CVNO0HnhUH for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:47:09 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 56BC011E81B3 for <tls@ietf.org>; Thu,  7 Nov 2013 11:46:46 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7JkhcE002078; Thu, 7 Nov 2013 21:46:43 +0200
X-CheckPoint: {527BEC9E-2-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 21:46:43 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Ryan Hurst <ryan.hurst@globalsign.com>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAIAABPCAgAAhNIA=
Date: Thu, 7 Nov 2013 19:46:42 +0000
Message-ID: <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com> <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com>
In-Reply-To: <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.53]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_68078EDDF9244AA5A605E7B688509EE3checkpointcom_"
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:47:14 -0000

--_000_68078EDDF9244AA5A605E7B688509EE3checkpointcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

IMO, if both sites are either collocated on the same machine, or hosted beh=
ind the same SSL accelerator, they already share enough that multi-SAN is n=
ot a bad thing.

With SNI is it currently stands, the site you are looking for is sent in th=
e clear. If we keep the choose-certificate functionality in 1.3, we still l=
eave it exposed in either the SNI or in the certificate that the server sen=
ds. A generic certificate is the only one that hides what the client is bro=
wsing.


On Nov 7, 2013, at 9:47 AM, Ryan Hurst <ryan.hurst@globalsign.com<mailto:ry=
an.hurst@globalsign.com>> wrote:

I don=92t think the economic issues should be a consideration here, just wh=
ats the right solution.

CAs are already required to include all the domain names in the SAN (https:=
//www.cabforum.org/Baseline_Requirements_V1.pdf) and all CAs have models fo=
r doing this.

The core issue is that SNI doesn=92t require shared keys across parties or =
cooperation of any type, using multi-san certificates does. This works in s=
ome cases, for example when the arbitrator (like a CDN) manages that cooper=
ation but in some cases its not possible for them to.

In such cases they need a dedicated IP or SNI.

Ryan


From: tls-bounces@ietf.org<mailto:tls-bounces@ietf.org> [mailto:tls-bounces=
@ietf.org<mailto:tls-bounces@ietf.org>] On Behalf Of Yoav Nir
Sent: Thursday, November 7, 2013 9:30 AM
To: Ralf Skyper Kaiser
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1=
.3

Hi, Ralf.

I'm not disagreeing with you regarding 1.3. At least in the long version of=
 the handshake (which you should be able to enable in any browser, if you w=
ant a little more privacy in exchange for an extra roundtrip).

But ordinarily, the sites that can get you killed are not collocated with b=
enign sites. And even when sites are collocated, the servers demux not base=
d on the SNI parameter in the TLS handshake, but based on the Server header=
 in HTTP. The only use of the SNI parameter is for selecting the right cert=
ificate. So if you try to go tohttps://www.gmail.com , you get a certificat=
e for www.gmail.com<http://www.gmail.com> , before being redirected to the =
same server, but this time with the URI https://mail.google.com .

It would be much nicer if we could update HTTPS (RFC 2818) to support this =
kind of multi-homing so as to make SNI superfluous. For example, if the ser=
ver certificate could list the different domain names that it was valid for=
. Yes, I know there's an economic side to this as well. I'm sure the CAs co=
uld charge by alternate name if needed.

Yoav

On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:skype=
r@thc.org>> wrote:



On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd <watsonbladd@gmail.com<mailto:w=
atsonbladd@gmail.com>> wrote:
On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:s=
kyper@thc.org>> wrote:
>
>
> 1. Meta-data is important. Meta-data tells a lot about a person.
> Meta-data can get a user killed or worse. Transmitting the host-name
> (meta-data) in clear in TLS is not good (as in =91not good because it
> can get you killed=92 and there is no alternative for the user =96 unless
> the user is a tech-wizard.).
They can use Tor. They need to anyway: reverse DNS lookups are not
rocket science.

[...]
>
> There are other ways how an adversary can extract the same meta-data.
> This should not deter us from fixing it in TLS. Maybe we will find a
> solution for the other problems as well (like confidential DNS).
No, the other problem is you connect to the server and ask it to show
you a page,
and learn what the server is. The sole exception is multihosting,
which is getting
less common for various reasons.

As a hacker I would love TLS to leak the host information. It would enable =
me
to find out which user connects to admin.blubb.com<http://admin.blubb.com/>=
 and who connects just to
www.blubb.com<http://www.blubb.com/> (both domains hosted on same server).
Your comments are wrong in this scenario: Connecting to the server does not=
 help
the hacker to gain above information. Neither does reverse lookup.

TLS leaks it and there is no other way the hacker would get this informatio=
n if
TLS would not leak it. Transport Layer Kind-off-Security protocol is the pr=
oblem.



regards,

ralf
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls



Email secured by Check Point

<smime.p7s>


--_000_68078EDDF9244AA5A605E7B688509EE3checkpointcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <DE9E927036A20C4793CE18EE88426051@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<base href=3D"x-msg://705/">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
IMO, if both sites are either collocated on the same machine, or hosted beh=
ind the same SSL accelerator, they already share enough that multi-SAN is n=
ot a bad thing.
<div><br>
</div>
<div>With SNI is it currently stands, the site you are looking for is sent =
in the clear. If we keep the choose-certificate functionality in 1.3, we st=
ill leave it exposed in either the SNI or in the certificate that the serve=
r sends. A generic certificate is
 the only one that hides what the client is browsing.</div>
<div><br>
<div><br>
<div>
<div>On Nov 7, 2013, at 9:47 AM, Ryan Hurst &lt;<a href=3D"mailto:ryan.hurs=
t@globalsign.com">ryan.hurst@globalsign.com</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"font-family: Ta=
homa; font-size: medium; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-=
align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webki=
t-text-stroke-width: 0px; ">
<div class=3D"WordSection1" style=3D"page: WordSection1; ">
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">I don=92t think the economic issues should be a considera=
tion here, just whats the right solution.</span></div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></p>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">CAs are already required to include all the domain names =
in the SAN (<a href=3D"https://www.cabforum.org/Baseline_Requirements_V1.pd=
f" style=3D"color: purple; text-decoration: underline; ">https://www.cabfor=
um.org/Baseline_Requirements_V1.pdf</a>)
 and all CAs have models for doing this.</span></div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></p>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">The core issue is that SNI doesn=92t require shared keys =
across parties or cooperation of any type, using multi-san certificates doe=
s. This works in some cases, for example
 when the arbitrator (like a CDN) manages that cooperation but in some case=
s its not possible for them to.</span></div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></p>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">In such cases they need a dedicated IP or SNI.</span></di=
v>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></p>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">Ryan</span></div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></p>
<div>
<div style=3D"border-style: solid none none; border-top-width: 1pt; border-=
top-color: rgb(225, 225, 225); padding: 3pt 0in 0in; ">
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<b><span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; ">From=
:</span></b><span style=3D"font-size: 11pt; font-family: Calibri, sans-seri=
f; "><span class=3D"Apple-converted-space">&nbsp;</span><a href=3D"mailto:t=
ls-bounces@ietf.org" style=3D"color: purple; text-decoration: underline; ">=
tls-bounces@ietf.org</a><span class=3D"Apple-converted-space">&nbsp;</span>=
[mailto:<a href=3D"mailto:tls-bounces@ietf.org" style=3D"color: purple; tex=
t-decoration: underline; ">tls-bounces@ietf.org</a>]<span class=3D"Apple-co=
nverted-space">&nbsp;</span><b>On
 Behalf Of<span class=3D"Apple-converted-space">&nbsp;</span></b>Yoav Nir<b=
r>
<b>Sent:</b><span class=3D"Apple-converted-space">&nbsp;</span>Thursday, No=
vember 7, 2013 9:30 AM<br>
<b>To:</b><span class=3D"Apple-converted-space">&nbsp;</span>Ralf Skyper Ka=
iser<br>
<b>Cc:</b><span class=3D"Apple-converted-space">&nbsp;</span><a href=3D"mai=
lto:tls@ietf.org" style=3D"color: purple; text-decoration: underline; ">tls=
@ietf.org</a><br>
<b>Subject:</b><span class=3D"Apple-converted-space">&nbsp;</span>Re: [TLS]=
 Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3</span></div>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
Hi, Ralf.</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
I'm not disagreeing with you regarding 1.3. At least in the long version of=
 the handshake (which you should be able to enable in any browser, if you w=
ant a little more privacy in exchange for an extra roundtrip).</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
But ordinarily, the sites that can get you killed are not collocated with b=
enign sites. And even when sites are collocated, the servers demux not base=
d on the SNI parameter in the TLS handshake, but based on the Server header=
 in HTTP. The only use of the SNI
 parameter is for selecting the right certificate. So if you try to go to<a=
 href=3D"https://www.gmail.com" style=3D"color: purple; text-decoration: un=
derline; ">https://www.gmail.com</a><span class=3D"Apple-converted-space">&=
nbsp;</span>, you get a certificate for<span class=3D"Apple-converted-space=
">&nbsp;</span><a href=3D"http://www.gmail.com" style=3D"color: purple; tex=
t-decoration: underline; ">www.gmail.com</a><span class=3D"Apple-converted-=
space">&nbsp;</span>,
 before being redirected to the same server, but this time with the URI<spa=
n class=3D"Apple-converted-space">&nbsp;</span><a href=3D"https://mail.goog=
le.com" style=3D"color: purple; text-decoration: underline; ">https://mail.=
google.com</a><span class=3D"Apple-converted-space">&nbsp;</span>.</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
It would be much nicer if we could update HTTPS (RFC 2818) to support this =
kind of multi-homing so as to make SNI superfluous. For example, if the ser=
ver certificate could list the different domain names that it was valid for=
. Yes, I know there's an economic
 side to this as well. I'm sure the CAs could charge by alternate name if n=
eeded.</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
Yoav</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
On Nov 7, 2013, at 9:03 AM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyper=
@thc.org" style=3D"color: purple; text-decoration: underline; ">skyper@thc.=
org</a>&gt; wrote:</div>
</div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<br>
<br>
</div>
<blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
On Thu, Nov 7, 2013 at 4:39 PM, Watson Ladd &lt;<a href=3D"mailto:watsonbla=
dd@gmail.com" target=3D"_blank" style=3D"color: purple; text-decoration: un=
derline; ">watsonbladd@gmail.com</a>&gt; wrote:</div>
<blockquote style=3D"border-style: none none none solid; border-left-width:=
 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; marg=
in-left: 4.8pt; margin-right: 0in; ">
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
On Thu, Nov 7, 2013 at 8:32 AM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:sk=
yper@thc.org" style=3D"color: purple; text-decoration: underline; ">skyper@=
thc.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; 1. Meta-data is important. Meta-data tells a lot about a person.<br>
&gt; Meta-data can get a user killed or worse. Transmitting the host-name<b=
r>
&gt; (meta-data) in clear in TLS is not good (as in =91not good because it<=
br>
&gt; can get you killed=92 and there is no alternative for the user =96 unl=
ess<br>
&gt; the user is a tech-wizard.).</div>
</div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
They can use Tor. They need to anyway: reverse DNS lookups are not<br>
rocket science.</div>
</blockquote>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 12pt; font-size: 12pt; font=
-family: 'Times New Roman', serif; ">
&nbsp;<br>
[...]</p>
</div>
<blockquote style=3D"border-style: none none none solid; border-left-width:=
 1pt; border-left-color: rgb(204, 204, 204); padding: 0in 0in 0in 6pt; marg=
in-left: 4.8pt; margin-right: 0in; ">
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
&gt;&nbsp;</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
&gt; There are other ways how an adversary can extract the same meta-data.<=
br>
&gt; This should not deter us from fixing it in TLS. Maybe we will find a<b=
r>
&gt; solution for the other problems as well (like confidential DNS).</div>
</div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
No, the other problem is you connect to the server and ask it to show<br>
you a page,<br>
and learn what the server is. The sole exception is multihosting,<br>
which is getting<br>
less common for various reasons.</div>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
As a hacker I would love TLS to leak the host information. It would enable =
me<br>
to find out which user connects to<span class=3D"Apple-converted-space">&nb=
sp;</span><a href=3D"http://admin.blubb.com/" style=3D"color: purple; text-=
decoration: underline; ">admin.blubb.com</a><span class=3D"Apple-converted-=
space">&nbsp;</span>and who connects just to</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 12pt; font-size: 12pt; font=
-family: 'Times New Roman', serif; ">
<a href=3D"http://www.blubb.com/" style=3D"color: purple; text-decoration: =
underline; ">www.blubb.com</a><span class=3D"Apple-converted-space">&nbsp;<=
/span>(both domains hosted on same server).</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
Your comments are wrong in this scenario: Connecting to the server does not=
 help<br>
the hacker to gain above information. Neither does reverse lookup.</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
TLS leaks it and there is no other way the hacker would get this informatio=
n if<br>
TLS would not leak it. Transport Layer Kind-off-Security protocol is the pr=
oblem.</div>
</div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 12pt; font-size: 12pt; font=
-family: 'Times New Roman', serif; ">
<br>
regards,<br>
<br>
ralf</p>
</div>
</div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" style=3D"color: purple; text-decoration: un=
derline; ">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" style=3D"color: purpl=
e; text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/tls<=
/a></div>
</blockquote>
</div>
<p class=3D"MsoNormal" style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; =
font-family: 'Times New Roman', serif; ">
&nbsp;</p>
</div>
</div>
<br>
<br>
Email secured by Check Point<span class=3D"Apple-converted-space">&nbsp;</s=
pan><br>
<br>
<span>&lt;smime.p7s&gt;</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>

--_000_68078EDDF9244AA5A605E7B688509EE3checkpointcom_--

From ynir@checkpoint.com  Thu Nov  7 11:49:21 2013
Return-Path: <ynir@checkpoint.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 F128B11E81B3 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:49:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.526
X-Spam-Level: 
X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 diDlsXWJQKnD for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:49:15 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CC86E11E8164 for <tls@ietf.org>; Thu,  7 Nov 2013 11:49:04 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7Jmw9W002620; Thu, 7 Nov 2013 21:48:58 +0200
X-CheckPoint: {527BED25-3-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 21:48:58 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "Salz, Rich" <rsalz@akamai.com>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAIAAI6dwgAADH4A=
Date: Thu, 7 Nov 2013 19:48:58 +0000
Message-ID: <708C4C0F-2915-4847-A823-E4CF74B8B367@checkpoint.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14F@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF14F@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.53]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_708C4C0F29154847A823E4CF74B8B367checkpointcom_"
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:49:21 -0000

--_000_708C4C0F29154847A823E4CF74B8B367checkpointcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On Nov 7, 2013, at 9:39 AM, "Salz, Rich" <rsalz@akamai.com<mailto:rsalz@aka=
mai.com>> wrote:

>  For example, if the server certificate could list the different domain n=
ames that it was valid for.

Like subjectAltName?  But unlike SNI, that requires the hosted parties to c=
ooperate in getting the certificate. SNI does not.

Yes, but at the cost that the domain name is exposed in the clear. Both in =
the SNI and in the certificate.

Yoav



--_000_708C4C0F29154847A823E4CF74B8B367checkpointcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <2C3806C743B7904EA25D95824B6A82FA@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<base href=3D"x-msg://707/">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
<br>
<div>
<div>On Nov 7, 2013, at 9:39 AM, &quot;Salz, Rich&quot; &lt;<a href=3D"mail=
to:rsalz@akamai.com">rsalz@akamai.com</a>&gt; wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"font-family: Ta=
homa; font-size: medium; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-=
align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: n=
ormal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webki=
t-text-stroke-width: 0px; ">
<div class=3D"WordSection1" style=3D"page: WordSection1; ">
<div style=3D"margin: 0in 0in 0.0001pt 0.5in; font-size: 12pt; font-family:=
 'Times New Roman', serif; text-indent: -0.25in; ">
<span style=3D"font-size: 11pt; font-family: Wingdings; color: rgb(31, 73, =
125); "><span>=D8<span style=3D"font-style: normal; font-variant: normal; f=
ont-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Time=
s New Roman'; ">&nbsp;<span class=3D"Apple-converted-space">&nbsp;</span></=
span></span></span>For
 example, if the server certificate could list the different domain names t=
hat it was valid for.<span style=3D"font-size: 11pt; font-family: Calibri, =
sans-serif; color: rgb(31, 73, 125); "><o:p></o:p></span></div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">&nbsp;</span></div>
<div style=3D"margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Time=
s New Roman', serif; ">
<span style=3D"font-size: 11pt; font-family: Calibri, sans-serif; color: rg=
b(31, 73, 125); ">Like subjectAltName?&nbsp; But unlike SNI, that requires =
the hosted parties to cooperate in getting the certificate. SNI does not.<o=
:p></o:p></span></div>
</div>
</div>
</blockquote>
<br>
</div>
<div>Yes, but at the cost that the domain name is exposed in the clear. Bot=
h in the SNI and in the certificate.</div>
<div><br>
</div>
<div>Yoav</div>
<div><br>
</div>
<br>
</body>
</html>

--_000_708C4C0F29154847A823E4CF74B8B367checkpointcom_--

From luto@amacapital.net  Thu Nov  7 11:52:13 2013
Return-Path: <luto@amacapital.net>
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 5C2F811E8188 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5l1tMyNI5FLv for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:52:01 -0800 (PST)
Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 57F1B11E822F for <tls@ietf.org>; Thu,  7 Nov 2013 11:52:01 -0800 (PST)
Received: by mail-pb0-f47.google.com with SMTP id rq13so1064120pbb.6 for <tls@ietf.org>; Thu, 07 Nov 2013 11:52:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=QR6gPkBvhjZT6aPBJsrMLYf7sO6V+gHzEzUDrdhzxeE=; b=A6IR5onZKwO2AhPW8WcUaf4szLbGCKWQxSxjew5G+9DKPwr/THG9I0Sl/B6cIu6HnN uusXQtCQXGN1dKAEQN/SXiYj1Um1zrrK6OerAxFwTXgDQengeaXg15VEr4nuH+j9B8mN pfQESdtXDuzCWCkJ9AxEJSzgW6DMwjjFAawum2s8wHDuVy/LLhCDe4X6FCz22gsrrUka vLmCTNlxKmsZxU3dZbLmE6lnwz2xLAlSpMi5sTRKGvGfCL+RGjVXACefHczrK5bq0klG TtR8Np9YMzqA3RLU8INLC54ccql4pkPesQEkh7GPWqejOxOU1nhpH8V+VEqJ7cqFgwwF tQhQ==
X-Gm-Message-State: ALoCoQk5r7SJDT0i0ME8FWFrhwjaMnbcO47mK6z+l9GQnjl5RPxHSiCL8HQ1R61I+jqFz2BwTfj6
X-Received: by 10.66.221.199 with SMTP id qg7mr11472847pac.13.1383853920820; Thu, 07 Nov 2013 11:52:00 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id ed3sm6947409pbc.6.2013.11.07.11.51.59 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 11:52:00 -0800 (PST)
Message-ID: <527BEF5E.8070704@amacapital.net>
Date: Thu, 07 Nov 2013 11:51:58 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [TLS] TLS 1.3 certificate delegation?
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: Thu, 07 Nov 2013 19:52:13 -0000

I'm not sure that this is in scope for TLS 1.3, but if it were part of
TLS 1.3 then servers could send different certificates to clients
depending on TLS version.

Currently, if an organization wants to use a wildcard certificate, every
web server must possess (or at least be able to use) the associated
private key.  Similarly, if an organization wants to use short-lived
keys, it must ask its CA to sign a large number of short-lived certificates.

In principle, a server could present a certificate chain like this:

1. trusted root
    |
    V
2. intermediate CA  (owned by outside authority)
    |
    V
3. non-CA (wildcard?) certificate  (owned by the server's operator)
    |
    V
4. short-lived or domain-specific certificate

Clients will reject this chain as invalid (it contains an intermediate
(#3) that isn't a CA).

It would be a departure from established practice, but, if certificate
#3 permits signing, then there's nothing insecure about this certificate
chain.  Whoever has the private key associated with certificate #3 is
permitted to host the domains described by the common name and
subjectAltNames of #3 (and subdomains if it's a wildcard), so, if
they're willing to delegate authority to certificate #4, they should be
able to.

In principle, current standards allow something like this by using a CA
certificate with a name constraint as #3, but this is completely broken
in practice.

If TLS 1.3 were to change the validation rules to allow this type of
certificate chain, then there would be several benefits:

 - Organizations could deploy ECDSA without involving the certificate
issuers.

 - Organizations could buy a single wildcard certificate and then
delegate authority to their servers however they like.

 - Servers could generate very short-lived delegated certificates to get
a good approximation of PFS without using DHE/ECDHE.  (Google's QUIC
does something very much like this.  They use fixed ECDH "certificates"
called "server configs" that contain a public curve25519 parameter,
which results in a much less computation than any TLS 1.2 key exchange
mode.)

Backwards compatibility is sometimes possible.  For example, a server
could present its real certificate to old clients (and use DHE) but
present a temporary delegated certificate to TLS 1.3 clients.


--Andy

From schoen@eff.org  Thu Nov  7 11:54:55 2013
Return-Path: <schoen@eff.org>
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 0B5C611E828D for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 aCIJPYVxgKU9 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:54:50 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [64.147.188.12]) by ietfa.amsl.com (Postfix) with ESMTP id BB0CF11E815C for <tls@ietf.org>; Thu,  7 Nov 2013 11:54:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2;  h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=OpfVqROFNWYIrev6e3recDNhMWNBmrQU91D2uaTjyJU=;  b=ob+mXZHRF+GER575Gvr4KeHo7i6IoFC7G68U0wcBe4t0BZwlS4DrA5/ZCSBvyyAVdJxkQFtPphylvD6cM3PPbIuZ8ybMr39JquUEF7Ti27G2vcgOkanNklQXJrV0AezSrKlaRAlfYHgvRdmUrEsGLTxBzdRkvCxQ3NqSF4rlktM=;
Received: from localhost ([127.0.0.1]:46737 helo=sescenties) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from <schoen@eff.org>) id 1VeVfC-0007z3-Mi; Thu, 07 Nov 2013 11:54:46 -0800
Date: Thu, 7 Nov 2013 11:54:46 -0800
From: Seth David Schoen <schoen@eff.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Message-ID: <20131107195446.GO2640@sescenties.(null)>
References: <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp> <527BE507.6090507@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <527BE507.6090507@fifthhorseman.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:54:55 -0000

Daniel Kahn Gillmor writes:

> Sure, but that is a bug in DNS, not a bug in TLS, and there are
> proposals (however farfetched) to work around that, like DNSCurve
> [0]. But fixing DNS leakage is out-of-scope for this working group.
> 
> Fixing TLS is in-scope, though, and TLS shouldn't leak information
> just because other related protocols also leak information.

And there might actually be some passive attackers who are on-path
with respect to the TLS session and not with respect to the DNS lookup
(for example, the DNS query might have been satisified by a recursive
resolver that's closer to the client than the eavesdropper is).

With CDNs, you sometimes get some pretty strange bedfellows on a single
server IP address, so the marginal information leak from SNI could be
pretty high!

-- 
Seth Schoen  <schoen@eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109       +1 415 436 9333 x107

From skyper@thc.org  Thu Nov  7 11:55:08 2013
Return-Path: <skyper@thc.org>
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 8FB0411E8297 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 mHlfB3dUo08V for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:55:04 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E46A911E8298 for <tls@ietf.org>; Thu,  7 Nov 2013 11:54:57 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id u16so1629148iet.21 for <tls@ietf.org>; Thu, 07 Nov 2013 11:54:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HPQHi4SU3yIhsErUDNFhYvsBGGjz7bHi7ADvGfKtQBQ=; b=D4QRMOeJwRVWtLwPUi0OpZ8tXizBdckGvGxc+r0W4m0pY6MZ2BME9R04x9vhBaL3E8 1V7tXpjt6e3DErf2ti2c/K8ZlcGC6tCLY6feOaQYX5UlzW+/Ul/MTZUOPjG2h/IbPhJH trpQIc3aZDbT1sM+7EN7+EpPRaRcdVJf/knrc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HPQHi4SU3yIhsErUDNFhYvsBGGjz7bHi7ADvGfKtQBQ=; b=hpcFF8UhMFiW4EKST4MYbvDxSY3jb1/2N47bRg4pr7WweE1yzoUWRUtZjJGySRNkIG ePwrggOuzLw2NHlsH/x4+YFuRElyD9zyh1UuSBp3DuHOORDF5EcPKRnYRbxi/ZhsFk5s VqTD6z/GWDbdFhfIRTlfdmszHtCooK+m2ervuo0PkLr+7cBZACSX7hIJEQ05GVbqTGHC QQT8zM4MiNkZzIGzUEz+IuR5dPCm/azVFyTF/duhoCiE8ZGEDtqhhDl39V9TWAqOPuz/ CedhMpKBBmcobQ0viUV4zdIo9RQbXx/1LHl3xMXq/4GlYVQbNq/chm9QQ1tdbwR5Rmdv x/VA==
X-Gm-Message-State: ALoCoQmcsptx8tRbJsTj3VsH9wBxrugm4PaDvo8G1JHdy5bphettLgvbK50qC+AR/s/dw5qwvFrC
MIME-Version: 1.0
X-Received: by 10.42.227.72 with SMTP id iz8mr6443148icb.27.1383854097132; Thu, 07 Nov 2013 11:54:57 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Thu, 7 Nov 2013 11:54:57 -0800 (PST)
X-Originating-IP: [70.102.70.79]
In-Reply-To: <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com> <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com> <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
Date: Thu, 7 Nov 2013 19:54:57 +0000
Message-ID: <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary=001a11c3d304e224ab04ea9ba310
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:55:08 -0000

--001a11c3d304e224ab04ea9ba310
Content-Type: text/plain; charset=ISO-8859-1

Hi,


On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <ynir@checkpoint.com> wrote:

>  IMO, if both sites are either collocated on the same machine, or hosted
> behind the same SSL accelerator, they already share enough that multi-SAN
> is not a bad thing.
>
>  With SNI is it currently stands, the site you are looking for is sent in
> the clear. If we keep the choose-certificate functionality in 1.3, we still
> leave it exposed in either the SNI or in the certificate that the server
> sends. A generic certificate is the only one that hides what the client is
> browsing.
> TLS mailing list
>

No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy' as
presented by Eric yesterday. Key Exchange is done before SNI is send and
auth is done as last. (What's now cleartext would then require
detectable-active attack).

regards,

ralf

--001a11c3d304e224ab04ea9ba310
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote">On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <span dir=3D"ltr">&lt;<=
a href=3D"mailto:ynir@checkpoint.com" target=3D"_blank">ynir@checkpoint.com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">




<div style=3D"word-wrap:break-word">
IMO, if both sites are either collocated on the same machine, or hosted beh=
ind the same SSL accelerator, they already share enough that multi-SAN is n=
ot a bad thing.
<div><br>
</div>
<div>With SNI is it currently stands, the site you are looking for is sent =
in the clear. If we keep the choose-certificate functionality in 1.3, we st=
ill leave it exposed in either the SNI or in the certificate that the serve=
r sends. A generic certificate is
 the only one that hides what the client is browsing.</div>
<div>TLS mailing list<br></div></div></blockquote></div><br></div><div clas=
s=3D"gmail_extra">No, SNI can be send encrypted in TLS 1.3 with &#39;Reduce=
d RT with Privacy&#39; as presented by Eric yesterday. Key Exchange is done=
 before SNI is send and auth is done as last. (What&#39;s now cleartext wou=
ld then require detectable-active attack).<br>
<br></div><div class=3D"gmail_extra">regards,<br><br>ralf<br><br></div></di=
v>

--001a11c3d304e224ab04ea9ba310--

From rsalz@akamai.com  Thu Nov  7 11:56:07 2013
Return-Path: <rsalz@akamai.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 B055311E81F3 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:56:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level: 
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 7J36A9J5E4LU for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 11:56:03 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3733911E8296 for <tls@ietf.org>; Thu,  7 Nov 2013 11:55:49 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 707EB284F9; Thu,  7 Nov 2013 19:55:48 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 58F10284F7; Thu,  7 Nov 2013 19:55:48 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 4E52C202A; Thu,  7 Nov 2013 19:55:48 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 7 Nov 2013 14:55:48 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Yoav Nir <ynir@checkpoint.com>, Ryan Hurst <ryan.hurst@globalsign.com>
Date: Thu, 7 Nov 2013 14:55:47 -0500
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAIAABPCAgAAhNICAACMt4A==
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF248@USMBX1.msg.corp.akamai.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com> <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com> <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
In-Reply-To: <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 19:56:07 -0000

> IMO, if both sites are either collocated on the same machine, or hosted b=
ehind the same SSL accelerator, they already share enough that multi-SAN is=
 not a bad thing.

Our experience disagrees.

> With SNI is it currently stands, the site you are looking for is sent in =
the clear. If we keep the choose-certificate functionality in 1.3, we still=
 leave it exposed in either the SNI or in the certificate that the server s=
ends. A generic certificate is the only one that hides what the client is b=
rowsing.

First, a disclaimer that this isn't a use-case my employer cares about much=
; on a personal note, I want more privacy.  But I don't see how you can mak=
e a 'generic certificate' that really meets the desired goal.  You already =
can't make a wildcard SAN for "*.com" or "*.co.uk" for example.

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA


From ynir@checkpoint.com  Thu Nov  7 12:07:08 2013
Return-Path: <ynir@checkpoint.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 C1F7A11E8275 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.527
X-Spam-Level: 
X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 PEHHC6idZS27 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:06:59 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7900F11E829A for <tls@ietf.org>; Thu,  7 Nov 2013 12:06:49 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA7K6j5R006217; Thu, 7 Nov 2013 22:06:45 +0200
X-CheckPoint: {527BF150-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 22:06:45 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ1sKAgAAGd4CAAAeWAIAABPCAgAAhNICAAAJPgIAAA0sA
Date: Thu, 7 Nov 2013 20:06:44 +0000
Message-ID: <19DC19A0-3620-4D05-A487-EC34BEBACE18@checkpoint.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com> <eb6ba436dfc994f6079ba798d048a02c@mail.gmail.com> <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com> <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com>
In-Reply-To: <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.53]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: multipart/alternative; boundary="_000_19DC19A036204D05A487EC34BEBACE18checkpointcom_"
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 20:07:08 -0000

--_000_19DC19A036204D05A487EC34BEBACE18checkpointcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On Nov 7, 2013, at 11:54 AM, Ralf Skyper Kaiser <skyper@thc.org<mailto:skyp=
er@thc.org>>
 wrote:

Hi,


On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <ynir@checkpoint.com<mailto:ynir@c=
heckpoint.com>> wrote:
IMO, if both sites are either collocated on the same machine, or hosted beh=
ind the same SSL accelerator, they already share enough that multi-SAN is n=
ot a bad thing.

With SNI is it currently stands, the site you are looking for is sent in th=
e clear. If we keep the choose-certificate functionality in 1.3, we still l=
eave it exposed in either the SNI or in the certificate that the server sen=
ds. A generic certificate is the only one that hides what the client is bro=
wsing.
TLS mailing list

No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy' as =
presented by Eric yesterday. Key Exchange is done before SNI is send and au=
th is done as last. (What's now cleartext would then require detectable-act=
ive attack).


You mean the one in 5.1.1.2 ?

Yes, but the client still sends the SNI before receiving the certificate. T=
his makes it still visible to an active attacker.  But you are right that a=
 passive eavesdropper is now precluded.

Yoav



--_000_19DC19A036204D05A487EC34BEBACE18checkpointcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <F0B295F160D2144C9EF996D818C8A395@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
<br>
<div>
<div>On Nov 7, 2013, at 11:54 AM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:=
skyper@thc.org">skyper@thc.org</a>&gt;</div>
<div>&nbsp;wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div dir=3D"ltr">Hi,<br>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <span d=
ir=3D"ltr">
&lt;<a href=3D"mailto:ynir@checkpoint.com" target=3D"_blank">ynir@checkpoin=
t.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word">IMO, if both sites are either collocate=
d on the same machine, or hosted behind the same SSL accelerator, they alre=
ady share enough that multi-SAN is not a bad thing.
<div><br>
</div>
<div>With SNI is it currently stands, the site you are looking for is sent =
in the clear. If we keep the choose-certificate functionality in 1.3, we st=
ill leave it exposed in either the SNI or in the certificate that the serve=
r sends. A generic certificate is
 the only one that hides what the client is browsing.</div>
<div>TLS mailing list<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<div class=3D"gmail_extra">No, SNI can be send encrypted in TLS 1.3 with 'R=
educed RT with Privacy' as presented by Eric yesterday. Key Exchange is don=
e before SNI is send and auth is done as last. (What's now cleartext would =
then require detectable-active attack).<br>
<br>
</div>
</div>
</blockquote>
<br>
</div>
<div>You mean the one in 5.1.1.2 ?</div>
<div><br>
</div>
<div>Yes, but the client still sends the SNI before receiving the certifica=
te. This makes it still visible to an active attacker. &nbsp;But you are ri=
ght that a passive eavesdropper is now precluded.</div>
<div><br>
</div>
<div>Yoav</div>
<div><br>
</div>
<br>
</body>
</html>

--_000_19DC19A036204D05A487EC34BEBACE18checkpointcom_--

From mrex@sap.com  Thu Nov  7 12:08:31 2013
Return-Path: <mrex@sap.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 0E56421E80C1 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:08:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.13
X-Spam-Level: 
X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 bYUGbrH-jWYb for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:08:24 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5111E815C for <tls@ietf.org>; Thu,  7 Nov 2013 12:08:24 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rA7K8GRE025524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Nov 2013 21:08:16 +0100 (MET)
In-Reply-To: <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Thu, 7 Nov 2013 21:08:15 +0100 (CET)
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: <20131107200815.F24AB1AA69@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 07 Nov 2013 20:08:31 -0000

Ralf Skyper Kaiser wrote:
> 
> On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> > 
> >  IMO, if both sites are either collocated on the same machine, or hosted
> > behind the same SSL accelerator, they already share enough that multi-SAN
> > is not a bad thing.
> >
> >  With SNI is it currently stands, the site you are looking for is sent in
> > the clear. If we keep the choose-certificate functionality in 1.3, we still
> > leave it exposed in either the SNI or in the certificate that the server
> > sends. A generic certificate is the only one that hides what the client is
> > browsing.
> > TLS mailing list
> >
> 
> No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy' as
> presented by Eric yesterday. Key Exchange is done before SNI is send and
> auth is done as last. (What's now cleartext would then require
> detectable-active attack).

I'm sorry, but I firmly believe this will be pure and useless obscurity
coming at a high cost.

The amount of "activity" for the attack is minuscule (just tear down
the connection when you see the TLSv1.3 client hello -- the client
*WILL* reconnect with SNI in the clear.  For the NSA, this is trivial,
they're actively doing stuff like this on a regular basis (Foxacid).

There are already lots of sites and lots of middle-boxes that cause
errors like this in a non-malicious fashion, that "detecting" such
an error is only going to annoy users, but not provide any benefit.

For those negligible situation where there might be any theoretical
benefit at all, it would be possible to define a seperate TLS extension
with the properties you're looking for, rather than messing up SNI.

-Martin


From carl@redhoundsoftware.com  Thu Nov  7 12:08:36 2013
Return-Path: <carl@redhoundsoftware.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 E155821E8096 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 BbZ8xTTBR-MQ for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:08:31 -0800 (PST)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 988F321E8137 for <tls@ietf.org>; Thu,  7 Nov 2013 12:08:28 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id v10so1092131pde.29 for <tls@ietf.org>; Thu, 07 Nov 2013 12:08:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=cs7hrfWaImzGPQ0QeGhESvE0XjDs+xFF39d/SmzOMhs=; b=D3UCZrO+ZnRdw1uMAdsZ0V/CIVGH+tEZNzQXpeQvZ/q2R2Rb6HoL4Mzbl20AgLU5LR 0VcpwuBaxIzWnRYRSAgow8CJ+eXiE53b6SvixAgEGr1lTdO3AZVTFWHHunb3nEKsQ8oV OuFwQ8iOpPTkkGMxJLo7p5Pfusa+Tio9zyJ/Q5kFg6XgPjIuUmZQGuKs4QHWB/7yzv2B e8x4QJ59fvO4ZeDnvzVV0B75eap0E60VTRdAUR+H9gm5qvZdDxKmcqBUtRUaOLI2zcPj WMq7US76Ee96DofTBfyPi4ReZTGCJ54nS9F3g/+asV4hK0ei6+1bUVyNnMw1dutpLaln cU4Q==
X-Gm-Message-State: ALoCoQkGlCIFAVXJ3ZugM+An/s81IZVpyzBYS0sBtI0nasG1YDIHNxxRSj9H+S1+1GuH/GhyDHjQ
X-Received: by 10.68.133.198 with SMTP id pe6mr10971382pbb.10.1383854907923; Thu, 07 Nov 2013 12:08:27 -0800 (PST)
Received: from [192.168.0.131] (S01061caff7df80fa.vc.shawcable.net. [24.85.69.194]) by mx.google.com with ESMTPSA id zq10sm8555030pab.6.2013.11.07.12.08.26 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Nov 2013 12:08:27 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.8.130913
Date: Thu, 07 Nov 2013 12:08:21 -0800
From: Carl Wallace <carl@redhoundsoftware.com>
To: Andy Lutomirski <luto@amacapital.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <CEA1320D.8065%carl@redhoundsoftware.com>
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
In-Reply-To: <527BEF5E.8070704@amacapital.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Thu, 07 Nov 2013 20:08:37 -0000

On 11/7/13 11:51 AM, "Andy Lutomirski" <luto@amacapital.net> wrote:

>I'm not sure that this is in scope for TLS 1.3, but if it were part of
>TLS 1.3 then servers could send different certificates to clients
>depending on TLS version.
>
>Currently, if an organization wants to use a wildcard certificate, every
>web server must possess (or at least be able to use) the associated
>private key.  Similarly, if an organization wants to use short-lived
>keys, it must ask its CA to sign a large number of short-lived
>certificates.
>
>In principle, a server could present a certificate chain like this:
>
>1. trusted root
>    |
>    V
>2. intermediate CA  (owned by outside authority)
>    |
>    V
>3. non-CA (wildcard?) certificate  (owned by the server's operator)
>    |
>    V
>4. short-lived or domain-specific certificate

Proxy certificates should accomplish what you want. See RFC3820.




From luto@amacapital.net  Thu Nov  7 12:15:48 2013
Return-Path: <luto@amacapital.net>
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 0BC6421E809D for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.696
X-Spam-Level: 
X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=0.281,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 TeK-0vnXCQEG for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:15:38 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDBD21E8096 for <tls@ietf.org>; Thu,  7 Nov 2013 12:15:38 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id 11so745457vbe.31 for <tls@ietf.org>; Thu, 07 Nov 2013 12:15:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EFySXiZX7/hFqrQDQCZ7F/6Lwzaqi0i80Dw3AB/hlRw=; b=Hj3BQwSilBn8tt0SmgOvrooNRIb6iXBJk/6zHEzdsNUjhD/AlZQ26OVP3ZZI36IWBM KTG7kWDRNfc6EM9RbVfnMePhW1xBCy1COYlwi5CHd5CrneOAtJegOUuXhFhr6lthscuV ujPcCiOnBm9CkxZWbaYrKs+UpeoiNebFzgLi7CmSJfOAM1fA2C+KvG5H1OBE/abjFR6g Ecoe05aZxcUmpx0nm5kbZaOvFOZNB7aKspZgQEgoFM3PUon5VE7KDNLzMxLn5joa/x4r t2L6LWKLlpX0A13sFpvMNUH5MSI0WxJglnuNaqqjew1wH4OE2a9SCtz5Du+lQiDoWnhK Tq6w==
X-Gm-Message-State: ALoCoQnlcYCk+n5AdZN7UjgIEduj0rofWO2QUR1D81mPV6xwA8Pc1K8PxyBSHvp7nIQX+RB8LMZ0
X-Received: by 10.52.27.243 with SMTP id w19mr6617541vdg.3.1383855330972; Thu, 07 Nov 2013 12:15:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Thu, 7 Nov 2013 12:15:10 -0800 (PST)
In-Reply-To: <CEA1320D.8065%carl@redhoundsoftware.com>
References: <527BEF5E.8070704@amacapital.net> <CEA1320D.8065%carl@redhoundsoftware.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Thu, 7 Nov 2013 12:15:10 -0800
Message-ID: <CALCETrUGfMqVzW3PgKJuLoRpGYuOsSH2SzaXV0DxRdAxhUimmw@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Thu, 07 Nov 2013 20:15:48 -0000

On Thu, Nov 7, 2013 at 12:08 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:
>
> On 11/7/13 11:51 AM, "Andy Lutomirski" <luto@amacapital.net> wrote:
>
>>I'm not sure that this is in scope for TLS 1.3, but if it were part of
>>TLS 1.3 then servers could send different certificates to clients
>>depending on TLS version.
>>
>>Currently, if an organization wants to use a wildcard certificate, every
>>web server must possess (or at least be able to use) the associated
>>private key.  Similarly, if an organization wants to use short-lived
>>keys, it must ask its CA to sign a large number of short-lived
>>certificates.
>>
>>In principle, a server could present a certificate chain like this:
>>
>>1. trusted root
>>    |
>>    V
>>2. intermediate CA  (owned by outside authority)
>>    |
>>    V
>>3. non-CA (wildcard?) certificate  (owned by the server's operator)
>>    |
>>    V
>>4. short-lived or domain-specific certificate
>
> Proxy certificates should accomplish what you want. See RFC3820.

Interesting -- I'd never noticed that.

That being said, proxy certificates are essentially useless unless all
clients support them.  In the absence of mandatory support or a client
extension indicating acceptance of proxy certificates, they won't be
used.

--Andy

From carl@redhoundsoftware.com  Thu Nov  7 12:26:48 2013
Return-Path: <carl@redhoundsoftware.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 3F6D621E809F for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 klHxgt80XiOi for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:26:42 -0800 (PST)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3C221E8137 for <tls@ietf.org>; Thu,  7 Nov 2013 12:26:42 -0800 (PST)
Received: by mail-pa0-f43.google.com with SMTP id hz1so1137149pad.16 for <tls@ietf.org>; Thu, 07 Nov 2013 12:26:42 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ix5vDgT3++axe1VQr8/rcdVQ/xizb7ojkrXuTtTbbDk=; b=ixJiUSv5CdcfSdXbSvZeTFXxABjWlq0wkfj+rXyORfH8Od1+Z7MhV2mJ/DVrTuYoGC 0gvvFyGFLCVol8/smohSvjrzu0+Nnvu3397pP8kT/tfzeLq/ibY0BfLiyPQTmUzefeaX iXbgFJtdgJSCKUzmAJQBaosDxgbCp+h3WnUwRXot0jxJW8HoSREEn6yQBlpzye4weH6s uRkB29oKx3ox6+RveRJNYnSAimIKyb/z4WD/J4cr+QtR72mrMiyGFdAkBEMcVNW3uIby icfVkfTNWSpeDSZzbimCqdhgWTXDMY8UdWxQhNTtqVWmTEUvzhBsRuJdtQCht98ZEbkx jVuQ==
X-Gm-Message-State: ALoCoQkiGCaWQxX4gxcso+C+pBbC+5aZShhnG5ud/J8oN/6i0N8+E+lg+GQ6S7wRN9Lx2KC71zsV
X-Received: by 10.66.102.66 with SMTP id fm2mr11646550pab.94.1383856002034; Thu, 07 Nov 2013 12:26:42 -0800 (PST)
Received: from [192.168.0.131] (S01061caff7df80fa.vc.shawcable.net. [24.85.69.194]) by mx.google.com with ESMTPSA id sy10sm8595606pac.15.2013.11.07.12.26.40 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Nov 2013 12:26:41 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.8.130913
Date: Thu, 07 Nov 2013 12:26:35 -0800
From: Carl Wallace <carl@redhoundsoftware.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <CEA13683.807E%carl@redhoundsoftware.com>
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
In-Reply-To: <CALCETrUGfMqVzW3PgKJuLoRpGYuOsSH2SzaXV0DxRdAxhUimmw@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Thu, 07 Nov 2013 20:26:48 -0000

>
>Interesting -- I'd never noticed that.
>
>That being said, proxy certificates are essentially useless unless all
>clients support them.  In the absence of mandatory support or a client
>extension indicating acceptance of proxy certificates, they won't be
>used.

Of course, but the same goes for notional hybrid server/CA certificates
too, no?  There is apparently some support for proxy certificates in
Apache.  I've no idea what it's used for or how well it works though.  



From luto@amacapital.net  Thu Nov  7 12:49:59 2013
Return-Path: <luto@amacapital.net>
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 AA24C21E8186 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level: 
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 Cdqu7QbOzdxZ for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 12:49:54 -0800 (PST)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55A21E80DB for <tls@ietf.org>; Thu,  7 Nov 2013 12:49:54 -0800 (PST)
Received: by mail-vb0-f54.google.com with SMTP id q12so770579vbe.41 for <tls@ietf.org>; Thu, 07 Nov 2013 12:49:53 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i7vFQT73PkdS0zYhSQuyeCmmAhUXHB22cCF8UANXzxY=; b=ZwWVFAnAoQSyrmp/gcW6ey34eZyzDJVXuAhFodPx8vWikd743Qa74l11URlKGRAnes sONaW+Gag4z/qpIvLBQYozBXz5VGSbOKcLmbinqxtTtlSbPSGoOzioydz6eYLTioBUFe z3u/6eAukdr/KP61LbWbnrWrmA3P2GNzBrXO4Ttl54FDGxCXLBXAbH+y3PkcYxPOkdly djJtVpYi+2LMeftcC5p74lcUSOxTvIb9rzeuOzV/UAxhIZPmPBmlGNfotzYBxRq9R2V3 wIikwXe9uJ2hTd/g26rH6xJAA4zpNpxEFjKyYonroLyIYRI5Q7QOxcBlOwHA54ScYsaY 1pdA==
X-Gm-Message-State: ALoCoQn/SFv/vpJi3xeMZGuwuLtNwD2IBjqLI5hS6tx3sJEmQYhRFrTsWC7UAcT4RX+MawAdFfnX
X-Received: by 10.58.54.69 with SMTP id h5mr8326726vep.25.1383857393667; Thu, 07 Nov 2013 12:49:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Thu, 7 Nov 2013 12:49:33 -0800 (PST)
In-Reply-To: <CEA13683.807E%carl@redhoundsoftware.com>
References: <CALCETrUGfMqVzW3PgKJuLoRpGYuOsSH2SzaXV0DxRdAxhUimmw@mail.gmail.com> <CEA13683.807E%carl@redhoundsoftware.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Thu, 7 Nov 2013 12:49:33 -0800
Message-ID: <CALCETrVA6_Lhr3RYNHBFC+b1rJgPs0fujkZhsn2Ai7XFP_3iCQ@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Thu, 07 Nov 2013 20:49:59 -0000

On Thu, Nov 7, 2013 at 12:26 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:
>>
>>Interesting -- I'd never noticed that.
>>
>>That being said, proxy certificates are essentially useless unless all
>>clients support them.  In the absence of mandatory support or a client
>>extension indicating acceptance of proxy certificates, they won't be
>>used.
>
> Of course, but the same goes for notional hybrid server/CA certificates
> too, no?  There is apparently some support for proxy certificates in
> Apache.  I've no idea what it's used for or how well it works though.
>

Right.

My point is that, if something like this shows up as a mandatory
feature in TLS 1.3, then it becomes usable.  I would use it on
public-facing websites, for example.

--Andy

From nico@cryptonector.com  Thu Nov  7 13:38:01 2013
Return-Path: <nico@cryptonector.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 7C96021E8163 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 13:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
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 c3o0r89G11En for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 13:37:56 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7E99111E8110 for <tls@ietf.org>; Thu,  7 Nov 2013 13:37:55 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id C8DC2360083 for <tls@ietf.org>; Thu,  7 Nov 2013 13:37:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=w9Oviivf76UCnNtrh4SlOlvmmfU=; b=Y1XkJOrM+2c xkmLum8dTUcW1qN0vY2lplIOgLDuFMBzlXYIv9ibxve3sY6KhDRc0gf3aROy4c50 m7p9cv6M9ZTiy7RnxZvpZqetbawdspjip9tFT93EzWYAbqk1K0AuralkghgkTqoq tgR7Wo93q0kdIkCBEjWWf3TOFuw2NNGY=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 9E16D360079 for <tls@ietf.org>; Thu,  7 Nov 2013 13:37:47 -0800 (PST)
Date: Thu, 7 Nov 2013 15:37:46 -0600
From: Nico Williams <nico@cryptonector.com>
To: tls@ietf.org
Message-ID: <20131107213744.GQ18713@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [TLS] Windows 2003 TLS 64 ciphersuite limit
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: Thu, 07 Nov 2013 21:38:01 -0000

A non-subscriber (who doesn't want to subscribe just to send this) has
asked me to forward this to the TLS WG list.  Without further ado:

From: Viktor Dukhovni <postfix-users@dukhovni.org>
Subject: Windows 2003 TLS 64 ciphersuite limit
Date: Thu, 7 Nov 2013 19:40:16 +0000

[ Please forward to TLS list ]

While we're removing interoperability obstacles with TLSv1.2, ... 
There is another problem with expanded client HELLO messages.

The Windows 2003 TLS stack (still used by a non-trivial number of
Microsoft Exchange SMTP servers) only looks at the first 64 elements
of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
it sometimes chooses 3DES (for which it misimplements CBC padding)
and fails during data transfer, or if that is suppressed or also
too far down the list, just fails the handshake.

With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4
at position:

    $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-'
    93:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

    $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4-'
    111:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

so TLS handshakes with these servers fail!

It is not clear what should be done here, the most practical
reordering and trimming that comes to mind is:

    $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA'
    51:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

Which does not leave much room for more ciphers.  I've never seen
DSS or DH certificates in the wild, but presumably they are needed
in some quarters, so this is likely not a generally applicable
solution.

I don't know how much longer such servers are likely to remain
active.  Postfix users are working around this with custom cipher
exclusions in the per-destination TLS policy table on a case-by-case
basis. :-(

The best outcome would be if they all got upgraded!  This will take
some time I imagine.

-- 
	Viktor.

From skyper@thc.org  Thu Nov  7 13:39:32 2013
Return-Path: <skyper@thc.org>
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 E75A321E8163 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 13:39:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 gCgOR8p-j7AN for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 13:39:28 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5A21E809F for <tls@ietf.org>; Thu,  7 Nov 2013 13:39:25 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so1893254iec.41 for <tls@ietf.org>; Thu, 07 Nov 2013 13:39:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ynhEcvHYifT2r6KDAXYrTBUEAEZnD/5RHURbXuruvpg=; b=Jdj34hyCjR/FuToxuVbRl483yBkIQpF2jwLH8Cpfd4sZLQK/svhWfEEJsECVADcsT6 7EAjmvnNpPB3S0dHf2SnjIbe/ftL7YEQQL8ha/2VRI1tyE4awQLLxc/MjbLxrtNVq6Mu aBkefCGqungbROzWIaQZG+1W+ifWoC8ypn9/0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ynhEcvHYifT2r6KDAXYrTBUEAEZnD/5RHURbXuruvpg=; b=ejHXjLmhEQA78Xxxm8Sw9JjftGzJOk0IvHZ5khLAK+Tkr5DY6KUjAEzC+GlJsy6mpI VINHII87mfK78i6n87qZG6dIFzRgYiG+dYmAJm1A5ZWhpYHlpKCyMrgkOx+sEiFJY6ZM QjJRC1yI5WPJ1q0EgQ5+xwS5tQHyrDdBQ7S9KlRU79fk8CDXj8u+fgU6klPWwajYoYZp sH8LE7lQbYSpnlG+efLQXF88QhZKjhbiG+T1kxlmfq5nXIJ/j8qtMAyxwHpaK8fs4HrC qNY1X4YKDErt7ZxrVhTcMmevpKQI69hcyZg1M5IUT3SSCAxA9Ef2rVizYDSD4oPrswZ0 mXJw==
X-Gm-Message-State: ALoCoQmK334VlvJGKzqKQJufzfQ5r4zkTEp4fbk8DXp0eCwRh47pI+FObfXDgtJsEawzMOACwHDm
MIME-Version: 1.0
X-Received: by 10.43.80.67 with SMTP id zt3mr6698926icb.23.1383860364372; Thu, 07 Nov 2013 13:39:24 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Thu, 7 Nov 2013 13:39:24 -0800 (PST)
X-Originating-IP: [70.102.70.79]
In-Reply-To: <20131107200815.F24AB1AA69@ld9781.wdf.sap.corp>
References: <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com> <20131107200815.F24AB1AA69@ld9781.wdf.sap.corp>
Date: Thu, 7 Nov 2013 21:39:24 +0000
Message-ID: <CA+BZK2o411meJDkLwnwOudrkr-G_eWeFx0tirLhUCoSnKsddEg@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=001a1133326a70984404ea9d1931
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 21:39:33 -0000

--001a1133326a70984404ea9d1931
Content-Type: text/plain; charset=ISO-8859-1

Hi,

For TLS 1.3 there can be a solution that the SNI is never send in clear.

The downgrade attack to TLS 1.2 is possible and would trigger the SNI to be
send in clear again.
(It requires an active attack).

We need the backward compatibility (from TLS 1.3 to TLS 1.2) for the
foreseeable future. That does not
mean that we should continue with the same flaws in 1.3 that we have in
previous TLS versions.

regards,

ralf



On Thu, Nov 7, 2013 at 8:08 PM, Martin Rex <mrex@sap.com> wrote:

> Ralf Skyper Kaiser wrote:
> >
> > On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> > >
> > >  IMO, if both sites are either collocated on the same machine, or
> hosted
> > > behind the same SSL accelerator, they already share enough that
> multi-SAN
> > > is not a bad thing.
> > >
> > >  With SNI is it currently stands, the site you are looking for is sent
> in
> > > the clear. If we keep the choose-certificate functionality in 1.3, we
> still
> > > leave it exposed in either the SNI or in the certificate that the
> server
> > > sends. A generic certificate is the only one that hides what the
> client is
> > > browsing.
> > > TLS mailing list
> > >
> >
> > No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy'
> as
> > presented by Eric yesterday. Key Exchange is done before SNI is send and
> > auth is done as last. (What's now cleartext would then require
> > detectable-active attack).
>
> I'm sorry, but I firmly believe this will be pure and useless obscurity
> coming at a high cost.
>
> The amount of "activity" for the attack is minuscule (just tear down
> the connection when you see the TLSv1.3 client hello -- the client
> *WILL* reconnect with SNI in the clear.  For the NSA, this is trivial,
> they're actively doing stuff like this on a regular basis (Foxacid).
>
> There are already lots of sites and lots of middle-boxes that cause
> errors like this in a non-malicious fashion, that "detecting" such
> an error is only going to annoy users, but not provide any benefit.
>
> For those negligible situation where there might be any theoretical
> benefit at all, it would be possible to define a seperate TLS extension
> with the properties you're looking for, rather than messing up SNI.
>
> -Martin
>
>

--001a1133326a70984404ea9d1931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br></div><div>For TLS 1.3 there can be a solu=
tion that the SNI is never send in clear.<br><br></div><div>The downgrade a=
ttack to TLS 1.2 is possible and would trigger the SNI to be send in clear =
again.<br>
</div><div>(It requires an active attack).<br></div><div><br></div><div>We =
need the backward compatibility (from TLS 1.3 to TLS 1.2) for the foreseeab=
le future. That does not<br></div><div>mean that we should continue with th=
e same flaws in 1.3 that we have in previous TLS versions.<br>
<br></div>regards,<br><br>ralf<br><br></div><div class=3D"gmail_extra"><br>=
<br><div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 8:08 PM, Martin Rex <=
span dir=3D"ltr">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex=
@sap.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">Ralf=
 Skyper Kaiser wrote:<br>
&gt;<br>
&gt; On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir &lt;<a href=3D"mailto:ynir@ch=
eckpoint.com">ynir@checkpoint.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; =A0IMO, if both sites are either collocated on the same machine, =
or hosted<br>
&gt; &gt; behind the same SSL accelerator, they already share enough that m=
ulti-SAN<br>
&gt; &gt; is not a bad thing.<br>
&gt; &gt;<br>
&gt; &gt; =A0With SNI is it currently stands, the site you are looking for =
is sent in<br>
&gt; &gt; the clear. If we keep the choose-certificate functionality in 1.3=
, we still<br>
&gt; &gt; leave it exposed in either the SNI or in the certificate that the=
 server<br>
&gt; &gt; sends. A generic certificate is the only one that hides what the =
client is<br>
&gt; &gt; browsing.<br>
&gt; &gt; TLS mailing list<br>
&gt; &gt;<br>
&gt;<br>
&gt; No, SNI can be send encrypted in TLS 1.3 with &#39;Reduced RT with Pri=
vacy&#39; as<br>
&gt; presented by Eric yesterday. Key Exchange is done before SNI is send a=
nd<br>
&gt; auth is done as last. (What&#39;s now cleartext would then require<br>
&gt; detectable-active attack).<br>
<br>
</div></div>I&#39;m sorry, but I firmly believe this will be pure and usele=
ss obscurity<br>
coming at a high cost.<br>
<br>
The amount of &quot;activity&quot; for the attack is minuscule (just tear d=
own<br>
the connection when you see the TLSv1.3 client hello -- the client<br>
*WILL* reconnect with SNI in the clear. =A0For the NSA, this is trivial,<br=
>
they&#39;re actively doing stuff like this on a regular basis (Foxacid).<br=
>
<br>
There are already lots of sites and lots of middle-boxes that cause<br>
errors like this in a non-malicious fashion, that &quot;detecting&quot; suc=
h<br>
an error is only going to annoy users, but not provide any benefit.<br>
<br>
For those negligible situation where there might be any theoretical<br>
benefit at all, it would be possible to define a seperate TLS extension<br>
with the properties you&#39;re looking for, rather than messing up SNI.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
<br>
</font></span></blockquote></div><br></div>

--001a1133326a70984404ea9d1931--

From seonghan.shin@aist.go.jp  Thu Nov  7 14:02:35 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 C23E611E8142 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 14:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level: 
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 viVGZNpqOFKB for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 14:02:31 -0800 (PST)
Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id E545521E8144 for <tls@ietf.org>; Thu,  7 Nov 2013 14:02:27 -0800 (PST)
Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUnwN81TLbsjgZYZo37NjqJ+H/a+ZG3vT@postini.com; Thu, 07 Nov 2013 14:02:28 PST
Received: by mail-lb0-f182.google.com with SMTP id w6so965429lbh.13 for <tls@ietf.org>; Thu, 07 Nov 2013 14:02:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=1dlZSHSqGEFevg1eMlUsZotYj3ZvC0Ga0I3zBPLQ5F8=; b=FtjNhfKi6M0heJI88FdUUFrwgScWNOw8DIg7kmICS2EWX3G3u6fiIx6dnhDlQrPmRg Ocba83wVy2ZjybS7u7/A4dQTWf714P7RY8RTbSo/hJlMuhtD3TkuvBTIc7r5lKTZfbcl Yv1ms5wp+aE/fEJMRxbFAKTFKDHr7Um2d61R0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1dlZSHSqGEFevg1eMlUsZotYj3ZvC0Ga0I3zBPLQ5F8=; b=AmFJp+gNOD3Z/KJi+VaKqhXGamc7pOrEBe4v44qjHm4tgKhi16wGyy7jngNWUYAEY0 IkAIjOLbM1pKhTHpIQhQJu4OHH+sUKtKZc1soUAJUkWNrNoleeagapkcrY9LuvmzFT/u Ibt/aTsmgDvNH52ruz9jxaaDy/+/BQZbdK9L/kDxRmXoN4/1wBkhGY93HyLkQrOICun6 XqoQavM8DL0RxoC9mxhvOMNwN8AiPcQznWbhsCG3ASsTew1iq0mUPS6EiJCgFklw/T/M gjApL7E798ygHKkYiUwn2hzhNZZtKAjt0HHwyRFHCU/ms44Mp9Oy8TVR+ncwFn6gAB6R Kz8A==
X-Gm-Message-State: ALoCoQlohc+s6pQwMseGPWagq1j53sMUvsg+VLSaLSmEWXJaXmwDNweyohbSQBKTuReA0BfeYMA/8XO9WRNtlJltkkV/MfvsaMgpGedZGyYVAMvyZ8SQx/OIsongBbhDe/srmatCnkDggWcmxll0bAmKBk6YQrEBMA==
X-Received: by 10.112.72.233 with SMTP id g9mr948251lbv.2.1383861745860; Thu, 07 Nov 2013 14:02:25 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.72.233 with SMTP id g9mr948241lbv.2.1383861745677; Thu, 07 Nov 2013 14:02:25 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Thu, 7 Nov 2013 14:02:25 -0800 (PST)
Date: Fri, 8 Nov 2013 07:02:25 +0900
Message-ID: <CAEKgtqnQNarEsGO1XPeQOoQ1UK065-daa01d5PLyQD9d6SABeA@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c23fbcc50d3a04ea9d6b06
Subject: [TLS] PWD LC for TLS's "Standard RFC"? (Re:  TLS-PWD vs. TLS-SRP)
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: Thu, 07 Nov 2013 22:02:35 -0000

--001a11c23fbcc50d3a04ea9d6b06
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

This is just a summary of my emails regarding PWD.

First, I have reviewed almost all IETF email discusstions and on-site
discussions, related to PAKE, since 2008.
Now, the TLS wg is about to issue a LC for tls-pwd.
http://tools.ietf.org/html/draft-ietf-tls-pwd-01

Compared to SPEKE and AugPAKE,
https://tools.ietf.org/html/draft-shin-tls-augpake-01
http://tools.ietf.org/html/draft-jablon-speke-02
http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29
PWD is NOT a good choice.
1) PWD has no provable security.
2) PWD is not efficient.
3) PWD may not be patent-free because of SPEKE.

Need more PAKEs better than PWD? See
http://grouper.ieee.org/groups/1363/passwdPK/submissions.html and
http://www.jablon.org/passwordlinks.html

I know we all are security (or crypto) experts and which one is good/bad.

Thank you and best regards,
Shin


On Thu, Nov 7, 2013 at 10:15 AM, SeongHan Shin <seonghan.shin@aist.go.jp>wrote:

> Dear all,
>
> > Is there any advantages of tls-pwd over tls-srp?
>
> > Is there any advantages of tls-pwd over tls-augpake and SPEKE?
> These are clarifying questions because TLS WG is going with PWD towards
> "standard RFC" though PWD has no provable security and is less efficient
> (compared to SPEKE and AugPAKE).
> Are all tls wg members already clarified with advantages of using tls-pwd?
> If so, just let me know.
>
> For patent issues between SPEKE and PWD, there was no conclusions in the
> earlier IPsec meetings to my understanding.
>
> Best regards,
> Shin
>
>
> On Thu, Nov 7, 2013 at 7:44 AM, SeongHan Shin <seonghan.shin@aist.go.jp>wrote:
>
>> Hi Dan,
>>
>> I also was in the IPsec mailing list through all discussions of PAKE
>> schemes.
>> But, I don't remember any advantages of pwd over augpake and speke.
>> Do you mean patent issue that pwd is patent-free and speke isn't?
>>
>> Regards,
>> Shin
>>
>> On Thu, Nov 7, 2013 at 7:32 AM, Dan Harkins <dharkins@lounge.org> wrote:
>>
>>>
>>>   Hi Shin,
>>>
>>> On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:
>>> > Hi Dan,
>>> >
>>> > Here comes the next question:
>>> > Is there any advantages of tls-pwd over tls-augpake and SPEKE?
>>> > https://tools.ietf.org/html/draft-shin-tls-augpake-01
>>> > http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29
>>>
>>>   Mrs. Harkins didn't raise a moron. I really do not want to
>>> repeat the debacle that occurred on the IPsec mailing list
>>> regarding PAKE schemes.
>>>
>>>   If you would like to rehash all those exchanges I suggest
>>> you go look at the archives.
>>>
>>>   regards,
>>>
>>>   Dan.
>>>
>>>
>>>
>>>
>>
>>
>> --
>> ------------------------------------------------------------------
>> SeongHan Shin
>> Research Institute for Secure Systems (RISEC),
>> National Institute of Advanced Industrial Science and Technology (AIST),
>> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> Tel : +81-29-861-2670/5284
>> Fax : +81-29-861-5285
>> E-mail : seonghan.shin@aist.go.jp
>> ------------------------------------------------------------------
>>
>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>



-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a11c23fbcc50d3a04ea9d6b06
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div>Dea=
r all,<br><br></div>This is just a summary of my emails regarding PWD.<br><=
/div><br>First, I have reviewed almost all IETF email discusstions and on-s=
ite discussions, related to PAKE, since 2008.<br>
</div>Now, the TLS wg is about to issue a LC for tls-pwd.<br><a href=3D"htt=
p://tools.ietf.org/html/draft-ietf-tls-pwd-01">http://tools.ietf.org/html/d=
raft-ietf-tls-pwd-01</a><br><br></div>Compared to SPEKE and AugPAKE,<br><a =
href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01" target=3D"_b=
lank">https://tools.ietf.org/html/draft-shin-tls-augpake-01</a><br>
<a href=3D"http://tools.ietf.org/html/draft-jablon-speke-02">http://tools.i=
etf.org/html/draft-jablon-speke-02</a><br><a href=3D"http://en.wikipedia.or=
g/wiki/SPEKE_%28cryptography%29" target=3D"_blank">http://en.wikipedia.org/=
wiki/SPEKE_%28cryptography%29</a><br>
</div></div><div>PWD is NOT a good choice.<br></div>1) PWD has no provable =
security.<br></div>2) PWD is not efficient.<br></div>3) PWD may not be pate=
nt-free because of SPEKE.<br><br>Need more PAKEs better than PWD? See=20
<a href=3D"http://grouper.ieee.org/groups/1363/passwdPK/submissions.html">h=
ttp://grouper.ieee.org/groups/1363/passwdPK/submissions.html</a> and=20
<a href=3D"http://www.jablon.org/passwordlinks.html">http://www.jablon.org/=
passwordlinks.html</a><br><br></div><div></div>I know we all are security (=
or crypto) experts and which one is good/bad.<br><br></div>Thank you and be=
st regards,<br>
</div><div>Shin<br></div><div><div><div><div><div><div><div><div><div><div>=
<div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">On Thu, Nov 7, 2013 at 10:15 AM, SeongHan Shin <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:seonghan.shin@aist.go.jp" target=3D"_blank">seonghan.shin@ais=
t.go.jp</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Dear all=
,<br><div class=3D"gmail_extra"><br>&gt; Is there any advantages of tls-pwd=
 over tls-srp?<div class=3D"im">
<br>&gt; Is there any advantages of tls-pwd over tls-augpake and SPEKE?<br>=
</div></div><div class=3D"gmail_extra">These are clarifying questions becau=
se TLS WG is going with PWD towards &quot;standard RFC&quot; though PWD has=
 no provable security and is less efficient (compared to SPEKE and AugPAKE)=
.<br>

</div><div class=3D"gmail_extra">Are all tls wg members already clarified w=
ith advantages of using tls-pwd?<br></div><div class=3D"gmail_extra">If so,=
 just let me know.<br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">

For patent issues between SPEKE and PWD, there was no conclusions in the ea=
rlier IPsec meetings to my understanding.<br><br></div><div class=3D"gmail_=
extra">Best regards,<br></div><div class=3D"gmail_extra">Shin<br></div><div=
>
<div class=3D"h5"><div class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Thu, Nov 7, 2013 at 7:44 AM, SeongHan=
 Shin <span dir=3D"ltr">&lt;<a href=3D"mailto:seonghan.shin@aist.go.jp" tar=
get=3D"_blank">seonghan.shin@aist.go.jp</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div>Hi Dan,<br><br></div>I also was in the IPsec mailing list through al=
l discussions of PAKE schemes.<br>


</div>But, I don&#39;t remember any advantages of pwd over augpake and spek=
e.<br></div>Do you mean patent issue that pwd is patent-free and speke isn&=
#39;t?<br>
<div><div><div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">Regards,<br></div><div class=3D"gmail_extra">Shin<br></div><div class=
=3D"gmail_extra"><div><div><br><div class=3D"gmail_quote">On Thu, Nov 7, 20=
13 at 7:32 AM, Dan Harkins <span dir=3D"ltr">&lt;<a href=3D"mailto:dharkins=
@lounge.org" target=3D"_blank">dharkins@lounge.org</a>&gt;</span> wrote:<br=
>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br>
=A0 Hi Shin,<br>
<div><br>
On Wed, November 6, 2013 1:24 pm, SeongHan Shin wrote:<br>
&gt; Hi Dan,<br>
&gt;<br>
&gt; Here comes the next question:<br>
&gt; Is there any advantages of tls-pwd over tls-augpake and SPEKE?<br>
&gt; <a href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01" targ=
et=3D"_blank">https://tools.ietf.org/html/draft-shin-tls-augpake-01</a><br>
&gt; <a href=3D"http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29" targ=
et=3D"_blank">http://en.wikipedia.org/wiki/SPEKE_%28cryptography%29</a><br>
<br>
</div>=A0 Mrs. Harkins didn&#39;t raise a moron. I really do not want to<br=
>
repeat the debacle that occurred on the IPsec mailing list<br>
regarding PAKE schemes.<br>
<br>
=A0 If you would like to rehash all those exchanges I suggest<br>
you go look at the archives.<br>
<br>
=A0 regards,<br>
<br>
=A0 Dan.<br>
<br>
<br>
<br>
</blockquote></div><br><br clear=3D"all"><br></div></div><div>-- <br><div s=
tyle=3D"margin:0mm 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#3=
9;;font-size:10pt" lang=3D"EN-US">-----------------------------------------=
-------------------------<br>



SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>



Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+812=
98615285" target=3D"_blank">+81-29-861-5285</a><br>E-mail : <a href=3D"mail=
to:seonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seon=
ghan.shin@aist.go.jp</font></a><br>



------------------------------------------------------------------</span></=
div>
</div></div></div></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margin:0m=
m 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>


SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>


Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+812=
98615285" target=3D"_blank">+81-29-861-5285</a><br>E-mail : <a href=3D"mail=
to:seonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seon=
ghan.shin@aist.go.jp</font></a><br>


------------------------------------------------------------------</span></=
div>
</div></div></div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margin:0m=
m 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:10pt=
" lang=3D"EN-US">----------------------------------------------------------=
--------<br>
SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div></div></div></div></div></div></div></div></div></div></d=
iv></div></div>

--001a11c23fbcc50d3a04ea9d6b06--

From fabrice.gautier@gmail.com  Thu Nov  7 14:37:31 2013
Return-Path: <fabrice.gautier@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 D159821E8172 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 14:37:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 fueNL9g8hl1R for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 14:37:30 -0800 (PST)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C68F221E816F for <tls@ietf.org>; Thu,  7 Nov 2013 14:37:30 -0800 (PST)
Received: by mail-pd0-f175.google.com with SMTP id g10so1238827pdj.20 for <tls@ietf.org>; Thu, 07 Nov 2013 14:37:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/MKb8SB5gnfDdnCiwZUixpKTn61jgih1/sec7xtdW/I=; b=ORnNZItQQrIIIiFN+DBcEqbX5K1CiHQoMlqA42Rfk4hfzxJ3pcCFAUtD2/1Y0bB3vK scjBxinHqDiXRsh+mrTyRDd51hnBRLoFs7BorKPdF/DtruaSac0cnEL5gt6kK2Wdv6ht eV7z47qr6hxkXQk++OcPdm3TZS9dad2F3WtPkSSuZ14zqm/Jer3UtwQBapjqqJ5SIQ0e sIrTmM+xihHNO5xHfyQMUfFBbMHpsiyAfe9R1Ow4AvsGMiN+vfX08LSBntqrcAbEw2qe Lo3XUN1beSBw4oM0cTBpHD4OuJelo4b+aKN7U43sca1/vxZPQOa321qsA7Qcus9s4IT5 Yhsw==
X-Received: by 10.68.13.202 with SMTP id j10mr11304958pbc.147.1383863850410; Thu, 07 Nov 2013 14:37:30 -0800 (PST)
Received: from [17.244.7.96] ([17.244.7.96]) by mx.google.com with ESMTPSA id at4sm7456823pbc.30.2013.11.07.14.37.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 14:37:28 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-E42E981B-84E0-4879-A499-3C502F496C82
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (11B504)
In-Reply-To: <CAEKgtqnSgdouYAmSa5DbN1sME=65wi3PpM17b2+Bybsz8PzBow@mail.gmail.com>
Date: Thu, 7 Nov 2013 14:37:39 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <07A9A949-2A96-4401-B640-A0E1C438A8E8@gmail.com>
References: <CAEKgtqmfHpzNye_DCgyzJ7PmsGRFWCHAtjX=HOLKo0OEoEi0gQ@mail.gmail.com> <CANOyrg-LzPbft+DMH8h3HatAJAwTqx6PRBG_n=3MrSfWHcMSqg@mail.gmail.com> <CAEKgtqnSgdouYAmSa5DbN1sME=65wi3PpM17b2+Bybsz8PzBow@mail.gmail.com>
To: SeongHan Shin <seonghan.shin@aist.go.jp>
Cc: =?big5?B?pWqt7KlNqLk=?= <k-kobara@aist.go.jp>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Augmented PAKE (Re: New Version Notification for draft-shin-tls-augpake-01.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: Thu, 07 Nov 2013 22:37:31 -0000

--Apple-Mail-E42E981B-84E0-4879-A499-3C502F496C82
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

> On Nov 7, 2013, at 10:36, SeongHan Shin <seonghan.shin@aist.go.jp> wrote:
>=20
> Hi Fabrice,
>=20
> Thank you for your comment!
>=20
> Section 5.1 can be used in TLS 1.3 handshake (?) as in Eric's presentation=
 :)

I haven't seen anything in the TLS1.3 flows document that would allow that.

>=20
> >How does the client knows which group to use ?
> As you pointed out, we need to change Section 5.1 for the current tls vers=
ion.
> A naive approach is to add one round exchange after ServerHello.
> Any other good ideas?

I guess you could only require the extra round trip for the first connection=
 and have the client cache the group parameters somehow.=20

But then you probably need a way for the client to tell the server which par=
ameter it is using, so it can signal if the parameters match without going t=
hrough the whole handshake.=20

Also, your draft don't define new ciphersuites, like TLS-SRP does, so I don'=
t think it's complete.=20

   Fabrice=20


>=20
> Regards,
> Shin
>=20
>=20
>> On Fri, Nov 8, 2013 at 1:20 AM, Fabrice Gautier <fabrice.gautier@gmail.co=
m> wrote:
>> Hi,
>>=20
>> How does the client knows which group to use ?
>>=20
>> As the client would need to know the group before sending the
>> ClientHello, it seems that the client needs to remember the groups
>> parameters along with the password, which seems impractical.
>>=20
>>=20
>> -- Fabrice
>>=20
>>=20
>> On Wed, Nov 6, 2013 at 11:25 AM, SeongHan Shin <seonghan.shin@aist.go.jp>=
 wrote:
>> > Dear all,
>> >
>> > For anyone who are interested in PAKE, pls see the below I-D regarding
>> > augmented PAKE.
>> >
>> > IMO, two reasons that SRP was published as RFC 2945 and included in IEE=
E
>> > 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the
>> > server's computation cost of SRP is a minimum.
>> > (Though SRP has no provable security)
>> >
>> > The AugPAKE in the below I-D is provably secure and more efficient than=

>> > other augmented PAKEs (including SRP and AMP).
>> >
>> > Of course, augmented PAKE provides additional security property over
>> > (balanced) PAKE.
>> >
>> > Best regards,
>> > Shin
>> >
>> >
>> > On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin <seonghan.shin@aist.go.jp=
>
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I submitted a new version of our I-D regarding augmented PAKE (AugPAKE=
)
>> >> and its integration into TLS.
>> >> I added some features of AugPAKE in Appendix.
>> >> Any comments are welcome!
>> >>
>> >> Best regards,
>> >> Shin
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: <internet-drafts@ietf.org>
>> >> Date: Wed, Sep 4, 2013 at 6:26 PM
>> >> Subject: New Version Notification for draft-shin-tls-augpake-01.txt
>> >> To: Kazukuni Kobara <kobara_conf-ml@aist.go.jp>, SeongHan Shin
>> >> <seonghan.shin@aist.go.jp>
>> >>
>> >>
>> >>
>> >> A new version of I-D, draft-shin-tls-augpake-01.txt
>> >> has been successfully submitted by SeongHan Shin and posted to the
>> >> IETF repository.
>> >>
>> >> Filename:        draft-shin-tls-augpake
>> >> Revision:        01
>> >> Title:           Augmented Password-Authenticated Key Exchange for
>> >> Transport Layer Security (TLS)
>> >> Creation date:   2013-09-04
>> >> Group:           Individual Submission
>> >> Number of pages: 19
>> >> URL:
>> >> http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-01.txt
>> >> Status:          http://datatracker.ietf.org/doc/draft-shin-tls-augpak=
e
>> >> Htmlized:        http://tools.ietf.org/html/draft-shin-tls-augpake-01
>> >> Diff:
>> >> http://www.ietf.org/rfcdiff?url2=3Ddraft-shin-tls-augpake-01
>> >>
>> >> Abstract:
>> >>    This document describes an efficient augmented password-authenticat=
ed
>> >>    key exchange (AugPAKE) protocol where a user remembers a low-entrop=
y
>> >>    password and its verifier is registered in the intended server.  In=

>> >>    general, the user password is chosen from a small set of dictionary=

>> >>    whose space is within the off-line dictionary attacks.  The AugPAKE=

>> >>    protocol described here is secure against passive attacks, active
>> >>    attacks and off-line dictionary attacks (on the obtained messages
>> >>    with passive/active attacks), and also provides resistance to serve=
r
>> >>    compromise (in the context of augmented PAKE security).  Based on t=
he
>> >>    AugPAKE protocol, this document also specifies a new password-only
>> >>    authentication handshake for Transport Layer Security (TLS) protoco=
l.
>> >>
>> >>
>> >>
>> >>
>> >> Please note that it may take a couple of minutes from the time of
>> >> submission
>> >> until the htmlized version and diff are available at tools.ietf.org.
>> >>
>> >> The IETF Secretariat
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> ------------------------------------------------------------------
>> >> SeongHan Shin
>> >> Research Institute for Secure Systems (RISEC),
>> >> National Institute of Advanced Industrial Science and Technology (AIST=
),
>> >> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> >> Tel : +81-29-861-2670/5284
>> >> Fax : +81-29-861-5285
>> >> E-mail : seonghan.shin@aist.go.jp
>> >> ------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> > --
>> > ------------------------------------------------------------------
>> > SeongHan Shin
>> > Research Institute for Secure Systems (RISEC),
>> > National Institute of Advanced Industrial Science and Technology (AIST)=
,
>> > Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> > Tel : +81-29-861-2670/5284
>> > Fax : +81-29-861-5285
>> > E-mail : seonghan.shin@aist.go.jp
>> > ------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>=20
>=20
>=20
> --=20
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------

--Apple-Mail-E42E981B-84E0-4879-A499-3C502F496C82
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>On Nov 7, 2013, at 10:36, SeongHan Shi=
n &lt;<a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@aist.go.jp</=
a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr"><=
div>Hi Fabrice,<br><br></div><div>Thank you for your comment!<br><br></div>S=
ection 5.1 can be used in TLS 1.3 handshake (?) as in Eric's presentation :)=
<br></div></div></blockquote><div><br></div>I haven't seen anything in the T=
LS1.3 flows document that would allow that.<div><br><blockquote type=3D"cite=
"><div><div dir=3D"ltr"><br>&gt;How does the client knows which group to use=
 ?<br>
<div><div class=3D"gmail_extra">As you pointed out, we need to change Sectio=
n 5.1 for the current tls version.<br></div><div class=3D"gmail_extra">A nai=
ve approach is to add one round exchange after ServerHello.<br></div><div cl=
ass=3D"gmail_extra">
Any other good ideas?<br></div></div></div></div></blockquote><div><br></div=
>I guess you could only require the extra round trip for the first connectio=
n and have the client cache the group parameters somehow.&nbsp;<div><br></di=
v><div>But then you probably need a way for the client to tell the server wh=
ich parameter it is using, so it can signal if the parameters match without g=
oing through the whole handshake.&nbsp;</div><div><br></div><div>Also, your d=
raft don't define new ciphersuites, like TLS-SRP does, so I don't think it's=
 complete.&nbsp;</div><div><br></div><div>&nbsp; &nbsp;Fabrice&nbsp;</div><d=
iv><br></div><div><br><div><blockquote type=3D"cite"><div><div dir=3D"ltr"><=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Regards,=
<br></div><div class=3D"gmail_extra">Shin<br></div><div class=3D"gmail_extra=
"><br><br><div class=3D"gmail_quote">On Fri, Nov 8, 2013 at 1:20 AM, Fabrice=
 Gautier <span dir=3D"ltr">&lt;<a href=3D"mailto:fabrice.gautier@gmail.com" t=
arget=3D"_blank">fabrice.gautier@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
How does the client knows which group to use ?<br>
<br>
As the client would need to know the group before sending the<br>
ClientHello, it seems that the client needs to remember the groups<br>
parameters along with the password, which seems impractical.<br>
<br>
<br>
-- Fabrice<br>
<div><div class=3D"h5"><br>
<br>
On Wed, Nov 6, 2013 at 11:25 AM, SeongHan Shin &lt;<a href=3D"mailto:seongha=
n.shin@aist.go.jp">seonghan.shin@aist.go.jp</a>&gt; wrote:<br>
&gt; Dear all,<br>
&gt;<br>
&gt; For anyone who are interested in PAKE, pls see the below I-D regarding<=
br>
&gt; augmented PAKE.<br>
&gt;<br>
&gt; IMO, two reasons that SRP was published as RFC 2945 and included in IEE=
E<br>
&gt; 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the<b=
r>
&gt; server's computation cost of SRP is a minimum.<br>
&gt; (Though SRP has no provable security)<br>
&gt;<br>
&gt; The AugPAKE in the below I-D is provably secure and more efficient than=
<br>
&gt; other augmented PAKEs (including SRP and AMP).<br>
&gt;<br>
&gt; Of course, augmented PAKE provides additional security property over<br=
>
&gt; (balanced) PAKE.<br>
&gt;<br>
&gt; Best regards,<br>
&gt; Shin<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin &lt;<a href=3D"mailto:seo=
nghan.shin@aist.go.jp">seonghan.shin@aist.go.jp</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Dear all,<br>
&gt;&gt;<br>
&gt;&gt; I submitted a new version of our I-D regarding augmented PAKE (AugP=
AKE)<br>
&gt;&gt; and its integration into TLS.<br>
&gt;&gt; I added some features of AugPAKE in Appendix.<br>
&gt;&gt; Any comments are welcome!<br>
&gt;&gt;<br>
&gt;&gt; Best regards,<br>
&gt;&gt; Shin<br>
&gt;&gt;<br>
&gt;&gt; ---------- Forwarded message ----------<br>
&gt;&gt; From: &lt;<a href=3D"mailto:internet-drafts@ietf.org">internet-draf=
ts@ietf.org</a>&gt;<br>
&gt;&gt; Date: Wed, Sep 4, 2013 at 6:26 PM<br>
&gt;&gt; Subject: New Version Notification for draft-shin-tls-augpake-01.txt=
<br>
&gt;&gt; To: Kazukuni Kobara &lt;<a href=3D"mailto:kobara_conf-ml@aist.go.jp=
">kobara_conf-ml@aist.go.jp</a>&gt;, SeongHan Shin<br>
&gt;&gt; &lt;<a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@aist.=
go.jp</a>&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; A new version of I-D, draft-shin-tls-augpake-01.txt<br>
&gt;&gt; has been successfully submitted by SeongHan Shin and posted to the<=
br>
&gt;&gt; IETF repository.<br>
&gt;&gt;<br>
&gt;&gt; Filename: &nbsp; &nbsp; &nbsp; &nbsp;draft-shin-tls-augpake<br>
&gt;&gt; Revision: &nbsp; &nbsp; &nbsp; &nbsp;01<br>
&gt;&gt; Title: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Augmented Password-Authen=
ticated Key Exchange for<br>
&gt;&gt; Transport Layer Security (TLS)<br>
&gt;&gt; Creation date: &nbsp; 2013-09-04<br>
&gt;&gt; Group: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Individual Submission<br>=

&gt;&gt; Number of pages: 19<br>
&gt;&gt; URL:<br>
&gt;&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-shin-tls-augpa=
ke-01.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-shin-=
tls-augpake-01.txt</a><br>
&gt;&gt; Status: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"http://datatra=
cker.ietf.org/doc/draft-shin-tls-augpake" target=3D"_blank">http://datatrack=
er.ietf.org/doc/draft-shin-tls-augpake</a><br>
&gt;&gt; Htmlized: &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"http://tools.ietf.o=
rg/html/draft-shin-tls-augpake-01" target=3D"_blank">http://tools.ietf.org/h=
tml/draft-shin-tls-augpake-01</a><br>
&gt;&gt; Diff:<br>
&gt;&gt; <a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-shin-tls-augpak=
e-01" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Ddraft-shin-tls-au=
gpake-01</a><br>
&gt;&gt;<br>
&gt;&gt; Abstract:<br>
&gt;&gt; &nbsp; &nbsp;This document describes an efficient augmented passwor=
d-authenticated<br>
&gt;&gt; &nbsp; &nbsp;key exchange (AugPAKE) protocol where a user remembers=
 a low-entropy<br>
&gt;&gt; &nbsp; &nbsp;password and its verifier is registered in the intende=
d server. &nbsp;In<br>
&gt;&gt; &nbsp; &nbsp;general, the user password is chosen from a small set o=
f dictionary<br>
&gt;&gt; &nbsp; &nbsp;whose space is within the off-line dictionary attacks.=
 &nbsp;The AugPAKE<br>
&gt;&gt; &nbsp; &nbsp;protocol described here is secure against passive atta=
cks, active<br>
&gt;&gt; &nbsp; &nbsp;attacks and off-line dictionary attacks (on the obtain=
ed messages<br>
&gt;&gt; &nbsp; &nbsp;with passive/active attacks), and also provides resist=
ance to server<br>
&gt;&gt; &nbsp; &nbsp;compromise (in the context of augmented PAKE security)=
. &nbsp;Based on the<br>
&gt;&gt; &nbsp; &nbsp;AugPAKE protocol, this document also specifies a new p=
assword-only<br>
&gt;&gt; &nbsp; &nbsp;authentication handshake for Transport Layer Security (=
TLS) protocol.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Please note that it may take a couple of minutes from the time of<b=
r>
&gt;&gt; submission<br>
&gt;&gt; until the htmlized version and diff are available at <a href=3D"htt=
p://tools.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
&gt;&gt;<br>
&gt;&gt; The IETF Secretariat<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; ------------------------------------------------------------------<=
br>
&gt;&gt; SeongHan Shin<br>
&gt;&gt; Research Institute for Secure Systems (RISEC),<br>
&gt;&gt; National Institute of Advanced Industrial Science and Technology (A=
IST),<br>
&gt;&gt; Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>=

&gt;&gt; Tel : +81-29-861-2670/5284<br>
&gt;&gt; Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+81298615285">+81-=
29-861-5285</a><br>
&gt;&gt; E-mail : <a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@=
aist.go.jp</a><br>
&gt;&gt; ------------------------------------------------------------------<=
br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; ------------------------------------------------------------------<br>
&gt; SeongHan Shin<br>
&gt; Research Institute for Secure Systems (RISEC),<br>
&gt; National Institute of Advanced Industrial Science and Technology (AIST)=
,<br>
&gt; Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>
&gt; Tel : +81-29-861-2670/5284<br>
&gt; Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+81298615285">+81-29-8=
61-5285</a><br>
&gt; E-mail : <a href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@aist=
.go.jp</a><br>
&gt; ------------------------------------------------------------------<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; TLS mailing list<br>
&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margin:0mm=
 0mm 0pt"><span style=3D"font-family:'MS UI Gothic';font-size:10pt" lang=3D"=
EN-US">------------------------------------------------------------------<br=
>
SeongHan Shin<br></span><span style=3D"font-family:'MS UI Gothic';font-size:=
10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC),<br>Natio=
nal Institute of Advanced Industrial Science and Technology (AIST),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +81=
-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:seo=
nghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan.sh=
in@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></d=
iv>
</div></div></div>
</div></blockquote></div></div></div></body></html>=

--Apple-Mail-E42E981B-84E0-4879-A499-3C502F496C82--

From mike-list@pobox.com  Thu Nov  7 15:18:18 2013
Return-Path: <mike-list@pobox.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 6418C11E827F for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 15:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 ZjndzoI8zrLG for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 15:18:12 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0321E808A for <tls@ietf.org>; Thu,  7 Nov 2013 15:17:59 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2ED2AE583; Thu,  7 Nov 2013 18:17:43 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=+W8ZXBBNr73W BzAo6JKm/YlvjQc=; b=Vs/pjCAQNxwuQ3lB1aQR5kp5U3v7Go7e3m4ZmLwqGfvM pLf5g1fL6sd3R5qussOmvDBdUFY3VBrGDZm3ljo8KQUUDRA9UYnQjx81sGkSTeZC U4UOLr+0bhNfiWQMwlJbczSur0NcOBTuJ+C0z8j+4fSudd4uQKLCq2hvabNNha0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=JD3QTz QtaqPHen2CglkPECTZjLG9gK0c21HHfWfFMZ727fQohlWANID7LOmIaFE+9zRxzJ ELOyrFgGzywIZ59Wygb+qeT68JNbrmiDvQlc+kT9WmJ540dHJkj/i7SQJyvDZTzu eejcaOiVjyRV+ZaVxrn0Pzy5nOYRISMC2uPdI=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 24DE0E582; Thu,  7 Nov 2013 18:17:43 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4EB8AE578; Thu,  7 Nov 2013 18:17:42 -0500 (EST)
Message-ID: <527C1F95.403@pobox.com>
Date: Thu, 07 Nov 2013 15:17:41 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
References: <20131107185957.8B48C1AA69@ld9781.wdf.sap.corp> <527BE507.6090507@fifthhorseman.net>
In-Reply-To: <527BE507.6090507@fifthhorseman.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: CD8B4960-4802-11E3-BA2E-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Thu, 07 Nov 2013 23:18:18 -0000

Daniel Kahn Gillmor wrote:
> 
> Putting SNI info in an encrypted handshake would make that information 
> unavailable to passive attackers.  Despite still being vulnerable to 
> active attackers (possibly at the cost of a connection failure) this is 
> a win, and if we can offer this protection in the protocol, we should.

SNI is not limited to host names, though currently those are the only
defined names:

           enum {
               host_name(0), (255)
           } NameType;

If there is a need for a more opaque server identity, it could be defined
here.

Mike

From jsalowey@cisco.com  Thu Nov  7 17:11:48 2013
Return-Path: <jsalowey@cisco.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 5428011E815E for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 17:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.58
X-Spam-Level: 
X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 3LMwS1fbXGp0 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 17:11:42 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7898911E8160 for <tls@ietf.org>; Thu,  7 Nov 2013 17:11:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=416; q=dns/txt; s=iport; t=1383873102; x=1385082702; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wNyQKHLxxyZ+GRCQLYbowi+WDaKCPR3RKWJc617yZyI=; b=cVBt+Pvgioji/izEo8e2K5AWc1jCfjRBuPXs9MouY3CJ6nNUViTl6fGQ 55gfnK8hfDu7DnrwahUHj8wBLHG+wkhkgceungn/GAEpZpQ4eg1C9ueei Of/hYqe6k6xwjS4fLyo4+7wGCWepq/LxzuQsSvUKfZIMi3CGjN026d8iY 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAAQ5fFKtJV2d/2dsb2JhbABagweBC8A4FnSCLB0dUQE+QicEiBSbW6FakwCBEAOYDJIKgyaCKg
X-IronPort-AV: E=Sophos;i="4.93,656,1378857600"; d="scan'208";a="282219242"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 08 Nov 2013 01:11:40 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA81BehC011011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tls@ietf.org>; Fri, 8 Nov 2013 01:11:40 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 19:11:39 -0600
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: Working Group Last Call for draft-ietf-tls-pwd
Thread-Index: AQHO3B960CnFA0SYTEinPPth71PTJQ==
Date: Fri, 8 Nov 2013 01:11:39 +0000
Message-ID: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.85.165.166]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <86FD7950F5D95949923667C33024C5E5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Fri, 08 Nov 2013 01:11:48 -0000

This is the beginning of the working group last call for  draft-ietf-tls-pw=
d-01.   The underlying cryptographic protocol for TLS-PWD has been reviewed=
 by the IRTF CFRG group with satisfactory results.  The document needs part=
icular attention paid to the integration of this mechanism into the TLS pro=
tocol.   Please send comments to the TLS list by December 2, 2013. =20

- Joe
(For the TLS chairs)=

From jacob@appelbaum.net  Thu Nov  7 17:52:01 2013
Return-Path: <jacob@appelbaum.net>
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 1A5AC21E814C for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 17:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1]
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 tOeVF7teYRqX for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 17:51:55 -0800 (PST)
Received: from mail-ea0-f171.google.com (mail-ea0-f171.google.com [209.85.215.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0766C11E81BB for <tls@ietf.org>; Thu,  7 Nov 2013 17:51:54 -0800 (PST)
Received: by mail-ea0-f171.google.com with SMTP id h15so608080eak.2 for <tls@ietf.org>; Thu, 07 Nov 2013 17:51:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=aMCFD8XK2oT4p84iQCB1bXmxffn+SaYOYC9GsTA9Y4g=; b=Gdw3Vg/fsQJrwaQMhAOR5s/oikVM1xLam4bBPGx4FGRxa7yKssYklTx/ZZefPw//z2 ZWBIVeiouuJP2Y9wXyuyGpMyIUGeBJViuVYvivXiYB4U41ZD2X57F8y3e7drC+B/bor6 Uhfbw+M6u0Olt2nYTpSj0PGjVvE8fvjK0y//xnkmyBnxUg8ZDt4lY0oLulhLpbt76prS YdsDqBbnunsBsPGv1pTEzOPqKfTFKPxZZumKy2RudnFuI+CG6HA24t4fliCfI2zd1BwQ /cAkCBXs/cU3iS869Qi9ksnOLumninUuNqlk/mQXd2iKZtc6uLHqmloGfudB6gkfWIlO XzOQ==
X-Gm-Message-State: ALoCoQkII01bg0bDZMQOZMJNbgplYzmQW6phKpxKi0/4FoY3cdWJP7tbSTd6FBdv7GmVePD7hNFd
X-Received: by 10.15.75.73 with SMTP id k49mr12741397eey.36.1383875513788; Thu, 07 Nov 2013 17:51:53 -0800 (PST)
Received: from 127.0.0.1 ([37.221.160.203]) by mx.google.com with ESMTPSA id a6sm16336836eei.10.2013.11.07.17.51.50 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 17:51:52 -0800 (PST)
Message-ID: <527BDB0D.5050505@appelbaum.net>
Date: Thu, 07 Nov 2013 18:25:17 +0000
From: Jacob Appelbaum <jacob@appelbaum.net>
MIME-Version: 1.0
To: tls@ietf.org
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <CACsn0c=VWmsfxvE_17+FyBASUXPCNrS1FQQ02fzhF5rA6zx4wQ@mail.gmail.com> <CA+BZK2oAj6FmXTbDoY0oRHpHFVzeN-NmDJde2mJTwOzBW0CdiQ@mail.gmail.com> <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
In-Reply-To: <EEF0FE50-3032-4C7B-BA07-1845CDEDA155@checkpoint.com>
OpenPGP: id=4193A197
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Fri, 08 Nov 2013 01:52:01 -0000

Yoav Nir:
> Hi, Ralf.
> 
> I'm not disagreeing with you regarding 1.3. At least in the long
> version of the handshake (which you should be able to enable in any
> browser, if you want a little more privacy in exchange for an extra
> roundtrip).
> 
> But ordinarily, the sites that can get you killed are not collocated
> with benign sites. 

I disagree. Cloud computing is a good counter example. AppSpot is the
perfect example where there are more benign sites than dangerous sites
and it is easy to use it for interesting tricks.

> And even when sites are collocated, the servers
> demux not based on the SNI parameter in the TLS handshake, but based
> on the Server header in HTTP. The only use of the SNI parameter is
> for selecting the right certificate. So if you try to go to
> https://www.gmail.com , you get a certificate for
> www.gmail.com<http://www.gmail.com> , before being redirected to the
> same server, but this time with the URI https://mail.google.com .
> 

The DPI boxes demux on whatever they can steal off of the wire.

> It would be much nicer if we could update HTTPS (RFC 2818) to support
> this kind of multi-homing so as to make SNI superfluous. For example,
> if the server certificate could list the different domain names that
> it was valid for. Yes, I know there's an economic side to this as
> well. I'm sure the CAs could charge by alternate name if needed.

I agree that RFC 2818 should be updated to reflect these kinds of uses.

All the best,
Jacob

From mrex@sap.com  Thu Nov  7 21:02:51 2013
Return-Path: <mrex@sap.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 AF75E11E81B8 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 21:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.144
X-Spam-Level: 
X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 GU0CWpBqEOd9 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 21:02:46 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1E11E8158 for <tls@ietf.org>; Thu,  7 Nov 2013 21:02:36 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rA852Wab022167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 06:02:32 +0100 (MET)
In-Reply-To: <527BE507.6090507@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Fri, 8 Nov 2013 06:02:32 +0100 (CET)
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: <20131108050232.B8F2A1AA6B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 05:02:51 -0000

Daniel Kahn Gillmor wrote:
> Martin Rex wrote:
>> 
>> But you are aware that there is no such thing as a
>> "confidential DNS lookup" (confidential towards whom anyways),
>> so that in general, what your browser is connecting will be
>> directly preceded by a cleartext DNS lookup with that very name...
> 
> Sure, but that is a bug in DNS, not a bug in TLS, and there are 
> proposals (however farfetched) to work around that, like DNSCurve [0]. 
> But fixing DNS leakage is out-of-scope for this working group.

No need to develop and deploy anthing.
Just switch on IPsec (which allegedly is, according to the IPv6 fanciers,
already deployed everywhere).  This could adequately protect not only
DNS lookups, but also the entire cleartext phase of TLSv1.0/1/2 handshakes.
 
>
> Fixing TLS is in-scope, though, and TLS shouldn't leak information just 
> because other related protocols also leak information.

Don't fix it if it ain't broken.
SNI was specifically DESIGNED to convey the server name in the clear.

Security only works in a meaningful fashion if you can ensure "hygiene",
otherwise it will be expensive obscurity and result in casualties.


> 
> Putting SNI info in an encrypted handshake would make that information 
> unavailable to passive attackers.

This is a dangerious illusion.  As long as SNI will travel in the clear in
protocol versions up to TLSv1.2, it *WILL* leak.  Maybe not from your
client, but someone elses older client going to the same service.

TLSv1.2 (rfc5246) was published in 2008, and its adoption rate is
about as bad as that of IPv6.  The more changes there are proposed
for TLSv1.3, the worse it will fail in the installed base.
TLSv1.2 already is a proven failure and the weakest TLS version
in existence.


-Martin

From mrex@sap.com  Thu Nov  7 21:17:47 2013
Return-Path: <mrex@sap.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 339DD11E8158 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 21:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level: 
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 c3dosWbeu5+j for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 21:17:39 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id CCA9C11E80F5 for <tls@ietf.org>; Thu,  7 Nov 2013 21:17:35 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rA85HX7k024212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 06:17:34 +0100 (MET)
In-Reply-To: <CEA13683.807E%carl@redhoundsoftware.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Date: Fri, 8 Nov 2013 06:17:33 +0100 (CET)
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: <20131108051733.D44D91AA6B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 05:17:47 -0000

Carl Wallace wrote:
> >
> >Interesting -- I'd never noticed that.
> >
> >That being said, proxy certificates are essentially useless unless all
> >clients support them.  In the absence of mandatory support or a client
> >extension indicating acceptance of proxy certificates, they won't be
> >used.
> 
> Of course, but the same goes for notional hybrid server/CA certificates
> too, no?  There is apparently some support for proxy certificates in
> Apache.  I've no idea what it's used for or how well it works though.  

The TLS implementations that have the least excuse for ignoring
what travels in the Server's Certificate TLS handshake
message are the TLS clients -- and TLS clients outnumber TLS servers
by maybe three orders of magnitudes.

What Apache consciously/officially supports might be largely irrelevant
when OpenSSL is used -- because that seems to blissfully send arbitrary
data from two files (cert and chain) provided that the contents
can be ASN.1 decoded as X.509v3 containers.  So whatever the admin
manages to put in these files, Apache will send obediently and with
eyes closed. 

-Martin

From luto@amacapital.net  Thu Nov  7 22:04:55 2013
Return-Path: <luto@amacapital.net>
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 8DCB321E816C for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 22:04:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.883
X-Spam-Level: 
X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.094,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 iS0G4wfZKnQ1 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 22:04:50 -0800 (PST)
Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5567A21E8095 for <tls@ietf.org>; Thu,  7 Nov 2013 22:04:50 -0800 (PST)
Received: by mail-vb0-f53.google.com with SMTP id i11so1074392vbh.26 for <tls@ietf.org>; Thu, 07 Nov 2013 22:04:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=U6okDCmhvqdr+yZFXsu5fUiIo5lccIuJclp9drgoxys=; b=JhDAeeCLDBgHg+rJQ1u2aOzMJ2Szy+H0MJQQj263eca8BSpuDCmmpAu0P9IqOZVKHm CXTlEC9P0UIEqLiS3ov8BBhoZDl96H+OAZ8GGQCc+Ccg+A5EOZhLnySzuZryKVLV3HAP HfD2HZmUR7cs1SO2cxcEwLZ0ij1yRfQ76NkfAl0bJ8Q8w9MGnWlQRefEGlZWtYg7018C MQYaZAsOB3GeS4ikdusVv2gtpS0u1I3Ds8TO2nKcekvZakwGwIGCfaoGzx9LBdQAqt2x gz8oRmO4nAxYXaKJtckbPKWe3yC/Z0byitIO2P/fHNqSbeOEnIPaGyqZtFTAGEGlH9qk 9TLQ==
X-Gm-Message-State: ALoCoQk4UQmpNn3KmrL3Z28vJWYp2pCEWri4zG8FAzqtm36H98nBkwerhlm0mR9QwoYX696qPPcT
X-Received: by 10.52.28.243 with SMTP id e19mr202230vdh.36.1383890689612; Thu, 07 Nov 2013 22:04:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Thu, 7 Nov 2013 22:04:29 -0800 (PST)
In-Reply-To: <20131108051733.D44D91AA6B@ld9781.wdf.sap.corp>
References: <CEA13683.807E%carl@redhoundsoftware.com> <20131108051733.D44D91AA6B@ld9781.wdf.sap.corp>
From: Andy Lutomirski <luto@amacapital.net>
Date: Thu, 7 Nov 2013 22:04:29 -0800
Message-ID: <CALCETrVff+YE8xhDF21LAMQ15xjEoFwnkkRh=DMGhPmQmYOs4g@mail.gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 06:04:55 -0000

On Thu, Nov 7, 2013 at 9:17 PM, Martin Rex <mrex@sap.com> wrote:
> Carl Wallace wrote:
>> >
>> >Interesting -- I'd never noticed that.
>> >
>> >That being said, proxy certificates are essentially useless unless all
>> >clients support them.  In the absence of mandatory support or a client
>> >extension indicating acceptance of proxy certificates, they won't be
>> >used.
>>
>> Of course, but the same goes for notional hybrid server/CA certificates
>> too, no?  There is apparently some support for proxy certificates in
>> Apache.  I've no idea what it's used for or how well it works though.
>
> The TLS implementations that have the least excuse for ignoring
> what travels in the Server's Certificate TLS handshake
> message are the TLS clients -- and TLS clients outnumber TLS servers
> by maybe three orders of magnitudes.
>
> What Apache consciously/officially supports might be largely irrelevant
> when OpenSSL is used -- because that seems to blissfully send arbitrary
> data from two files (cert and chain) provided that the contents
> can be ASN.1 decoded as X.509v3 containers.  So whatever the admin
> manages to put in these files, Apache will send obediently and with
> eyes closed.

This is, I think, mostly irrelevant -- if I know that my clients
understand delegated certificates or proxy certificates or whatever,
then I'll find a way to get my server to send them.

ISTM that, as long as there's momentum behind a developing a better
TLS, it would make sense to use the same version upgrade to improve
the certificate situation.  (Proxy certificates aren't the only big
improvements possible -- a clean way to support DNSSEC-based
certificates would be great, too.)

FWIW, there's precedent for using new TLS versions to expand the set
of allowable certificates.  If I"m reading it correctly, TLS 1.2
allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
will reject those.

--Andy

From watsonbladd@gmail.com  Thu Nov  7 22:34:17 2013
Return-Path: <watsonbladd@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 AA0DB21E81C9 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 22:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level: 
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.053,  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 QiZBXYalvkvo for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 22:34:17 -0800 (PST)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CF7C421E80A1 for <tls@ietf.org>; Thu,  7 Nov 2013 22:34:16 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id t60so1509192wes.40 for <tls@ietf.org>; Thu, 07 Nov 2013 22:34:15 -0800 (PST)
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=QRa8iteksSuc5KT3vXcpvLnHGn4/IWgeW0/EVPG/MI8=; b=fcBJP/5EyjZynz8t+rPTRqau6m4MpvjV91oS/tLmWFxqlkrDCPuSrdtUXuGi4RFBrF Pvh4FkpkhozQ2SYjhJeOEcwrLI+f7sGDJGhnQq2OyfVmpMAK6x6BWi4fy4QkSblH5yhn TB6SS/ajJcgFaGmgclvjX632lXOQhdSvOJjJ/JMYzvIsqrh8i2r+tXBwc+i/hGJ2DSoR tGSvugIewjcTxKXDtwaY1V6QVQQbqvqp3ppRv7FV+h435E8cxLAmyT33dabyPzUa/kpW 6qZoXRfKvTE7CUPZ9qnNPw3ibChK1uwi5bPEZ/7ATt2X2AzPRZy7Yev93gFVnkS60GvM dCKA==
MIME-Version: 1.0
X-Received: by 10.194.93.105 with SMTP id ct9mr10770311wjb.6.1383892455703; Thu, 07 Nov 2013 22:34:15 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 7 Nov 2013 22:34:15 -0800 (PST)
In-Reply-To: <CA+BZK2o411meJDkLwnwOudrkr-G_eWeFx0tirLhUCoSnKsddEg@mail.gmail.com>
References: <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com> <20131107200815.F24AB1AA69@ld9781.wdf.sap.corp> <CA+BZK2o411meJDkLwnwOudrkr-G_eWeFx0tirLhUCoSnKsddEg@mail.gmail.com>
Date: Thu, 7 Nov 2013 22:34:15 -0800
Message-ID: <CACsn0cmoiQph7mSfTxsKs+O-9iRYAVeHcp73tCuVuCyofi5oMg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Fri, 08 Nov 2013 06:34:17 -0000

On Thu, Nov 7, 2013 at 1:39 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> Hi,
>
> For TLS 1.3 there can be a solution that the SNI is never send in clear.
>
> The downgrade attack to TLS 1.2 is possible and would trigger the SNI to be
> send in clear again.
> (It requires an active attack).
Why wasn't this fixed years ago? The client should indicate the
highest offered version when falling back, and the server should
signal if there is a problem. This was an issue with SSL 3.0 and TLS
1.0. It's still an issue today because SSL 3.0 is still out there.
>
> We need the backward compatibility (from TLS 1.3 to TLS 1.2) for the
> foreseeable future. That does not
> mean that we should continue with the same flaws in 1.3 that we have in
> previous TLS versions.
>
> regards,
>
> ralf
>
>
>
> On Thu, Nov 7, 2013 at 8:08 PM, Martin Rex <mrex@sap.com> wrote:
>>
>> Ralf Skyper Kaiser wrote:
>> >
>> > On Thu, Nov 7, 2013 at 7:46 PM, Yoav Nir <ynir@checkpoint.com> wrote:
>> > >
>> > >  IMO, if both sites are either collocated on the same machine, or
>> > > hosted
>> > > behind the same SSL accelerator, they already share enough that
>> > > multi-SAN
>> > > is not a bad thing.
>> > >
>> > >  With SNI is it currently stands, the site you are looking for is sent
>> > > in
>> > > the clear. If we keep the choose-certificate functionality in 1.3, we
>> > > still
>> > > leave it exposed in either the SNI or in the certificate that the
>> > > server
>> > > sends. A generic certificate is the only one that hides what the
>> > > client is
>> > > browsing.
>> > > TLS mailing list
>> > >
>> >
>> > No, SNI can be send encrypted in TLS 1.3 with 'Reduced RT with Privacy'
>> > as
>> > presented by Eric yesterday. Key Exchange is done before SNI is send and
>> > auth is done as last. (What's now cleartext would then require
>> > detectable-active attack).
>>
>> I'm sorry, but I firmly believe this will be pure and useless obscurity
>> coming at a high cost.
>>
>> The amount of "activity" for the attack is minuscule (just tear down
>> the connection when you see the TLSv1.3 client hello -- the client
>> *WILL* reconnect with SNI in the clear.  For the NSA, this is trivial,
>> they're actively doing stuff like this on a regular basis (Foxacid).
>>
>> There are already lots of sites and lots of middle-boxes that cause
>> errors like this in a non-malicious fashion, that "detecting" such
>> an error is only going to annoy users, but not provide any benefit.
>>
>> For those negligible situation where there might be any theoretical
>> benefit at all, it would be possible to define a seperate TLS extension
>> with the properties you're looking for, rather than messing up SNI.
>>
>> -Martin
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From stebila@qut.edu.au  Thu Nov  7 22:50:56 2013
Return-Path: <stebila@qut.edu.au>
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 009E511E8213 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 22:50:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.895
X-Spam-Level: 
X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-4]
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 Kx6MTkoXyesm for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 22:50:51 -0800 (PST)
Received: from qutexedge03.qut.edu.au (qutexedge03.qut.edu.au [131.181.191.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE4C11E81C6 for <tls@ietf.org>; Thu,  7 Nov 2013 22:50:39 -0800 (PST)
Received: from QUTEXHUB03.qut.edu.au (131.181.186.94) by qutexedge03.qut.edu.au (131.181.191.20) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 8 Nov 2013 16:50:37 +1000
Received: from QUTEXMBX01.qut.edu.au ([131.181.107.108]) by QUTEXHUB03.qut.edu.au ([131.181.186.94]) with mapi; Fri, 8 Nov 2013 16:50:37 +1000
From: Douglas Stebila <stebila@qut.edu.au>
To: "<tls@ietf.org>" <tls@ietf.org>
Date: Fri, 8 Nov 2013 16:50:28 +1000
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-pwd
Thread-Index: Ac7cTtRQYZxW8K9BT3mTdG68Ouh4mw==
Message-ID: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
In-Reply-To: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Fri, 08 Nov 2013 06:50:56 -0000

I believe that where possible the IETF should aim to standardize cryptograp=
hic protocols that have provable security results.  Such proofs of course d=
on't guarantee the protocol is secure in all scenarios, but at least rule o=
ut some classes of attacks.  In the field of password authenticated key exc=
hange, there are many provably secure protocols, and so it would be prefera=
ble to see one such protocol adopted.

Douglas


On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> =
wrote:

> This is the beginning of the working group last call for  draft-ietf-tls-=
pwd-01.   The underlying cryptographic protocol for TLS-PWD has been review=
ed by the IRTF CFRG group with satisfactory results.  The document needs pa=
rticular attention paid to the integration of this mechanism into the TLS p=
rotocol.   Please send comments to the TLS list by December 2, 2013. =20
>=20
> - Joe
> (For the TLS chairs)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From mrex@sap.com  Thu Nov  7 23:21:17 2013
Return-Path: <mrex@sap.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 A331321E81A7 for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 23:21:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.153
X-Spam-Level: 
X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 1z1UQem+akne for <tls@ietfa.amsl.com>; Thu,  7 Nov 2013 23:21:12 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4920D11E8145 for <tls@ietf.org>; Thu,  7 Nov 2013 23:21:11 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rA87L9bH013518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 08:21:10 +0100 (MET)
In-Reply-To: <CALCETrVff+YE8xhDF21LAMQ15xjEoFwnkkRh=DMGhPmQmYOs4g@mail.gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 8 Nov 2013 08:21:09 +0100 (CET)
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: <20131108072109.CA6061AA6A@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 07:21:17 -0000

Andy Lutomirski wrote:
> 
> FWIW, there's precedent for using new TLS versions to expand the set
> of allowable certificates.  If I"m reading it correctly, TLS 1.2
> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
> will reject those.

TLSv1.1 will certainly not reject those.
It is only rfc4492 that incorrectly alleges that those should be rejected.

And an implementation of TLSv1.2 client that would accept an ECDSA
EE server cert signed by an RSA cert when TLSv1.2 is negotiated,
but would reject the very same server certificate when TLSv1.1 is
negotiated (but would accept it with TLSv1.1 when a pure ECC
cert path is present) would yield "seriously broken" on my scorecard.

A number of TLS specs are plastered with rfc2119-violating
and therefore bogus and void requirements.

I somewhat optimistic that a number of implementations ignore
those bogus requirements already.  Fixing the remaining implementations
to ignore those bogus requirements might turn out to be easier than
fixing the documents, though...


What I find confusing about rfc4492 is how the hash for digitally-signed
is selected & signalled for TLSv1.0 and TLSv1.1--that seems somewhat
undefined in the document.


But then, using ECDSA with TLS would be pretty suicidal.  (EC)DSA are
an extremly brittle algorithms, i.e. "cryptoglycerin", and while
rfc6979 might help in producing k in constant time, the algorithm
for computing the inverse of k as specified in FIPS 186-4 Appendix C.1
is not a constant-time algorithm, and might leak sufficient "implicit hint"
about k that it makes the signing process "vulnerable to catastrophic
failures" when it is performed inband/online, such as in TLS, where
the server must sign each ServerKeyExchange handshake message inband.


-Martin

From mrex@sap.com  Fri Nov  8 04:32:06 2013
Return-Path: <mrex@sap.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 B1BD611E8147 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 04:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.157
X-Spam-Level: 
X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 CUKkveXBp+XB for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 04:32:01 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E652D21E80BB for <tls@ietf.org>; Fri,  8 Nov 2013 04:31:57 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rA8CVmpA024000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 13:31:48 +0100 (MET)
In-Reply-To: <68078EDD-F924-4AA5-A605-E7B688509EE3@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
Date: Fri, 8 Nov 2013 13:31:48 +0100 (CET)
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: <20131108123148.AFCC01AA70@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 12:32:06 -0000

Yoav Nir wrote:
> 
> With SNI is it currently stands, the site you are looking for is sent in
> the clear. If we keep the choose-certificate functionality in 1.3, we
> still leave it exposed in either the SNI or in the certificate that the
> server sends. A generic certificate is the only one that hides what the
> client is browsing.

Unless you go down the Tor path in its entirety, the site you're
accessing will be fairly close to always trivially distinguishable
by simple traffic analysis (sizes,amount and frequency of requests).

Next protocol will regularly suffer from the very same problem,
characteristic/distinct traffic patterns.

-Martin

From carl@redhoundsoftware.com  Fri Nov  8 04:39:50 2013
Return-Path: <carl@redhoundsoftware.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 2578721F9C3A for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 04:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level: 
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599]
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 nVGGt+zQSF1w for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 04:39:45 -0800 (PST)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9BA21E80BB for <tls@ietf.org>; Fri,  8 Nov 2013 04:39:45 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id v10so2104198pde.29 for <tls@ietf.org>; Fri, 08 Nov 2013 04:39:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=B9pD3eHleg7RoZHR7ztjmyRsbibEHvLZKgKhler9KOg=; b=a+cDaKNcAvB1OIHea0H4ZMtx9+4CQ0bll8Av40B6D5leDlAwOsKhjRn2nOmr5pMe3O DGgoKcXmZn8DuvA2WeE7yHBD1PM7StJP+zi+2/K2Ks0bZQ5U/h/KR4wxSogzRYmsanYS FtOHmq6RP4fuOnocjRZlHFCKqPByLsP6iOzmflkTXYofadN3RUvh2L71Smd+Gn476rb7 tYq4efsq7i761Ho8yIVQtiPcrRMudD9vbVYKikKnIgYJAZBDZMeMXyDAgnuOnkx8NNdP 8PuEwbgZAU588SZa1K1UrHlII8J8u4lBdMhLwCxJ950zv27MAZa2b43GnREY3Yit2ElP t1dg==
X-Gm-Message-State: ALoCoQlXZtdN56HCe8ufolfvKr6m3WOeLHAVEoB4VAbFU0a6Y+ARSuBdoUfd/52sQgSF7TXKdRFY
X-Received: by 10.68.203.164 with SMTP id kr4mr14887971pbc.48.1383914385159; Fri, 08 Nov 2013 04:39:45 -0800 (PST)
Received: from [192.168.0.131] (S01061caff7df80fa.vc.shawcable.net. [24.85.69.194]) by mx.google.com with ESMTPSA id ka3sm11867607pbc.32.2013.11.08.04.39.41 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Nov 2013 04:39:44 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.8.130913
Date: Fri, 08 Nov 2013 04:39:38 -0800
From: Carl Wallace <carl@redhoundsoftware.com>
To: Andy Lutomirski <luto@amacapital.net>, <mrex@sap.com>
Message-ID: <CEA21B4F.8220%carl@redhoundsoftware.com>
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
In-Reply-To: <CALCETrVff+YE8xhDF21LAMQ15xjEoFwnkkRh=DMGhPmQmYOs4g@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 12:39:50 -0000

>
>ISTM that, as long as there's momentum behind a developing a better
>TLS, it would make sense to use the same version upgrade to improve
>the certificate situation.  (Proxy certificates aren't the only big
>improvements possible -- a clean way to support DNSSEC-based
>certificates would be great, too.)

As would end-to-end authentication when proxies are in use:
http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01.



From Johannes.Merkle@secunet.com  Fri Nov  8 06:29:27 2013
Return-Path: <Johannes.Merkle@secunet.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 1633411E8189 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 06:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level: 
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 9Dbk0jIXwyxH for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 06:29:21 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 58DB011E8128 for <tls@ietf.org>; Fri,  8 Nov 2013 06:29:21 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2E3071A0066; Fri,  8 Nov 2013 15:29:19 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 78hEOSsdOIPl; Fri,  8 Nov 2013 15:29:18 +0100 (CET)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 7C5E81A0075; Fri,  8 Nov 2013 15:29:15 +0100 (CET)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 15:29:15 +0100
Message-ID: <527CF53B.7010908@secunet.com>
Date: Fri, 08 Nov 2013 15:29:15 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: mrex@sap.com, Andy Lutomirski <luto@amacapital.net>
References: <20131108072109.CA6061AA6A@ld9781.wdf.sap.corp>
In-Reply-To: <20131108072109.CA6061AA6A@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2013 14:29:15.0871 (UTC) FILETIME=[E6F696F0:01CEDC8E]
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 14:29:27 -0000

>>
>> FWIW, there's precedent for using new TLS versions to expand the set
>> of allowable certificates.  If I"m reading it correctly, TLS 1.2
>> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
>> will reject those.
> 
> TLSv1.1 will certainly not reject those.
> It is only rfc4492 that incorrectly alleges that those should be rejected.

I think you are wrong: Section 7.4.2 of RFC 4346 states

                              Unless otherwise specified, the signing
      algorithm for the certificate MUST be the same as the algorithm
      for the certificate key.


Section 7.4.2 of RFC 5246 states
                                                                  Note
   that this implies that a certificate containing a key for one
   signature algorithm MAY be signed using a different signature
   algorithm (for instance, an RSA key signed with a DSA key).  This is
   a departure from TLS 1.1, which required that the algorithms be the
   same.

Johannes


From Johannes.Merkle@secunet.com  Fri Nov  8 06:37:07 2013
Return-Path: <Johannes.Merkle@secunet.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 0302521E8113 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 06:37:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.548
X-Spam-Level: 
X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ty734nq4443e for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 06:36:57 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9A58A21E8154 for <tls@ietf.org>; Fri,  8 Nov 2013 06:36:57 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id E1D071A006F; Fri,  8 Nov 2013 15:36:56 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d5L0Sv2wMhAn; Fri,  8 Nov 2013 15:36:55 +0100 (CET)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id D3F781A0066; Fri,  8 Nov 2013 15:36:55 +0100 (CET)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 15:36:56 +0100
Message-ID: <527CF707.2070000@secunet.com>
Date: Fri, 08 Nov 2013 15:36:55 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Andy Lutomirski <luto@amacapital.net>, "tls@ietf.org" <tls@ietf.org>
References: <527BEF5E.8070704@amacapital.net>
In-Reply-To: <527BEF5E.8070704@amacapital.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2013 14:36:56.0239 (UTC) FILETIME=[F95D2BF0:01CEDC8F]
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 14:37:07 -0000

> It would be a departure from established practice, but, if certificate
> #3 permits signing, then there's nothing insecure about this certificate
> chain.  Whoever has the private key associated with certificate #3 is
> permitted to host the domains described by the common name and
> subjectAltNames of #3 (and subdomains if it's a wildcard), so, if
> they're willing to delegate authority to certificate #4, they should be
> able to.

It is a bad idea to introduce violations of PKIX standards (RFC 5280) in TLS  1.3.



-- 
Johannes

From skyper@thc.org  Fri Nov  8 07:28:51 2013
Return-Path: <skyper@thc.org>
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 6096621E819C for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 07:28:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.353
X-Spam-Level: 
X-Spam-Status: No, score=-0.353 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 XjPVQ2DylfdH for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 07:28:47 -0800 (PST)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 117D221E81AC for <tls@ietf.org>; Fri,  8 Nov 2013 07:28:47 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so166570iet.20 for <tls@ietf.org>; Fri, 08 Nov 2013 07:28:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kpWWrxOGuR59+jXvY8uJ3AOq1HQyaGGeR948q089onQ=; b=RDxViP0ePvPLbYuuUsuRtKCtNPvHI68C7oHuBE6M9J8yZAS/EnlilwlgleZ8hx6f08 YGtIJ+DLO3vSUYiS6xmqH5fRNgwedBbrUuvEcOhBvL2Pib5YIpG6NwThoLSQjnZT1H68 jdvWD3QZ4jNbcT25qrM9LPG/LuxvNorDNAVLw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kpWWrxOGuR59+jXvY8uJ3AOq1HQyaGGeR948q089onQ=; b=PP/nF60zzcVRCe3i5XUzRd7SQzxQ/uEwxvsHw1NsJjBxP7t4AOzn+sNV3W18tRtvF6 XyuVHJP4iDmDx4QVh+H5lehcBCAXI5k10ZEt9/BAIkrJ7WTNbbJevxneR23NBofyE4bI +pJG0SHs8WBvPvoX31Gcfvd2zMf8uQvGDnXv2MInbRFkEJNQdlYcn+ZRcMfCTAH5QDRR FMmY+LNuHA1OWlX80ktf4iHQwW3qnWyCXZaaieSrl9DBT7iwXmBiAT/qsZ2S7S6uT6tK q/9dnpU9U72jsl3yUsCw7JRjSUVumHO4kYfOlzAk00GZqEPExEDq53eSGfCx1FW21eip Hetg==
X-Gm-Message-State: ALoCoQkPuHtr6kHAz9MZ/PGgJA1cCEmwq1K6a5GwGoMVuQpde1RdJL1IWS3gMLLsEuvcIBaIHqih
MIME-Version: 1.0
X-Received: by 10.43.93.5 with SMTP id bs5mr9082489icc.32.1383924526196; Fri, 08 Nov 2013 07:28:46 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Fri, 8 Nov 2013 07:28:46 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <20131108050232.B8F2A1AA6B@ld9781.wdf.sap.corp>
References: <527BE507.6090507@fifthhorseman.net> <20131108050232.B8F2A1AA6B@ld9781.wdf.sap.corp>
Date: Fri, 8 Nov 2013 15:28:46 +0000
Message-ID: <CA+BZK2onJUrHPegXwO4TWVaj-tirBnpXxEY32T_VA4SZDcnhJA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=bcaec519691dc8591f04eaac0932
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Fri, 08 Nov 2013 15:28:51 -0000

--bcaec519691dc8591f04eaac0932
Content-Type: text/plain; charset=ISO-8859-1

Hi


On Fri, Nov 8, 2013 at 5:02 AM, Martin Rex <mrex@sap.com> wrote:

> >
> > Fixing TLS is in-scope, though, and TLS shouldn't leak information just
> > because other related protocols also leak information.
>
> Don't fix it if it ain't broken.
> SNI was specifically DESIGNED to convey the server name in the clear.
>
> Security only works in a meaningful fashion if you can ensure "hygiene",
> otherwise it will be expensive obscurity and result in casualties.
>

SNI was NOT DESIGNED to be convey the server name in clear. SNI was
designed so that the server can pick the right certificate.

SNI can be transmitted encrypted and should be transmitted encrypted (see
recent plenary sessions at IETF88).


> Putting SNI info in an encrypted handshake would make that information
> > unavailable to passive attackers.
>
> This is a dangerious illusion.  As long as SNI will travel in the clear in
> protocol versions up to TLSv1.2, it *WILL* leak.  Maybe not from your
> client, but someone elses older client going to the same service.
>

Martin, with your argument why should we fix anything at all in any product
or design?

The proposed solution FIXES passive pervasive surveillance in TLS 1.3.

Your proposal fixes nothing, keeps an identified and acknowledged security
flaw in TLS 1.3 and enables passive pervasive surveillance.

Let's make pervasive passive surveillance harder.

Your other concerns that there other ways how an attacker can get the host
name are noted and are out-of-scope for the TLS-WG (yes, the NSA can even
get a FISA order...but we wont fix that one either....and enabling IPSEC
does not scale (yet)).


regards,

ralf

--bcaec519691dc8591f04eaac0932
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi<br><div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Fri, Nov 8, 2013 at 5:02 AM, Martin Rex <span dir=3D"lt=
r">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt;<br><div class=3D"im">
&gt; Fixing TLS is in-scope, though, and TLS shouldn&#39;t leak information=
 just<br>
&gt; because other related protocols also leak information.<br>
<br>
</div>Don&#39;t fix it if it ain&#39;t broken.<br>
SNI was specifically DESIGNED to convey the server name in the clear.<br>
<br>
Security only works in a meaningful fashion if you can ensure &quot;hygiene=
&quot;,<br>
otherwise it will be expensive obscurity and result in casualties.<br></blo=
ckquote><div><br></div><div>SNI was NOT DESIGNED to be convey the server na=
me in clear. SNI was designed so that the server can pick the right certifi=
cate. <br>
<br>SNI can be transmitted encrypted and should be transmitted encrypted (s=
ee recent plenary sessions at IETF88).<br><br></div><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div class=3D"im">
&gt; Putting SNI info in an encrypted handshake would make that information=
<br>
&gt; unavailable to passive attackers.<br>
<br>
</div>This is a dangerious illusion. =A0As long as SNI will travel in the c=
lear in<br>
protocol versions up to TLSv1.2, it *WILL* leak. =A0Maybe not from your<br>
client, but someone elses older client going to the same service.<br></bloc=
kquote></div><br></div><div class=3D"gmail_extra">Martin, with your argumen=
t why should we fix anything at all in any product or design? <br><br></div=
>
<div class=3D"gmail_extra">The proposed solution FIXES passive pervasive su=
rveillance in TLS 1.3.<br><br></div><div class=3D"gmail_extra">Your proposa=
l fixes nothing, keeps an identified and acknowledged security flaw in TLS =
1.3 and enables passive pervasive surveillance.<br>
<br></div><div class=3D"gmail_extra">Let&#39;s make pervasive passive surve=
illance harder.<br><br></div><div class=3D"gmail_extra">Your other concerns=
 that there other ways how an attacker can get the host name are noted and =
are out-of-scope for the TLS-WG (yes, the NSA can even get a FISA order...b=
ut we wont fix that one either....and enabling IPSEC does not scale (yet)).=
<br>
</div><div class=3D"gmail_extra"><br><br>regards,<br><br>ralf<br><br>=A0<br=
></div><br></div></div>

--bcaec519691dc8591f04eaac0932--

From frantz@pwpconsult.com  Fri Nov  8 07:56:36 2013
Return-Path: <frantz@pwpconsult.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 C97E311E8240 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 07:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 XZmuvKMvA73v for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 07:56:31 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id D198B11E81AB for <tls@ietf.org>; Fri,  8 Nov 2013 07:56:31 -0800 (PST)
Received: from [173.185.171.74] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1VeoQ9-0005Km-0x; Fri, 08 Nov 2013 10:56:30 -0500
Date: Fri,  8 Nov 2013 07:56:26 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
X-Priority: 3
In-Reply-To: <527CF707.2070000@secunet.com>
Message-ID: <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec796dfbec18f035d936775da4b21fb8c64b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.185.171.74
Cc: tls@ietf.org, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 15:56:36 -0000

On 11/8/13 at 6:36 AM, johannes.merkle@secunet.com (Johannes Merkle) wrote:

> > It would be a departure from established practice, but, if certificate
> > #3 permits signing, then there's nothing insecure about this certificat=
e
> > chain.  Whoever has the private key associated with certificate #3 is
> > permitted to host the domains described by the common name and
> > subjectAltNames of #3 (and subdomains if it's a wildcard), so, if
> > they're willing to delegate authority to certificate #4, they should be
> > able to.
>=20
> It is a bad idea to introduce violations of PKIX standards (RFC 5280) in =
TLS  1.3.

Please explain why.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Concurrency is hard. 12 out  | Periwinkle
(408)356-8506      | 10 programmers get it wrong. | 16345 Englewood Ave
www.pwpconsult.com |                - Jeff Frantz | Los Gatos, CA 95032


From rsalz@akamai.com  Fri Nov  8 08:16:21 2013
Return-Path: <rsalz@akamai.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 1AE3521E809B for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 LaU3UxVCH+wg for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:16:16 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 036C511E8153 for <tls@ietf.org>; Fri,  8 Nov 2013 08:16:16 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 730121655F8; Fri,  8 Nov 2013 16:16:15 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 662CD165537; Fri,  8 Nov 2013 16:16:15 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 479CC2FD60; Fri,  8 Nov 2013 16:16:15 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 8 Nov 2013 11:16:14 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Bill Frantz <frantz@pwpconsult.com>, Johannes Merkle <johannes.merkle@secunet.com>
Date: Fri, 8 Nov 2013 11:16:13 -0500
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
Thread-Index: Ac7cmyB3cQYsetYxSg6MrAD7RoLe0wAAkwiA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local>
In-Reply-To: <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 16:16:21 -0000

> > It is a bad idea to introduce violations of PKIX standards (RFC 5280) i=
n TLS  1.3.

> Please explain why.

TLS uses certificates.  Certificates use the CA structure.  The CA structur=
e has a particular trust model.  PKIX [dr]efines an instance of that trust =
model. PKIX is used throughout the Internet when X.509 certificates are use=
d, almost exclusively.  It is hard to write trust-path code and get it righ=
t. Adding a new complexity for this one special case (even if it is a major=
 user) makes library re-use harder, and is could well make all certificate-=
using software on the same computer open to buggy and/or confusing behavior=
.

"If you want PGP you know where to get it."

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA

From mrex@sap.com  Fri Nov  8 08:34:54 2013
Return-Path: <mrex@sap.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 92D4E21F9FF6 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.161
X-Spam-Level: 
X-Spam-Status: No, score=-10.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 uitFOY5ErXhp for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:34:42 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8778811E8165 for <tls@ietf.org>; Fri,  8 Nov 2013 08:34:40 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rA8GYWHn000355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 17:34:32 +0100 (MET)
In-Reply-To: <527CF53B.7010908@secunet.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Date: Fri, 8 Nov 2013 17:34:32 +0100 (CET)
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: <20131108163432.AE6371AA71@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 16:34:55 -0000

Johannes Merkle wrote:
> 
> >>
> >> FWIW, there's precedent for using new TLS versions to expand the set
> >> of allowable certificates.  If I"m reading it correctly, TLS 1.2
> >> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
> >> will reject those.
> > 
> > TLSv1.1 will certainly not reject those.
> > It is only rfc4492 that incorrectly alleges that those should be rejected.
> 
> I think you are wrong: Section 7.4.2 of RFC 4346 states
> 
>                               Unless otherwise specified, the signing
>       algorithm for the certificate MUST be the same as the algorithm
>       for the certificate key.

The history of this obvious defect starts in rfc2246.

There exists no such artificial limitation in SSLv3, and when I looked
at implementations I've been using for interop testing a few
years ago (Microsoft SChannel, OpenSSL, Firefox), they would
happily interoperate with an RSA server cert signed by a CA with a
DSA key.  To me it looks like most implementors were either not
aware of this bogus, backwards-incompatible requirement,
or they applied common sense and deliberately ignored it.

One can not "violate" rfc2119 Section 6 more than with the above
statement, so it is null and void.

Not only is this method "must be the same algorithm" not required
for interop, it is the the worst possible way to impair interop
without a cause.


-Martin

From prvs=4024cee193=uri@ll.mit.edu  Fri Nov  8 08:35:47 2013
Return-Path: <prvs=4024cee193=uri@ll.mit.edu>
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 4D5E011E81CA for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level: 
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 2DMQyLRfg95f for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:35:39 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7647211E8102 for <tls@ietf.org>; Fri,  8 Nov 2013 08:35:35 -0800 (PST)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id rA8GW6qV003169; Fri, 8 Nov 2013 11:35:29 -0500
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: Douglas Stebila <stebila@qut.edu.au>, "<tls@ietf.org>" <tls@ietf.org>
Date: Fri, 8 Nov 2013 11:35:16 -0500
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-pwd
Thread-Index: Ac7coIPgv2200VnRTWWurB4rxXqEJA==
Message-ID: <CEA27C78.1375B%uri@ll.mit.edu>
In-Reply-To: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3466755316_41033349"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-08_07:2013-11-08, 2013-11-08, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311080095
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Fri, 08 Nov 2013 16:35:49 -0000

--B_3466755316_41033349
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 11/8/13 1:50 , "Douglas Stebila" <stebila@qut.edu.au> wrote:

>I believe that where possible the IETF should aim to standardize
>cryptographic protocols that have provable security results.  Such proofs
>of course don't guarantee the protocol is secure in all scenarios, but at
>least rule out some classes of attacks.  In the field of password
>authenticated key exchange, there are many provably secure protocols, and
>so it would be preferable to see one such protocol adopted.

I concur - except I believe that whenever possible the IETF should aim to
standardize cryptographic protocols that are unencumbered by license fees
and patents. If the choice arises between a protocol that carries both
(provable security and Intellectual Property) and a protocol that has
neither - I'd strongly prefer the latter.



>On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)
><jsalowey@cisco.com> wrote:
>
>> This is the beginning of the working group last call for
>>draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>>TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
>>results.  The document needs particular attention paid to the
>>integration of this mechanism into the TLS protocol.   Please send
>>comments to the TLS list by December 2, 2013.
>> 
>> - Joe
>> (For the TLS chairs)
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

--B_3466755316_41033349
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD
F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0
B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p
rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr
i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8
11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB
BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw
PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/
inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd
XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq
oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5
48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ
/Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw
ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J
VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v
dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w
HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT
Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg
MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK
Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2
QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z
XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK
sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn
qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G
CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny
bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG
MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3
EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G
CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk
zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm
UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD
2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU
meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB
snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw
CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD
UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz
NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx
DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv
f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT
XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/
hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX
TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW
6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y
EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G
CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I
1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P
yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/
LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr
oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90
ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw
EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL
MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT
BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X
519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb
z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn
w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3
sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8
B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD
VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH
AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ
KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC
AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn
+t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f
NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU
3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ
aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw
ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv
cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg
hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCA1zSiRZPfn1hD6qDN2BfBY/nWztUQXWjOA
l0NYuR7VuTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEx
MDgxNjM1MTZaMA0GCSqGSIb3DQEBAQUABIIBALzl2BnuSyRAa5DI85Y/jQmHWJcRXkOE9Mcz
WqQJfC7/9wplkADOa5D2tjTOhhvw/A4ewdAk3eoXZlHi7ic4kTbNy7B+oBhsXwx2IdLkYsWb
XV/RkbafhkN8vht+Al26UVF8MLznqkxPt/JbdF0KZYl8f9euN3PAYIQkPAdIkDMl5GBh2jA6
UlqVcw9SZ3bre1GOImi0yFqj8/p18t8E49BF6M3YPPaeu7ZXQlMHxW6tym0iTLO7U9xcy2HQ
8GdMxxErQqC+uQQUId1yLLlpUMZ6JM1j8n2N/06Ue6q056KNOQLk8ISHpBniV94zWYxmeuJ5
CaYhdkJOWDXocuhuQjM=

--B_3466755316_41033349--

From luto@amacapital.net  Fri Nov  8 08:37:55 2013
Return-Path: <luto@amacapital.net>
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 68FF721E81AC for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.907
X-Spam-Level: 
X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 bIjU81Skuwv3 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:37:39 -0800 (PST)
Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8328221E8183 for <tls@ietf.org>; Fri,  8 Nov 2013 08:37:27 -0800 (PST)
Received: by mail-ve0-f177.google.com with SMTP id jz11so413477veb.36 for <tls@ietf.org>; Fri, 08 Nov 2013 08:37:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=chMpFuSlmzuPq/5ad0KK/RyrApC3C959MAt4Xnwcaic=; b=VYE5A9aiVvpE0MGA6JK0iOXsGi99XDe8IkbqfzHYpuhh4DkxQTjF/2huEs63rOwWCh I2/0ECbceKKa13V2sA2xha/cTwBDbn4C9fsh2oPfTirMp0p6dJI2ZDFPwfLhYUzitaAI EkPwz+lQwMLQ/nN9P1vplq+71hEW7Ovj98VmxrBt6YBds23cz5AMqZilMC/ZQdf/B/Zu wV+SRjTNxKsk0KMDqmfgqdXXQsuH3638utRNZDOmtQYecjrbK7eP3rkdeG12bUW3MJyG r0DnmIT17+ScWkE8fV3kXqxuxrm4oyeBjazr2Ty/Qc/+VhRiUwFK2/HF9foF78ctHy5I GvzQ==
X-Gm-Message-State: ALoCoQmqPUrH6IHR9whP4CE5j2U2GMnICAG1n+Qfnrh9/DC2aV2Yvh/U2jBvcHZEFQfP8t9HTfmX
X-Received: by 10.220.10.70 with SMTP id o6mr102570vco.45.1383928646139; Fri, 08 Nov 2013 08:37:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Fri, 8 Nov 2013 08:37:06 -0800 (PST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 8 Nov 2013 08:37:06 -0800
Message-ID: <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 16:37:55 -0000

On Fri, Nov 8, 2013 at 8:16 AM, Salz, Rich <rsalz@akamai.com> wrote:
>> > It is a bad idea to introduce violations of PKIX standards (RFC 5280) =
in TLS  1.3.
>
>> Please explain why.
>
> TLS uses certificates.  Certificates use the CA structure.  The CA struct=
ure has a particular trust model.  PKIX [dr]efines an instance of that trus=
t model. PKIX is used throughout the Internet when X.509 certificates are u=
sed, almost exclusively.  It is hard to write trust-path code and get it ri=
ght. Adding a new complexity for this one special case (even if it is a maj=
or user) makes library re-use harder, and is could well make all certificat=
e-using software on the same computer open to buggy and/or confusing behavi=
or.
>

This doesn't necessarily need to change the PKIX validation algorithm
at all [1].  Rather than presenting a proxy certificate, the server
could present a standard (valid according to PKIX / TLS 1.2 rules)
certificate and *separately* present a chain of public keys, each
signed by the previous one and marked with validity times, where the
first public key is signed by the server certificate and the last
public key is compatible with the key exchange algorithm.  (To keep it
simple, the allowable final key types could be limited to fixed DH
parameters and RSA/ECDSA signing keys -- there's no reason to support
traditional RSA key exchange here.)

None of this needs to be in X.509 format.  An advantage of *not* using
X.509 is that libraries can't make the mistake of asking clients to
validate these keypairs -- clients should validate the actual PKIX
certificate instead.

There's no need for revocation, OSCP stapling, or related mechanisms
-- the validity periods can be kept short enough that a validly signed
key is equivalent to a valid, fresh OCSP response.

This is a lot like how QUIC works.  I think Google got that part of
the protocol right.

Of course, the downside of this approach is that it's a much more
intrusive change in the TLS protocol (proxy certificates don't require
any protocol change except some indication from the client that it
accepts proxy certificates).

--Andy

From rsalz@akamai.com  Fri Nov  8 08:45:58 2013
Return-Path: <rsalz@akamai.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 2288811E8189 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 koGiObE3ZT5g for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:45:50 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9F611E80E6 for <tls@ietf.org>; Fri,  8 Nov 2013 08:45:34 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 928734810F; Fri,  8 Nov 2013 16:45:20 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 86A2E4810D; Fri,  8 Nov 2013 16:45:20 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 6D74547BE0; Fri,  8 Nov 2013 16:45:20 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 8 Nov 2013 11:45:19 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 8 Nov 2013 11:45:18 -0500
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
Thread-Index: Ac7coM+SnuUVj2jGRa2zRJ9igrLhkwAAB39g
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com> <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com>
In-Reply-To: <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 16:45:58 -0000

> Rather than presenting a proxy certificate, the server could present a st=
andard (valid according to PKIX / TLS 1.2 rules) certificate and *separatel=
y* present a chain of public keys, ... None of this needs to be in X.509 fo=
rmat.

I'm curious what this new and different but similar structure would be like=
.   And whether the intended use of this stuff justifies the complexity and=
 creation of all this new stuff, or breaking PKIX compatibility.

I think one way to not break with PKIX is to define a new extendedKeyUsage =
attribute that says "can sign short-term SSL cert chains"

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA

From mrex@sap.com  Fri Nov  8 08:52:25 2013
Return-Path: <mrex@sap.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 4061011E8186 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.164
X-Spam-Level: 
X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 LgHlp4kQ0ujJ for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:52:21 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B611E8168 for <tls@ietf.org>; Fri,  8 Nov 2013 08:52:20 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rA8GqILw009880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Nov 2013 17:52:18 +0100 (MET)
In-Reply-To: <527CF707.2070000@secunet.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Date: Fri, 8 Nov 2013 17:52:18 +0100 (CET)
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: <20131108165218.1EEB01AA71@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Nov 2013 16:52:25 -0000

Johannes Merkle wrote:
> 
>> It would be a departure from established practice, but, if certificate
>> #3 permits signing, then there's nothing insecure about this certificate
>> chain.  Whoever has the private key associated with certificate #3 is
>> permitted to host the domains described by the common name and
>> subjectAltNames of #3 (and subdomains if it's a wildcard), so, if
>> they're willing to delegate authority to certificate #4, they should be
>> able to.
> 
> It is a bad idea to introduce violations of PKIX standards
> (RFC 5280) in TLS  1.3.

It is actually not a violation of PKIX.  However, behaviour is undefined.

PKIX (rfc5280) inherited this from X.509, and it has been spelled out
in rfc5280-clarifications:

  http://tools.ietf.org/html/rfc6818#section-2

  2. Update to RFC 5280, Section 3.2: "Certification Paths and Trust"


     Add the following paragraph to the end of RFC 5280, Section 3.2:

  | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
  | that use of self-issued certificates and self-signed certificates
  | issued by entities other than CAs are outside the scope of this
  | specification.  Thus, for example, a web server or client might
  | generate a self-signed certificate to identify itself.  These
  | certificates and how a relying party uses them to authenticate
  | asserted identities are both outside the scope of RFC 5280.


"outside the scope of rfc5280".

which essentially means that TLSv1.3 could actually specify
whatever semantics it sees fit.  The problem that may arise, however
is that passing a certification path with such a
"self-issued certificate issued by an entity other than a CA"
to a _vanilla_ PKIX/rfc5280 or X.509 certificate path validation
function might not give you the result that you may be looking
for, likely applying CA checks on the end entity cert above
the proxy cert and aborting path validation with an error.


-Martin

From Johannes.Merkle@secunet.com  Fri Nov  8 08:56:02 2013
Return-Path: <Johannes.Merkle@secunet.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 3D00721E80ED for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Level: 
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=-0.251,  BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1]
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 7gOPNXkBR97j for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 08:55:53 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 73A6A21E819D for <tls@ietf.org>; Fri,  8 Nov 2013 08:55:47 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id B54E01A006F; Fri,  8 Nov 2013 17:55:45 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TMGM9n5v_FhU; Fri,  8 Nov 2013 17:55:44 +0100 (CET)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id AE11B1A0066; Fri,  8 Nov 2013 17:55:44 +0100 (CET)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 17:55:44 +0100
Message-ID: <527D1790.8010108@secunet.com>
Date: Fri, 08 Nov 2013 17:55:44 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>,  Andy Lutomirski <luto@amacapital.net>
References: <527CF707.2070000@secunet.com>	<r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local>	<2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com>	<CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2013 16:55:44.0899 (UTC) FILETIME=[5DA1D530:01CEDCA3]
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 16:56:02 -0000

> 
> I think one way to not break with PKIX is to define a new extendedKeyUsage attribute that says "can sign short-term SSL cert chains"

not breaking PKIX means that basic contraints must be set to CA=TRUE. Furthermore, the new EKU would have to be limited
t a particular domain.

Another way not to break PKIX would be to use the PKIX standard mechanism mentioned by Andy: CA certificates with name
constraints. If this was required to be supported in TLS 1.3  why should it be less likely to work in practice than a
completely new concept?



-- 
Johannes

From seonghan.shin@aist.go.jp  Fri Nov  8 09:04:05 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 2013111E8168 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.601
X-Spam-Level: 
X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751]
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 iZD11jq+G5-d for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:04:00 -0800 (PST)
Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 62B3111E80DC for <tls@ietf.org>; Fri,  8 Nov 2013 09:03:56 -0800 (PST)
Received: from mail-la0-f52.google.com ([209.85.215.52]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKUn0Zey2UBSPBttxNfmBdxIcQ3bUnAWrl@postini.com; Fri, 08 Nov 2013 09:03:56 PST
Received: by mail-la0-f52.google.com with SMTP id ev20so1983080lab.11 for <tls@ietf.org>; Fri, 08 Nov 2013 09:03:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h6qK3JYc1xeBIK2vHTdtElPDKIWioifFeZGEGCgg9LA=; b=Vi1tNawwxTnPXug5SnIYGcR4sYVaXsatIwsAspkGd8GEL8SPyZWP5N/23h2Hw773ws 8yVN6IbqvA4hlpVTdkWzOAep98xZFFEBgznjM5Faqf0zIYunJa1qCibnNlPdiNVEwgu3 FH9Uz65lO83sIkzeppxriO7oFiEUWTFiDoS/Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h6qK3JYc1xeBIK2vHTdtElPDKIWioifFeZGEGCgg9LA=; b=aglsi5RFgqWBXgGMQXPHtLW6GgWkBaPw3D0xTNXxkzcufYNsA2QrRrdyzWLv1G1qKx OqpSVAy23aAvSEkmBO9mOIpGZXpgzWeXtDqwqnByXJuAQbyxMwduShYLUAuY8ZUbpkgS XiP3N7offOXkfhyynblIJoOIG3cDvrlS/un88aksBOysuBC5hvUGtpsJ5YbKguEGcfJt +B7E+gBfzA5LZfH9cmnvmcV0YxLANT8G4u8cG9xv+a5uOAHpD2mnNRIG6Dmd7pIHvg1J xxuijGNsFVcadbjT4ifsdpDwdUJ0SaTDKMoyvrqrHr7rB+Ie8os/Y33sMUkdpLX+K+VX 44cg==
X-Gm-Message-State: ALoCoQnHTYZg+LJ4zqarAQAhz9jvBVbIyVo6wHLdsb4lpTjhgmaD6VUZLBZGqEKdAZwSiV/OeqigJg4jE9XJtE98ZhiLuM8Uh32WZDQwmCGtWci/zePkZiwMUnT1+1ybzPETcOxfHjGfG4GF4ycsfsEa8OOMZJNbig==
X-Received: by 10.152.243.11 with SMTP id wu11mr1543046lac.42.1383930231301; Fri, 08 Nov 2013 09:03:51 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.243.11 with SMTP id wu11mr1543036lac.42.1383930231144; Fri, 08 Nov 2013 09:03:51 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Fri, 8 Nov 2013 09:03:51 -0800 (PST)
In-Reply-To: <CEA27C78.1375B%uri@ll.mit.edu>
References: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CEA27C78.1375B%uri@ll.mit.edu>
Date: Sat, 9 Nov 2013 02:03:51 +0900
Message-ID: <CAEKgtqk6D+q6-4Jb0afu2O9qRq=mE5_T_5UNrst2_BLmqVTFJw@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: "<tls@ietf.org>" <tls@ietf.org>, "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary=001a11340c26d2641404eaad5dc9
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Fri, 08 Nov 2013 17:04:05 -0000

--001a11340c26d2641404eaad5dc9
Content-Type: text/plain; charset=ISO-8859-1

FYI,
AugPAKE is provably secure and can be used royal-free.
AugPAKE
https://tools.ietf.org/html/draft-shin-tls-augpake-01
IPR Disclosures
https://datatracker.ietf.org/ipr/2037/

Regards,
Shin



On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <
uri@ll.mit.edu> wrote:

> On 11/8/13 1:50 , "Douglas Stebila" <stebila@qut.edu.au> wrote:
>
> >I believe that where possible the IETF should aim to standardize
> >cryptographic protocols that have provable security results.  Such proofs
> >of course don't guarantee the protocol is secure in all scenarios, but at
> >least rule out some classes of attacks.  In the field of password
> >authenticated key exchange, there are many provably secure protocols, and
> >so it would be preferable to see one such protocol adopted.
>
> I concur - except I believe that whenever possible the IETF should aim to
> standardize cryptographic protocols that are unencumbered by license fees
> and patents. If the choice arises between a protocol that carries both
> (provable security and Intellectual Property) and a protocol that has
> neither - I'd strongly prefer the latter.
>
>
>
> >On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)
> ><jsalowey@cisco.com> wrote:
> >
> >> This is the beginning of the working group last call for
> >>draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
> >>TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
> >>results.  The document needs particular attention paid to the
> >>integration of this mechanism into the TLS protocol.   Please send
> >>comments to the TLS list by December 2, 2013.
> >>
> >> - Joe
> >> (For the TLS chairs)
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >_______________________________________________
> >TLS mailing list
> >TLS@ietf.org
> >https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a11340c26d2641404eaad5dc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>FYI,<br></div>AugPAKE is provably secure and can=
 be used royal-free.<br>AugPAKE<br><a href=3D"https://tools.ietf.org/html/d=
raft-shin-tls-augpake-01">https://tools.ietf.org/html/draft-shin-tls-augpak=
e-01</a><br>
</div>IPR Disclosures<br><div><a href=3D"https://datatracker.ietf.org/ipr/2=
037/">https://datatracker.ietf.org/ipr/2037/</a><br><br></div><div>Regards,=
<br></div><div>Shin<br><br></div></div><div class=3D"gmail_extra"><br><br><=
div class=3D"gmail_quote">
On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <span dir=3D=
"ltr">&lt;<a href=3D"mailto:uri@ll.mit.edu" target=3D"_blank">uri@ll.mit.ed=
u</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On 11/8/13 1:50 , &quot;Douglas Stebila&quot; &lt;<a href=
=3D"mailto:stebila@qut.edu.au">stebila@qut.edu.au</a>&gt; wrote:<br>
<br>
&gt;I believe that where possible the IETF should aim to standardize<br>
&gt;cryptographic protocols that have provable security results. =A0Such pr=
oofs<br>
&gt;of course don&#39;t guarantee the protocol is secure in all scenarios, =
but at<br>
&gt;least rule out some classes of attacks. =A0In the field of password<br>
&gt;authenticated key exchange, there are many provably secure protocols, a=
nd<br>
&gt;so it would be preferable to see one such protocol adopted.<br>
<br>
</div>I concur - except I believe that whenever possible the IETF should ai=
m to<br>
standardize cryptographic protocols that are unencumbered by license fees<b=
r>
and patents. If the choice arises between a protocol that carries both<br>
(provable security and Intellectual Property) and a protocol that has<br>
neither - I&#39;d strongly prefer the latter.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
&gt;On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)<br>
&gt;&lt;<a href=3D"mailto:jsalowey@cisco.com">jsalowey@cisco.com</a>&gt; wr=
ote:<br>
&gt;<br>
&gt;&gt; This is the beginning of the working group last call for<br>
&gt;&gt;draft-ietf-tls-pwd-01. =A0 The underlying cryptographic protocol fo=
r<br>
&gt;&gt;TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory<=
br>
&gt;&gt;results. =A0The document needs particular attention paid to the<br>
&gt;&gt;integration of this mechanism into the TLS protocol. =A0 Please sen=
d<br>
&gt;&gt;comments to the TLS list by December 2, 2013.<br>
&gt;&gt;<br>
&gt;&gt; - Joe<br>
&gt;&gt; (For the TLS chairs)<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; TLS mailing list<br>
&gt;&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;TLS mailing list<br>
&gt;<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div><br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"MARGI=
N:0mm 0mm 0pt"><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;FONT-SIZE:=
10pt" lang=3D"EN-US">------------------------------------------------------=
------------<br>
SeongHan Shin<br></span><span style=3D"FONT-FAMILY:&#39;MS UI Gothic&#39;;F=
ONT-SIZE:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div>

--001a11340c26d2641404eaad5dc9--

From Johannes.Merkle@secunet.com  Fri Nov  8 09:21:44 2013
Return-Path: <Johannes.Merkle@secunet.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 E70BB21E812C for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:21:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.54
X-Spam-Level: 
X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 afWKuuQIXDjD for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:21:28 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA911E81E4 for <tls@ietf.org>; Fri,  8 Nov 2013 09:21:28 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7CA331A006F; Fri,  8 Nov 2013 18:21:27 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id veKMQLTFcQFu; Fri,  8 Nov 2013 18:21:25 +0100 (CET)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id A57F71A0071; Fri,  8 Nov 2013 18:21:17 +0100 (CET)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Nov 2013 18:21:17 +0100
Message-ID: <527D1D8D.6090904@secunet.com>
Date: Fri, 08 Nov 2013 18:21:17 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20131108165218.1EEB01AA71@ld9781.wdf.sap.corp>
In-Reply-To: <20131108165218.1EEB01AA71@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2013 17:21:17.0837 (UTC) FILETIME=[EF559BD0:01CEDCA6]
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 17:21:45 -0000

> It is actually not a violation of PKIX.  However, behaviour is undefined.
> 
> PKIX (rfc5280) inherited this from X.509, and it has been spelled out
> in rfc5280-clarifications:
> 
>   http://tools.ietf.org/html/rfc6818#section-2
> 
>   2. Update to RFC 5280, Section 3.2: "Certification Paths and Trust"
> 
> 
>      Add the following paragraph to the end of RFC 5280, Section 3.2:
> 
>   | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
>   | that use of self-issued certificates and self-signed certificates
>   | issued by entities other than CAs are outside the scope of this
>   | specification.  Thus, for example, a web server or client might
>   | generate a self-signed certificate to identify itself.  These
>   | certificates and how a relying party uses them to authenticate
>   | asserted identities are both outside the scope of RFC 5280.
> 

Interesting, this clarification in RFC 5280bis escaped my attention.

However, self-issued implies that both certificates share the same Common Name. So this paragraph only applies to the
scenario sketched by Andy when the server identity (sub domain) is encoded _only_ in SubjectAltName (dNSName). This is
recommended by RFC 2818 anyway.

-- 
Johannes

From luto@amacapital.net  Fri Nov  8 09:33:31 2013
Return-Path: <luto@amacapital.net>
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 11B7611E819E for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.921
X-Spam-Level: 
X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 n7ybkCWLwEbZ for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:33:26 -0800 (PST)
Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id C259811E80EC for <tls@ietf.org>; Fri,  8 Nov 2013 09:33:25 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id x16so1585415vbf.23 for <tls@ietf.org>; Fri, 08 Nov 2013 09:33:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IolbQjCU4KQWlreKozvzIqEsIiw8+9VGuiYarcFbeK0=; b=DeCZbWihcC2LW+vUguhGZxkeeA5wLp2pJU0dvSQlUFLpksmISuN6w0tCeYvgoeOiH3 rLyiQ2xIrq10YiduwOApVim0Nbdy4ePXPcf1EyLzJIz/XVJaKnRklycYHbgD6BF/sNMQ t8H5xliQDckQTQRvEv+YERuYGxDCMZuIRzzhNkEAG2ew2Tv/3tU/IhRGOEpa9IpKwyOK ENAIdBSJpCGOo0B5aGzDa7lPpXaM4Ujbrm0a7xFL6AKk2Q+pLbQ6lkLTjTiqH8xsmQqR QkwnvjfT5+sruXyXaXVgR32VMgjuelch392iUjYq5rP9IhuVHN1y3T9Y6bY6OdbfuZR0 0VdQ==
X-Gm-Message-State: ALoCoQlXHgblutF4n7dhMqfeaOq0EBns8EYKZEeysR96Jh1CSKRReyYiuqmI/6671BCYhWzXYQsa
X-Received: by 10.52.103.35 with SMTP id ft3mr10940292vdb.5.1383932005207; Fri, 08 Nov 2013 09:33:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Fri, 8 Nov 2013 09:33:02 -0800 (PST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com> <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 8 Nov 2013 09:33:02 -0800
Message-ID: <CALCETrUtFqKZ9krQTdmL-rfdcAAS0fik5seJdMGG1GD7VU0rNA@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 17:33:31 -0000

On Fri, Nov 8, 2013 at 8:45 AM, Salz, Rich <rsalz@akamai.com> wrote:
>> Rather than presenting a proxy certificate, the server could present a standard (valid according to PKIX / TLS 1.2 rules) certificate and *separately* present a chain of public keys, ... None of this needs to be in X.509 format.
>
> I'm curious what this new and different but similar structure would be like.   And whether the intended use of this stuff justifies the complexity and creation of all this new stuff, or breaking PKIX compatibility.

A little like the server config mechanism here:

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit

From luto@amacapital.net  Fri Nov  8 09:43:54 2013
Return-Path: <luto@amacapital.net>
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 A8D6511E8155 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:43:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.33
X-Spam-Level: 
X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=-0.553,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-1]
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 imvJvioDGxNO for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:43:50 -0800 (PST)
Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id D023D21E813E for <tls@ietf.org>; Fri,  8 Nov 2013 09:43:38 -0800 (PST)
Received: by mail-vb0-f42.google.com with SMTP id p14so1609649vbm.15 for <tls@ietf.org>; Fri, 08 Nov 2013 09:43:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Py/v2jhrjTvgDR/jODfinKZ3VtMfArJ+EU1C96apzTw=; b=R4BpftmBtY7QmX2YDVF9cda+nCtswDJtuqyymNrAMNM65iMSPYpXYHf9Ml5jidnx4s Ct4ijdjSaqyHfmaPlxlehnm7x3THixDOujkIp8qHZN6iUk4u6SULsd+owSChjrsxId0R slAr+VPfG4gePeEY5FTJR6UpeRN0xQqWe7EBE8G6H1Hq3LI5RH39UJ64OiXeQiy3XP9x kju6tQXnlN2Qdl7cjuf84jB9INGnWUpB5SoT7gDtgc0uIXw1I600XdJvHz1KVBLz+1O/ tlg9dVakJxZRigMylzOoWCXLiK4CC9kOVgfQkoNm53xrMu+G7SbA5ckav3N4+zsYUJw6 ZWgQ==
X-Gm-Message-State: ALoCoQl7S/Zd2ARbNLRKf2R82LQeVy4XCVFs+rLq63cQNdRWCMUfTFARBU74Jhhlt+qsk4/jT5Wx
X-Received: by 10.220.145.75 with SMTP id c11mr2923446vcv.30.1383932617195; Fri, 08 Nov 2013 09:43:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Fri, 8 Nov 2013 09:43:17 -0800 (PST)
In-Reply-To: <527D1790.8010108@secunet.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com> <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com> <527D1790.8010108@secunet.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 8 Nov 2013 09:43:17 -0800
Message-ID: <CALCETrUHO6pWjhMMk4N0UxcAfKhOXKYNod8bUHbd5Rk75czBZQ@mail.gmail.com>
To: Johannes Merkle <johannes.merkle@secunet.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 17:43:54 -0000

On Fri, Nov 8, 2013 at 8:55 AM, Johannes Merkle
<johannes.merkle@secunet.com> wrote:
>>
>> I think one way to not break with PKIX is to define a new extendedKeyUsage attribute that says "can sign short-term SSL cert chains"
>
> not breaking PKIX means that basic contraints must be set to CA=TRUE. Furthermore, the new EKU would have to be limited
> t a particular domain.

Please don't -- that will just cause the certificate authorities to
charge more for these certificates.

The problem AIUI with X.509 constraints in general is that they only
apply to the next certificate down the chain, which means that there's
plenty of room to get the spec wrong and make it useless [1].

If TLS 1.3 adds a new mechanism here, I think that the validation rule
should be clearer: the standard CA=FALSE certificate that's involved
must be valid for the domain *and* each delegated certificate must
also be valid for the domain.  This means that you don't need to check
that each delegated certificate's constraints are a subset of their
parents'.  (For example, there's no need to make it illegal for a
CA=FALSE certificate for foo.example.com to delegate to a
*.example.com certificate; instead it's enough to say that the
*.example.com certificate won't be accepted for bar.example.com
because its signer isn't valid for that domain.  Similarly, you don't
need to think about all the different kinds of names in X.509 and
their interactions.)

(I suppose this is a problem w/ the non-X.509 approach in QUIC --
there's no way for a wildcard certificate to delegate just one of its
subdomains.)

[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/

--Andy

From hallam@gmail.com  Fri Nov  8 09:57:02 2013
Return-Path: <hallam@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 5B0E511E8229 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level: 
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OViIVMfT9mLc for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 09:57:00 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 519D711E8225 for <tls@ietf.org>; Fri,  8 Nov 2013 09:57:00 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id er20so2034521lab.31 for <tls@ietf.org>; Fri, 08 Nov 2013 09:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=O77n22meqOR4AXtcnxIgy3LIu21I1IOFgcxnqvsH7kY=; b=TWSqYGoec4Rsf99tk5OVHBE9xcwmzIWKh9/l10rFmnqWhGhmBg6fYywCuNTFt+Xuj0 8A/20O+MCQ8wPpxNdo2sdGZ67Rr5uic2ldFRnjMrzEtlnaJn9qd7gp9q7niS7NrWP8uL 2M/WSrp8W2zUwnpic9QVz4T3PrQdFr1r1b3+wzS36EUJR7vlEn0g8ooaJj167Y58nNVP jcPTWOHb+D2RByz92kDgJJZEn6sa6KyRgqoTw+PTMIuUmq0gFA6HpYMozHIgy3ZLVsFR FsuNU4R1l0ndSXqlRGO1EcyfUHoaaArMnvWihmhPzSF8wU6921j2odBTdqDc9QeHlRl+ tf0Q==
MIME-Version: 1.0
X-Received: by 10.152.6.169 with SMTP id c9mr11810335laa.28.1383933419273; Fri, 08 Nov 2013 09:56:59 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Fri, 8 Nov 2013 09:56:59 -0800 (PST)
Date: Fri, 8 Nov 2013 09:56:59 -0800
Message-ID: <CAMm+Lwgjx2yTArspC4u5=WOh6HQ+DMgq85aqR1H+KJs4UkF3jQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e01493c06d942dc04eaae1bb6
Subject: [TLS] OCSP Stapling support mandatory in TLS 1.3?
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: Fri, 08 Nov 2013 17:57:02 -0000

--089e01493c06d942dc04eaae1bb6
Content-Type: text/plain; charset=ISO-8859-1

I would like to use the TLS 1.3 update to require support for a number of
functions that are desperately needed but currently difficult to use due to
patchy support. Which is kind of what the point of a version upgrade is.

Chief on my list of 'must have' features is stapling support. All the
servers I have surveyed for WPKOPS support stapling.


What I would like to see is that a server always staple if there is an OCSP
distribution point advertised.

What I would settle for is that the server MUST understand the 'MUST
STAPLE' flag in a certificate and if it is present, provide the stapled
responses.

http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02


The advantage of this approach is that it means much less confusion for our
customers. It is easier for them to check that they support TLS 1.3 than to
look at server versions (which we might not know about if it is a less used
server or some CDN thing).


-- 
Website: http://hallambaker.com/

--089e01493c06d942dc04eaae1bb6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would like to use the TLS 1.3 update to require support =
for a number of functions that are desperately needed but currently difficu=
lt to use due to patchy support. Which is kind of what the point of a versi=
on upgrade is.<div>
<br></div><div>Chief on my list of &#39;must have&#39; features is stapling=
 support. All the servers I have surveyed for WPKOPS support stapling.</div=
><div><br></div><div><br></div><div>What I would like to see is that a serv=
er always staple if there is an OCSP distribution point advertised.</div>
<div><br></div><div>What I would settle for is that the server MUST underst=
and the &#39;MUST STAPLE&#39; flag in a certificate and if it is present, p=
rovide the stapled responses.</div><div><br></div><div><a href=3D"http://to=
ols.ietf.org/html/draft-hallambaker-tlsfeature-02">http://tools.ietf.org/ht=
ml/draft-hallambaker-tlsfeature-02</a><br>
</div><div><br clear=3D"all"><div><br></div><div>The advantage of this appr=
oach is that it means much less confusion for our customers. It is easier f=
or them to check that they support TLS 1.3 than to look at server versions =
(which we might not know about if it is a less used server or some CDN thin=
g).</div>
<div><br></div><div><br></div>-- <br>Website: <a href=3D"http://hallambaker=
.com/">http://hallambaker.com/</a><br>
</div></div>

--089e01493c06d942dc04eaae1bb6--

From mike-list@pobox.com  Fri Nov  8 11:26:20 2013
Return-Path: <mike-list@pobox.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 C5A3411E816D for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 11:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 YTT+Ezz-JCPr for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 11:25:33 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2EC21F9D7D for <tls@ietf.org>; Fri,  8 Nov 2013 11:25:33 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 71B3EE05F; Fri,  8 Nov 2013 14:25:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=ti0Nq3BV+dNy 2BCXRPGMxbzeJrU=; b=RSC/I/7S/6hdUpTXeZbMlf8qAlQcTAZdModaLqBqbYab qoWr6yzV7iWvIaqBvw/9+Qf49oMPPg8SV4YHb8gIuuV64uRiUDSuuhc0VYETWmpC ACmlXzU2QmFaefbTz7H0IiF26gNEg3/nRcXc63VMu1vqCGrWIQDgf+exVg6mgjE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=UrNO59 byhHd2OdudvSd5hFWeXVM937CGPJjGhLUMJh41smVu81j1Pkb0XMMfxsml3gnhYM qtypc6xnPInbEyA2f3C3ANAkqLakS2MuiputFKTpjqbrNuaGndBGfilajrv456mp ZPC0nzjy1EQqtU/TFeXXYKpQHwvYF0oxwn5IA=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 68549E05E; Fri,  8 Nov 2013 14:25:28 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 7480FE05D; Fri,  8 Nov 2013 14:25:27 -0500 (EST)
Message-ID: <527D3AA4.80108@pobox.com>
Date: Fri, 08 Nov 2013 11:25:24 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Johannes Merkle <johannes.merkle@secunet.com>
References: <20131108072109.CA6061AA6A@ld9781.wdf.sap.corp> <527CF53B.7010908@secunet.com>
In-Reply-To: <527CF53B.7010908@secunet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 8622773E-48AB-11E3-8585-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 19:26:20 -0000

Johannes Merkle wrote:
>>> FWIW, there's precedent for using new TLS versions to expand the set
>>> of allowable certificates.  If I"m reading it correctly, TLS 1.2
>>> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
>>> will reject those.
>> TLSv1.1 will certainly not reject those.
>> It is only rfc4492 that incorrectly alleges that those should be rejected.
> 
> I think you are wrong: Section 7.4.2 of RFC 4346 states
> 
>                               Unless otherwise specified, the signing
>       algorithm for the certificate MUST be the same as the algorithm
>       for the certificate key.
> 
> 
> Section 7.4.2 of RFC 5246 states
>                                                                   Note
>    that this implies that a certificate containing a key for one
>    signature algorithm MAY be signed using a different signature
>    algorithm (for instance, an RSA key signed with a DSA key).  This is
>    a departure from TLS 1.1, which required that the algorithms be the
>    same.

I don't believe that there was ever a requirement for a client to reject
a certificate chain based on the signature algorithms.  The requirement
is for what a server must send to the client when it has no knowledge
about the client's capabilities.  The cipher suite list sent by a client
provides a hint at its capabilities, but it was made explicit in TLS 1.2.

It would be a bad idea to send an RSA key signed with ECDSA, for example,
without knowing that the client can handle ECDSA.  That is the purpose
of the signature_algorithms extension.

If a client were to receive a certificate containing an RSA key that is
signed by ECDSA, and it happens to know how to validate ECDSA, there is
no reason to abort the connection.

Mike

From mike-list@pobox.com  Fri Nov  8 11:41:04 2013
Return-Path: <mike-list@pobox.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 5D45711E81D9 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 11:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 HIOC-9bOr86p for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 11:40:31 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D285C21E81F8 for <tls@ietf.org>; Fri,  8 Nov 2013 11:39:59 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 82EA0E198; Fri,  8 Nov 2013 14:39:51 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=HS1VU0EzGYQ9 F8JHLZZZk4O1XMQ=; b=mFgTQW9UNm2tPhM278al92jhyNEibtk9sdUSK7caUCPf XPQCpAOrKnsebQX5DGo95tnNSxHWDmD6b2thzd7N5lUSIv7XXxudxkNVrGrGB3s7 X2tSUq/vCVyq9cHRn4tQu7HKeUDTk+ltKvBRTuV0eNBPCpBsCDQKSbye+lq46Mc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=C6HXYc KgPUit5hivm/JF/5+iyO+Py9BYfCv7UhkpdVbTZ5QbYQCt91qRwdPe1qn0eRTxQ3 DOfcKTdkU4EOzSkCw8l36YCBMcpPhr1Bz6kFm5yui4I5qPphdiCHfmjAr1HsNa6a gutawAjJxeWlBpm9YBjA41eLttfr0m8UBSTi8=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 7911BE197; Fri,  8 Nov 2013 14:39:51 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id CED0AE196; Fri,  8 Nov 2013 14:39:49 -0500 (EST)
Message-ID: <527D3E04.9050206@pobox.com>
Date: Fri, 08 Nov 2013 11:39:48 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Ralf Skyper Kaiser <skyper@thc.org>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>
In-Reply-To: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 880AC072-48AD-11E3-8404-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Fri, 08 Nov 2013 19:41:05 -0000

Ralf Skyper Kaiser wrote:
>  
> Some thoughts why SNI (host name) and ALPN should be
> transmitted encrypted and not in clear....

I'm fine with encrypting these as long as the server
receives them prior to selecting a certificate.

SNI allows for multi-homing (different server names
on the same IP), and ALPN allows you to put multiple
services on the same port (e.g. SMTP/POP3/IMAP all on
port 443 along with HTTPS/SPDY).  Each service might
require its own certificate.

Mike

From skyper@thc.org  Fri Nov  8 13:43:07 2013
Return-Path: <skyper@thc.org>
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 EC01321E8147 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 13:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=0.068,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 ToWyCzZNYgiq for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 13:43:00 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 281FE11E80FB for <tls@ietf.org>; Fri,  8 Nov 2013 13:42:06 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so4240191iec.41 for <tls@ietf.org>; Fri, 08 Nov 2013 13:42:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pgCbNP3trBI6HBFMArZKU0gnQA/zdRmAOYJwtm7E7Us=; b=JoMA0gMsxB4nJy4CL/1qxtzR13F+yx60L4Nh7Tx83alLWNaCrW4uRIlkOniNaHszEY +1/QemtgZ/Vjak4Bom9O4JQ4oq25qfcG6OQPYWFRX1PnVJQumf83k7AUc6hI430hTMXb vDXOl6xUNNU3B06fi1ROyq2CugqdUfQGCnt3I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pgCbNP3trBI6HBFMArZKU0gnQA/zdRmAOYJwtm7E7Us=; b=bIOcXrzljyuqXLQtSpqf81hI7ahz9D8fgWvcA7zL/oDAjGjnlm/xCI+B7K+t4aH6O/ k5rA9Awxwk6w4DLjnEII9TGnAkzWuFvFD/4oatplBjUT7NGtodW2/PcF6V4BE1pCMjJA 7ytFU0jJ6KG4aSHrczt070+vheYNjK0R8NQ0JKxM4y3Umu+X5vkrbQ8DOYePGe8ooNoC dDd6kFoi6gK8IVju2Yf2mhMuRDCvpVzScwEN4fkzZLzMcTvXSeFQPToKISS6lPG4T1ub 0QNzomsa1bkrU+Z2ksr2cif5pzlXb4sNQyUVjTFbYxpQDXv+8f1MuxLiW11IC72oTVwF M9FA==
X-Gm-Message-State: ALoCoQlugxO27u6P8Bt3iHZghc3/5aMqHXS8vhX/H8MMCuUO+Lmy2KlAbKcyGcuxiQlTEC587K6g
MIME-Version: 1.0
X-Received: by 10.43.80.67 with SMTP id zt3mr10389704icb.23.1383946924992; Fri, 08 Nov 2013 13:42:04 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Fri, 8 Nov 2013 13:42:04 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <527D3E04.9050206@pobox.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <527D3E04.9050206@pobox.com>
Date: Fri, 8 Nov 2013 21:42:04 +0000
Message-ID: <CA+BZK2qa3tiHWVQF+DGn5XRRvdWCKYYUMdEEQjOQQpidioFqOw@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: "Michael D'Errico" <mike-list@pobox.com>
Content-Type: multipart/alternative; boundary=001a1133326adadcaa04eab14044
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Fri, 08 Nov 2013 21:43:07 -0000

--001a1133326adadcaa04eab14044
Content-Type: text/plain; charset=ISO-8859-1

Hi,

absolutely. Encrypted SNI in TLS 1.3 will be received by server prior to
selecting a certificate.

ALPN could be encrypted as well (same reason, same solution).

regards,

ralf


On Fri, Nov 8, 2013 at 7:39 PM, Michael D'Errico <mike-list@pobox.com>wrote:

> Ralf Skyper Kaiser wrote:
>
>>  Some thoughts why SNI (host name) and ALPN should be
>> transmitted encrypted and not in clear....
>>
>
> I'm fine with encrypting these as long as the server
> receives them prior to selecting a certificate.
>
> SNI allows for multi-homing (different server names
> on the same IP), and ALPN allows you to put multiple
> services on the same port (e.g. SMTP/POP3/IMAP all on
> port 443 along with HTTPS/SPDY).  Each service might
> require its own certificate.
>
> Mike
>

--001a1133326adadcaa04eab14044
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br></div><div>absolutely. Encrypted SNI in TL=
S 1.3 will be received by server prior to selecting a certificate.<br><br><=
/div><div>ALPN could be encrypted as well (same reason, same solution).<br>
</div><div><br>regards,<br><br></div><div>ralf<br></div></div><div class=3D=
"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Nov 8, 2013 at 7:3=
9 PM, Michael D&#39;Errico <span dir=3D"ltr">&lt;<a href=3D"mailto:mike-lis=
t@pobox.com" target=3D"_blank">mike-list@pobox.com</a>&gt;</span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ralf Skyper Kaiser wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">
=A0Some thoughts why SNI (host name) and ALPN should be<br></div>
transmitted encrypted and not in clear....<br>
</blockquote>
<br>
I&#39;m fine with encrypting these as long as the server<br>
receives them prior to selecting a certificate.<br>
<br>
SNI allows for multi-homing (different server names<br>
on the same IP), and ALPN allows you to put multiple<br>
services on the same port (e.g. SMTP/POP3/IMAP all on<br>
port 443 along with HTTPS/SPDY). =A0Each service might<br>
require its own certificate.<br>
<br>
Mike<br>
</blockquote></div><br></div>

--001a1133326adadcaa04eab14044--

From rob.stradling@comodo.com  Fri Nov  8 14:40:33 2013
Return-Path: <rob.stradling@comodo.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 CB6C221E8085 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 14:40:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 d0lEneR9VicR for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 14:40:28 -0800 (PST)
Received: from mmmail2.mcr.colo.comodoca.net (mmmail.mcr.colo.comodoca.net [91.209.196.71]) by ietfa.amsl.com (Postfix) with ESMTP id 42D2221E805F for <tls@ietf.org>; Fri,  8 Nov 2013 14:40:27 -0800 (PST)
Received: (qmail 32110 invoked from network); 8 Nov 2013 22:40:24 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 8 Nov 2013 22:40:24 -0000
Received: (qmail 12776 invoked by uid 1000); 8 Nov 2013 22:40:24 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 08 Nov 2013 22:40:24 +0000
Message-ID: <527D6858.5040007@comodo.com>
Date: Fri, 08 Nov 2013 22:40:24 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Andy Lutomirski <luto@amacapital.net>,  Johannes Merkle <johannes.merkle@secunet.com>
References: <527CF707.2070000@secunet.com>	<r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local>	<2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com>	<CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com>	<2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>	<527D1790.8010108@secunet.com> <CALCETrUHO6pWjhMMk4N0UxcAfKhOXKYNod8bUHbd5Rk75czBZQ@mail.gmail.com>
In-Reply-To: <CALCETrUHO6pWjhMMk4N0UxcAfKhOXKYNod8bUHbd5Rk75czBZQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 22:40:33 -0000

On 08/11/13 17:43, Andy Lutomirski wrote:
<snip>
> The problem AIUI with X.509 constraints in general is that they only
> apply to the next certificate down the chain,

Disagree.  I'd say the reverse is true.

The Basic Constraints pathLenConstraint field (RFC5280 4.2.1.9)...
   "...gives the maximum number of non-self-issued intermediate
    certificates that may follow this certificate in a valid
    certification path."

The Name Constraints extension (RFC5280 4.2.1.10)...
  "...indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located."

> which means that there's
> plenty of room to get the spec wrong and make it useless [1].

OpenSSL 0.9.8 doesn't process Name Constraints, but OpenSSL 1.0.0+ does. 
  So upgrade.  :-)

> If TLS 1.3 adds a new mechanism here,

...then implementers might "get the spec wrong and make it useless"?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From luto@amacapital.net  Fri Nov  8 15:04:44 2013
Return-Path: <luto@amacapital.net>
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 4C76821E8082 for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 15:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.851
X-Spam-Level: 
X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 gMh2B4sKqsYh for <tls@ietfa.amsl.com>; Fri,  8 Nov 2013 15:04:37 -0800 (PST)
Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id A5D1321E805F for <tls@ietf.org>; Fri,  8 Nov 2013 15:04:37 -0800 (PST)
Received: by mail-ve0-f169.google.com with SMTP id jy13so1946660veb.14 for <tls@ietf.org>; Fri, 08 Nov 2013 15:04:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=di0xovGQ+bs7bU/2HpwjSMVmdijfQQNwUeMDs4YaOtM=; b=OzHVwPxVILHX5JJjP3M2VRcyTnvZ3qXaMFXslyQwIlosx18SHBTVvzDCppAGcr2od2 c09E06SU0NIHgzsZqu9nWV/Fm6GLWx+JjS9gW99/y47HlR7ISlQ72RXp9sxgv11aQlET VdendnsI361usKPpVW+xo5d9tLS1+RGsEai2xn3QJnxOKBBCfCE/zS+t79FVY+JWfnNL 7xwAjUR8dSs1FOnh5BIlpVFlPCeJ6kd+ZYxg8Ji8RbxnqC01ed2O5yUZ86elDwDTHHHa Ps5vqR+Mkhl/v6uQECzFO0DoCBF4J9NjrQblS1TTJ53cwxbg4mim0EsLrOgLWTjQ6vbY OzSQ==
X-Gm-Message-State: ALoCoQkFqx8Uig8s6Dixz9MzksSvmrs0NMNxfOd24HoUPezyHrJuWoAr2aTYaNUesUaXg+0vEaB3
X-Received: by 10.220.244.132 with SMTP id lq4mr267982vcb.31.1383951877102; Fri, 08 Nov 2013 15:04:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Fri, 8 Nov 2013 15:04:17 -0800 (PST)
In-Reply-To: <527D6858.5040007@comodo.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com> <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com> <527D1790.8010108@secunet.com> <CALCETrUHO6pWjhMMk4N0UxcAfKhOXKYNod8bUHbd5Rk75czBZQ@mail.gmail.com> <527D6858.5040007@comodo.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 8 Nov 2013 15:04:17 -0800
Message-ID: <CALCETrW-0-xSDdODSe0qNk8TJE=nbJxKPMiUaWLuJ-FidOcAuw@mail.gmail.com>
To: Rob Stradling <rob.stradling@comodo.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Fri, 08 Nov 2013 23:04:44 -0000

On Fri, Nov 8, 2013 at 2:40 PM, Rob Stradling <rob.stradling@comodo.com> wrote:
> On 08/11/13 17:43, Andy Lutomirski wrote:
> <snip>
>
>> The problem AIUI with X.509 constraints in general is that they only
>> apply to the next certificate down the chain,
>
>
> Disagree.  I'd say the reverse is true.
>
> The Basic Constraints pathLenConstraint field (RFC5280 4.2.1.9)...
>   "...gives the maximum number of non-self-issued intermediate
>    certificates that may follow this certificate in a valid
>    certification path."
>
> The Name Constraints extension (RFC5280 4.2.1.10)...
>  "...indicates a name space within which all subject names in
>   subsequent certificates in a certification path MUST be located."
>
>
>> which means that there's
>> plenty of room to get the spec wrong and make it useless [1].
>
>
> OpenSSL 0.9.8 doesn't process Name Constraints, but OpenSSL 1.0.0+ does.  So
> upgrade.  :-)
>
>
>> If TLS 1.3 adds a new mechanism here,
>
>
> ...then implementers might "get the spec wrong and make it useless"?

If it's widely used (possibly even by default in some implementation)
to use short-term fixed DH parameters a la QUIC, then implementations
won't have the opportunity to screw it up.

--Andy

From peter.sylvester@edelweb.fr  Sat Nov  9 01:55:19 2013
Return-Path: <peter.sylvester@edelweb.fr>
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 5867A11E81BA for <tls@ietfa.amsl.com>; Sat,  9 Nov 2013 01:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 12dBdgYvTncq for <tls@ietfa.amsl.com>; Sat,  9 Nov 2013 01:55:14 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6325611E81B8 for <tls@ietf.org>; Sat,  9 Nov 2013 01:55:14 -0800 (PST)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 52FD15E05E; Sat,  9 Nov 2013 10:49:42 +0100 (CET)
Received: from [127.0.0.1] (unknown [192.168.11.68]) by mx1.on-x.com (Postfix) with ESMTP id D5B465E04B; Sat,  9 Nov 2013 10:49:41 +0100 (CET)
Message-ID: <527E067F.9010209@edelweb.fr>
Date: Sat, 09 Nov 2013 10:55:11 +0100
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131108163432.AE6371AA71@ld9781.wdf.sap.corp>
In-Reply-To: <20131108163432.AE6371AA71@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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: Sat, 09 Nov 2013 09:55:19 -0000

On 11/08/2013 05:34 PM, Martin Rex wrote:
> Johannes Merkle wrote:
>>>> FWIW, there's precedent for using new TLS versions to expand the set
>>>> of allowable certificates.  If I"m reading it correctly, TLS 1.2
>>>> allows ECDSA certificates that are signed with RSA; TLS 1.1 and below
>>>> will reject those.
>>> TLSv1.1 will certainly not reject those.
>>> It is only rfc4492 that incorrectly alleges that those should be rejected.
>> I think you are wrong: Section 7.4.2 of RFC 4346 states
>>
>>                                Unless otherwise specified, the signing
>>        algorithm for the certificate MUST be the same as the algorithm
>>        for the certificate key.
Taking this out of context is not helpful
The specificatiosn makes staements about what the sender has to
do, not what the receiver has to verify.

7.4.2. Server Certificate

    When this message will be sent:



> The history of this obvious defect starts in rfc2246.

>
> There exists no such artificial limitation in SSLv3, and when I looked
> at implementations I've been using for interop testing a few
> years ago (Microsoft SChannel, OpenSSL, Firefox), they would
> happily interoperate with an RSA server cert signed by a CA with a
> DSA key.  To me it looks like most implementors were either not
> aware of this bogus, backwards-incompatible requirement,
> or they applied common sense and deliberately ignored it.
What is bogus in restricting a sender to be conservative?
>
> One can not "violate" rfc2119 Section 6 more than with the above
> statement, so it is null and void.
Be strict in what you send, that's violated by some, be liberal
in what to receive, this enhances interop in some cases.

>
> Not only is this method "must be the same algorithm" not required
> for interop, it is the the worst possible way to impair interop
> without a cause.NO
Only if a receiver misinterpretes the rulles about what a sender MUST do as
'you have to verify this and reject if you can detect it'. But that is not what
is written.

By default a receiver can accept any kinf of garbage, not verify
signatures, etc.



From code@funwithsoftware.org  Sat Nov  9 21:34:33 2013
Return-Path: <code@funwithsoftware.org>
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 9554321E80E8 for <tls@ietfa.amsl.com>; Sat,  9 Nov 2013 21:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.135,  BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 QmYGIP+E323s for <tls@ietfa.amsl.com>; Sat,  9 Nov 2013 21:34:28 -0800 (PST)
Received: from mail24c25-2209.carrierzone.com (mail223c25.carrierzone.com [64.29.147.237]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1421E80E6 for <tls@ietf.org>; Sat,  9 Nov 2013 21:34:28 -0800 (PST)
X-Authenticated-User: ppelleti.speakeasy.net
Received: from PatrickMBP.local (dsl017-096-185.lax1.dsl.speakeasy.net [69.17.96.185]) (authenticated bits=0) by mail24c25-2209.carrierzone.com (8.13.6/8.13.1) with ESMTP id rAA5Y9dq002334 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 10 Nov 2013 05:34:23 +0000
Message-ID: <527F1AD1.20804@funwithsoftware.org>
Date: Sat, 09 Nov 2013 21:34:09 -0800
From: Patrick Pelletier <code@funwithsoftware.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: TLS Mailing List <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com> <87d2mcy2s3.fsf@alice.fifthhorseman.net>
In-Reply-To: <87d2mcy2s3.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-CSC: 0
X-CHA: v=2.1 cv=aKDJ99Nm c=1 sm=1 tr=0 a=3bGt9MXpJgS1DxBngKRbCQ==:117 a=3bGt9MXpJgS1DxBngKRbCQ==:17 a=eVbW6KzvAAAA:8 a=g0qM3YM6AAAA:8 a=Nj7kusMiCPUA:10 a=XwRAJLFUau8A:10 a=rtZ2W72OR7QA:10 a=8nJEP1OIZ-IA:10 a=SF9KqDZ7AAAA:8 a=MlwnRRhLUwgA:10 a=gHvrztcjAAAA:8 a=X5UvlbiVwI_kCvQgiB0A:9 a=wPNLvfGTeEIA:10 a=yl1PmSW91XoA:10
X-CTCH-RefID: str=0001.0A020203.527F1AE0.0096, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.100
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
Subject: Re: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
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: Sun, 10 Nov 2013 05:34:33 -0000

On 11/7/13 1:33 AM, Daniel Kahn Gillmor wrote:

> The minmalist proposal:
> -----------------------
>
>   * compliant clients advertising a ciphersuite using EDH would include
>     an extension indicating the smallest and largest EDH group sizes they
>     are willing to accept.

The only thing I would add is that besides minimum and maximum number of 
bits, the client should also indicate a multiple, which the group size 
must be divisible by.  For example, Java only supports DH groups whose 
size is a multiple of 64.  If the client can accept any group size 
within its minimum,maximum range, then it uses 1 as its multiple.  So, 
examples of this triple might be:

1024,2048,64
1280,4096,8
1024,8192,1

> All of the observations above make me think that the minimalist proposal
> seems to be the least likely to cause controversy and the simplest to
> patch into existing implementations quickly and safely.

+1.  It just fixes the existing mechanism, rather than introducing a new 
mechanism.

However, at the risk of making the minimalist proposal slightly less 
minimal, I'd like to suggest that the extension should also allow the 
server to reply with the DH exponent size:

http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html

--Patrick


From watsonbladd@gmail.com  Sat Nov  9 21:42:05 2013
Return-Path: <watsonbladd@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 DEE4321E80E8 for <tls@ietfa.amsl.com>; Sat,  9 Nov 2013 21:42:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050,  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 sGM3s4nnon2X for <tls@ietfa.amsl.com>; Sat,  9 Nov 2013 21:42:05 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1003121E80E7 for <tls@ietf.org>; Sat,  9 Nov 2013 21:42:04 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id cb5so1188334wib.0 for <tls@ietf.org>; Sat, 09 Nov 2013 21:42:03 -0800 (PST)
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=eyuGe/bSzUGy5g29H1+CZPzGvpAH8i0NBX5/JOvLcCk=; b=g2nFe6bbhCNOyd78e3xFoEB6OgN2Kd2T1LvSBPNAry4gqZs/OYhBsARMZDmnRIHLU+ fsvkbU0nJzde+up3XNkWIOUvvQTLlyqmQkfGsAXNxgNWGGaFYzd25nUyZu5fKa/uJrWY mCAbUCWQQwgDEEEJ+DlCXkAChZPtj9MXnUQZA8s2LD0KIEwvbwvLQ9dRyUxWmivrvTOP 8GmBKhw3zBMrxV44azpWKcBrhEbkyakvI70A9Fe7mkxbGebQxMDrjMWq2VhhiJl2z7xv 1c6FkMnnofIr1WD9cfNXWTB19+x7UCh9HIPDh1Ng6dme2wMwAeaC3AjZbeRYp2fDmrw0 /x5A==
MIME-Version: 1.0
X-Received: by 10.180.37.162 with SMTP id z2mr7728099wij.58.1384062123921; Sat, 09 Nov 2013 21:42:03 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sat, 9 Nov 2013 21:42:03 -0800 (PST)
In-Reply-To: <527F1AD1.20804@funwithsoftware.org>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> <A3161699-0975-403C-B9C1-8BE548062949@mac.com> <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com> <87d2mcy2s3.fsf@alice.fifthhorseman.net> <527F1AD1.20804@funwithsoftware.org>
Date: Sat, 9 Nov 2013 21:42:03 -0800
Message-ID: <CACsn0cnNA5PwE2Og+w08fJqqDdwhFm54_ajdx30ymJa=iZTyiA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Patrick Pelletier <code@funwithsoftware.org>
Content-Type: text/plain; charset=UTF-8
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] DH group negotiation extension [was: Re: draft-sheffer-tls-bcp: DH recommendations]
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: Sun, 10 Nov 2013 05:42:06 -0000

On Sat, Nov 9, 2013 at 9:34 PM, Patrick Pelletier
<code@funwithsoftware.org> wrote:
> On 11/7/13 1:33 AM, Daniel Kahn Gillmor wrote:
>
>> The minmalist proposal:
>> -----------------------
>>
>>   * compliant clients advertising a ciphersuite using EDH would include
>>     an extension indicating the smallest and largest EDH group sizes they
>>     are willing to accept.
>
>
> The only thing I would add is that besides minimum and maximum number of
> bits, the client should also indicate a multiple, which the group size must
> be divisible by.  For example, Java only supports DH groups whose size is a
> multiple of 64.  If the client can accept any group size within its
> minimum,maximum range, then it uses 1 as its multiple.  So, examples of this
> triple might be:
>
> 1024,2048,64
> 1280,4096,8
> 1024,8192,1
>
>
>> All of the observations above make me think that the minimalist proposal
>> seems to be the least likely to cause controversy and the simplest to
>> patch into existing implementations quickly and safely.
Fuck no.
Why don't we just use an elliptic curve? Failing that, why not define one group?
Having servers and clients suggest groups to each other is a great
denial of service attack
as factoring p-1 might take a while.  What does EDH group negotiation solve?
Sincerely,
Watson
>
>
> +1.  It just fixes the existing mechanism, rather than introducing a new
> mechanism.
>
> However, at the risk of making the minimalist proposal slightly less
> minimal, I'd like to suggest that the extension should also allow the server
> to reply with the DH exponent size:
>
> http://lists.gnutls.org/pipermail/gnutls-help/2012-May/002748.html
>
> --Patrick
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From mike-list@pobox.com  Sun Nov 10 12:29:08 2013
Return-Path: <mike-list@pobox.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 1F33721E8142 for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 12:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 zJRTK9iUsCwZ for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 12:28:57 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0956021E808A for <tls@ietf.org>; Sun, 10 Nov 2013 12:28:55 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0F3FFCDA1; Sun, 10 Nov 2013 15:28:55 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Ij8agNQtRqRb f2p9t4KWgPApCOs=; b=qmLH80l71xq+iK7OJl6VctEH8LUmJ3Efl0NIKtM0UFfB lOMuht6vBKSnDu3hpL80Zn9CKs52t0MoNkPE1rewTPvGrw1I6fKZOX6LTerWa7np ZttAuz+1nSoMN1tNqGx04USJKaao1c+dHnBbhkRvkRG6EMP30TB+BKT/+uQ3yb4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=CImq1k DED9jPlEg/BEYmVxWRW1j/NXqbswLj6K8xXKtzhtZYD+C9Se2v7XcdBkUTphom4f 0E3/At7q+LK8R7n6olM1S2fj5wIEOzX9Z8wS3sh6pDAhk+wblTdiSNjRZj6My19s MCsJ1yBuQQ6s7N1FhxhxcvM9d+alZwJTLtWQA=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 058F0CDA0; Sun, 10 Nov 2013 15:28:55 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9597ACD9F; Sun, 10 Nov 2013 15:28:53 -0500 (EST)
Message-ID: <527FEC83.9020107@pobox.com>
Date: Sun, 10 Nov 2013 12:28:51 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <AAE0766F5AF36B46BAB7E0EFB927320630E4A54175@GBTWK10E001.Technology.local>	<522BE808.4090405@stpeter.im> <522C88D8.5030702@gnutls.org>
In-Reply-To: <522C88D8.5030702@gnutls.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: B7B2CC9E-4A46-11E3-8E23-F66B0E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: [TLS] Encrypt-then-MAC again (was Re:  padding bug)
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: Sun, 10 Nov 2013 20:29:08 -0000

In trying to figure out what's stalling the encrypt-then-mac draft
I came across this old message (below).  The complaint against the
draft appears to be that since the MAC is no longer encrypted, there
may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
as the problem, so I checked to see which cipher suites use it.

The 13 cipher suites using MD5 are:

   A     0001    TLS_RSA_WITH_NULL_MD5
   B     0003    TLS_RSA_EXPORT_WITH_RC4_40_MD5
   C     0004    TLS_RSA_WITH_RC4_128_MD5
   D     0006    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
   E     0017    TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
   F     0018    TLS_DH_anon_WITH_RC4_128_MD5
   G     0022    TLS_KRB5_WITH_DES_CBC_MD5
   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
   I     0024    TLS_KRB5_WITH_RC4_128_MD5
   J     0025    TLS_KRB5_WITH_IDEA_CBC_MD5
   K     0029    TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
   L     002A    TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
   M     002B    TLS_KRB5_EXPORT_WITH_RC4_40_MD5

Eight of these (A, B, D, E, G, K, L, and M) are considered trivially
breakable; F allows for a MitM; J uses the deprecated IDEA cipher;
and C and I use RC4 which we now know is completely broken.

That leaves only one cipher suite to possibly be concerned about:

   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5

Do we really want to hold up the encrypt-then-mac draft any longer
because of this one Kerberos/triple-DES/MD5 cipher suite?

Mike




Nikos Mavrogiannopoulos wrote:
> On 09/08/2013 04:59 AM, Peter Saint-Andre wrote:
> 
>>> As I recall there were three proposals for resolving the padding
>>> bug in TLS
>>> 1.       An extension for Pad First (i.e. padding before an
>>> otherwise standard TLS mode of operation)
>>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>> 3.       The replacement of each existing cipher suite with an 
>>> equivalent AEAD one
>>> Was any consensus achieved as to the best approach?
>> I never saw further discussion on this topic. Are there I-Ds for each
>> approach? #3 seems onerous to me (and doubling the number of cipher
>> suites doesn't seem like a desirable outcome), and as far as I can
>> tell there's no specification for #1. Although I am not a TLS expert,
>> the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly
>> solves a real-world problem, and we have running code; thus IMHO
>> formalization of this approach deserves to be considered in the WG.
> 
> It is important when trying to solve an issue not to introduce new
> issues. The current proposal for #2 unfortunately does not take into
> account known counter-measures for key recovery attacks in MACs (see [0]).
> 
> regards,
> Nikos
> 
> [0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html

From watsonbladd@gmail.com  Sun Nov 10 12:33:42 2013
Return-Path: <watsonbladd@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 0EC3B21E8141 for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 12:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level: 
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.047,  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 7ZdNb4CynlLs for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 12:33:41 -0800 (PST)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 35CAC11E812A for <tls@ietf.org>; Sun, 10 Nov 2013 12:33:41 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id p61so1232263wes.6 for <tls@ietf.org>; Sun, 10 Nov 2013 12:33:38 -0800 (PST)
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=VwINuPePGgKVlRA8xcUlsFXDVfbsKVF0l1aGoQuG0b4=; b=Zoj/K5Kt95+Aw+6xyytvfQ2y89kq3OpG7B8AvEOsyVkSX/sgDdBEdKp4de6mI7UAbn 0jf1tL3fBeZNAAWXHPk6LteEu9xVI9c61ybtcJKdAm+QpzY6EPHyHd7WpYs0RteVHZ8b Iw2mRslG/HijNaULa5D+9t6ePYlFpDD9RBRvgXxTWgWAy9mwancvAVTXPxiAmdSNbYFs tFQRJUBkGZaRe9UP1iNs6h9pJAef3LLlFuoWZXqdK/lj1N70izC8VPiApzlz8fv04c12 2xqweQDoojphRiAIXP322ywDyh21Z95gnD07EmocBem5zdhN3NmjIW4vglTTr3MBiDn8 uuRA==
MIME-Version: 1.0
X-Received: by 10.194.239.40 with SMTP id vp8mr449630wjc.45.1384115618818; Sun, 10 Nov 2013 12:33:38 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sun, 10 Nov 2013 12:33:38 -0800 (PST)
In-Reply-To: <527FEC83.9020107@pobox.com>
References: <AAE0766F5AF36B46BAB7E0EFB927320630E4A54175@GBTWK10E001.Technology.local> <522BE808.4090405@stpeter.im> <522C88D8.5030702@gnutls.org> <527FEC83.9020107@pobox.com>
Date: Sun, 10 Nov 2013 12:33:38 -0800
Message-ID: <CACsn0c=up8rP39cHfbxe-HAyFUszW60i_5dvoVY8gdmD=T6dYg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Sun, 10 Nov 2013 20:33:42 -0000

On Sun, Nov 10, 2013 at 12:28 PM, Michael D'Errico <mike-list@pobox.com> wrote:
> In trying to figure out what's stalling the encrypt-then-mac draft
> I came across this old message (below).  The complaint against the
> draft appears to be that since the MAC is no longer encrypted, there
> may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
> as the problem, so I checked to see which cipher suites use it.
Who thinks this is a real problem? If the MAC is weak it shouldn't be used,
end of story. We have a real issue burning people now, and the
argument against it is
something that won't be an issue for a while, and only affects people
with their head in the
sand.
I say we publish it.
>
> The 13 cipher suites using MD5 are:
>
>   A     0001    TLS_RSA_WITH_NULL_MD5
>   B     0003    TLS_RSA_EXPORT_WITH_RC4_40_MD5
>   C     0004    TLS_RSA_WITH_RC4_128_MD5
>   D     0006    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
>   E     0017    TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
>   F     0018    TLS_DH_anon_WITH_RC4_128_MD5
>   G     0022    TLS_KRB5_WITH_DES_CBC_MD5
>   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
>   I     0024    TLS_KRB5_WITH_RC4_128_MD5
>   J     0025    TLS_KRB5_WITH_IDEA_CBC_MD5
>   K     0029    TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
>   L     002A    TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
>   M     002B    TLS_KRB5_EXPORT_WITH_RC4_40_MD5
>
> Eight of these (A, B, D, E, G, K, L, and M) are considered trivially
> breakable; F allows for a MitM; J uses the deprecated IDEA cipher;
> and C and I use RC4 which we now know is completely broken.
>
> That leaves only one cipher suite to possibly be concerned about:
>
>   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
>
> Do we really want to hold up the encrypt-then-mac draft any longer
> because of this one Kerberos/triple-DES/MD5 cipher suite?
No.
>
> Mike
>
Sincerely,
Watson Ladd
>
>
>
> Nikos Mavrogiannopoulos wrote:
>>
>> On 09/08/2013 04:59 AM, Peter Saint-Andre wrote:
>>
>>>> As I recall there were three proposals for resolving the padding
>>>> bug in TLS
>>>> 1.       An extension for Pad First (i.e. padding before an
>>>> otherwise standard TLS mode of operation)
>>>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>>> 3.       The replacement of each existing cipher suite with an
>>>> equivalent AEAD one
>>>> Was any consensus achieved as to the best approach?
>>>
>>> I never saw further discussion on this topic. Are there I-Ds for each
>>> approach? #3 seems onerous to me (and doubling the number of cipher
>>> suites doesn't seem like a desirable outcome), and as far as I can
>>> tell there's no specification for #1. Although I am not a TLS expert,
>>> the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly
>>> solves a real-world problem, and we have running code; thus IMHO
>>> formalization of this approach deserves to be considered in the WG.
>>
>>
>> It is important when trying to solve an issue not to introduce new
>> issues. The current proposal for #2 unfortunately does not take into
>> account known counter-measures for key recovery attacks in MACs (see [0]).
>>
>> regards,
>> Nikos
>>
>> [0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From Kenny.Paterson@rhul.ac.uk  Sun Nov 10 12:40:25 2013
Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 5DD8B21E8147 for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 12:40:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yzyRi-24-drr for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 12:40:19 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E321E809D for <tls@ietf.org>; Sun, 10 Nov 2013 12:40:18 -0800 (PST)
Received: from mail53-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Sun, 10 Nov 2013 20:39:59 +0000
Received: from mail53-va3 (localhost [127.0.0.1])	by mail53-va3-R.bigfish.com (Postfix) with ESMTP id CF3ED2E048B; Sun, 10 Nov 2013 20:39:59 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT001.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: PS-24(zzbb2dIdb82h98dI9371I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(189002)(199002)(377454003)(24454002)(479174003)(56776001)(81542001)(59766001)(81816001)(81342001)(69226001)(76482001)(54316002)(561944002)(87936001)(2656002)(85306002)(74706001)(77982001)(74366001)(77096001)(83072001)(4396001)(19580405001)(50986001)(36756003)(81686001)(47736001)(47976001)(49866001)(53806001)(15202345003)(54356001)(76176001)(46102001)(19580395003)(51856001)(87266001)(76796001)(74502001)(83322001)(66066001)(74662001)(80022001)(74876001)(63696002)(31966008)(65816001)(56816003)(80976001)(74482001)(47446002)(76786001)(83506001)(15975445006)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB288; H:DBXPR03MB287.eurprd03.prod.outlook.com; CLIP:80.42.233.244; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail53-va3 (localhost.localdomain [127.0.0.1]) by mail53-va3 (MessageSwitch) id 1384115997480084_17328; Sun, 10 Nov 2013 20:39:57 +0000 (UTC)
Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.232])	by mail53-va3.bigfish.com (Postfix) with ESMTP id 65BD62C01EE; Sun, 10 Nov 2013 20:39:57 +0000 (UTC)
Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 10 Nov 2013 20:39:57 +0000
Received: from DBXPR03MB288.eurprd03.prod.outlook.com (10.242.142.153) by AM2PRD0311HT001.eurprd03.prod.outlook.com (10.255.162.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Sun, 10 Nov 2013 20:39:56 +0000
Received: from DBXPR03MB287.eurprd03.prod.outlook.com (10.242.142.150) by DBXPR03MB288.eurprd03.prod.outlook.com (10.242.142.153) with Microsoft SMTP Server (TLS) id 15.0.815.6; Sun, 10 Nov 2013 20:39:37 +0000
Received: from DBXPR03MB287.eurprd03.prod.outlook.com ([169.254.7.84]) by DBXPR03MB287.eurprd03.prod.outlook.com ([169.254.7.200]) with mapi id 15.00.0815.000; Sun, 10 Nov 2013 20:39:37 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Watson Ladd <watsonbladd@gmail.com>, Michael D'Errico <mike-list@pobox.com>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO3lQ7mnUaIIfFcEaCeS9k+sy2l5oe7UAA
Date: Sun, 10 Nov 2013 20:39:36 +0000
Message-ID: <CEA59E7E.E9C5%kenny.paterson@rhul.ac.uk>
In-Reply-To: <CACsn0c=up8rP39cHfbxe-HAyFUszW60i_5dvoVY8gdmD=T6dYg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.233.244]
x-forefront-prvs: 0026334A56
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C04F8CE82E99794E821B28FDF04B6B6C@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Sun, 10 Nov 2013 20:40:25 -0000

Michael,

I posted on this back in September
(http://www.ietf.org/mail-archive/web/tls/current/msg09824.html). Let me
restate what I wrote then:

"I briefly reviewed the literature for the state-of-the-art on attacks
against HMAC-H for hash algorithm "H". (See for example
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf, and later papers by L.
Wang et al. at Eurocrypt 2008, by X. Wang et al. at Eurocrypt 2009, plus
more recent work, e.g. Peyrin et al. at Asiacrypt 2012.)

In TLS, we essentially have H =3D MD5, SHA-1 or SHA-256.  In view of the
literature, of these, I'd recommend deprecating MD5 as the hash if
Approach #2 were to be adopted: current attacks do not seriously threaten
it, but taking a fairly conservative approach seems appropriate here."



To summarise: the currently known attacks on MD5 do not have significant
consequences for the security of HMAC-MD5 in the TLS context.

So the issue you raise should not be holding things up.

Cheers

Kenny=20


On 10/11/2013 20:33, "Watson Ladd" <watsonbladd@gmail.com> wrote:

>On Sun, Nov 10, 2013 at 12:28 PM, Michael D'Errico <mike-list@pobox.com>
>wrote:
>> In trying to figure out what's stalling the encrypt-then-mac draft
>> I came across this old message (below).  The complaint against the
>> draft appears to be that since the MAC is no longer encrypted, there
>> may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
>> as the problem, so I checked to see which cipher suites use it.
>Who thinks this is a real problem? If the MAC is weak it shouldn't be
>used,
>end of story. We have a real issue burning people now, and the
>argument against it is
>something that won't be an issue for a while, and only affects people
>with their head in the
>sand.
>I say we publish it.
>>
>> The 13 cipher suites using MD5 are:
>>
>>   A     0001    TLS_RSA_WITH_NULL_MD5
>>   B     0003    TLS_RSA_EXPORT_WITH_RC4_40_MD5
>>   C     0004    TLS_RSA_WITH_RC4_128_MD5
>>   D     0006    TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
>>   E     0017    TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
>>   F     0018    TLS_DH_anon_WITH_RC4_128_MD5
>>   G     0022    TLS_KRB5_WITH_DES_CBC_MD5
>>   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
>>   I     0024    TLS_KRB5_WITH_RC4_128_MD5
>>   J     0025    TLS_KRB5_WITH_IDEA_CBC_MD5
>>   K     0029    TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
>>   L     002A    TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
>>   M     002B    TLS_KRB5_EXPORT_WITH_RC4_40_MD5
>>
>> Eight of these (A, B, D, E, G, K, L, and M) are considered trivially
>> breakable; F allows for a MitM; J uses the deprecated IDEA cipher;
>> and C and I use RC4 which we now know is completely broken.
>>
>> That leaves only one cipher suite to possibly be concerned about:
>>
>>   H     0023    TLS_KRB5_WITH_3DES_EDE_CBC_MD5
>>
>> Do we really want to hold up the encrypt-then-mac draft any longer
>> because of this one Kerberos/triple-DES/MD5 cipher suite?
>No.
>>
>> Mike
>>
>Sincerely,
>Watson Ladd
>>
>>
>>
>> Nikos Mavrogiannopoulos wrote:
>>>
>>> On 09/08/2013 04:59 AM, Peter Saint-Andre wrote:
>>>
>>>>> As I recall there were three proposals for resolving the padding
>>>>> bug in TLS
>>>>> 1.       An extension for Pad First (i.e. padding before an
>>>>> otherwise standard TLS mode of operation)
>>>>> 2.       An extension for Encrypt-then-MAC (i.e. this draft)
>>>>> 3.       The replacement of each existing cipher suite with an
>>>>> equivalent AEAD one
>>>>> Was any consensus achieved as to the best approach?
>>>>
>>>> I never saw further discussion on this topic. Are there I-Ds for each
>>>> approach? #3 seems onerous to me (and doubling the number of cipher
>>>> suites doesn't seem like a desirable outcome), and as far as I can
>>>> tell there's no specification for #1. Although I am not a TLS expert,
>>>> the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly
>>>> solves a real-world problem, and we have running code; thus IMHO
>>>> formalization of this approach deserves to be considered in the WG.
>>>
>>>
>>> It is important when trying to solve an issue not to introduce new
>>> issues. The current proposal for #2 unfortunately does not take into
>>> account known counter-measures for key recovery attacks in MACs (see
>>>[0]).
>>>
>>> regards,
>>> Nikos
>>>
>>> [0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
>--=20
>"Those who would give up Essential Liberty to purchase a little
>Temporary Safety deserve neither  Liberty nor Safety."
>-- Benjamin Franklin
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls
>



From mike-list@pobox.com  Sun Nov 10 19:49:32 2013
Return-Path: <mike-list@pobox.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 CA08521E81DB for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 19:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 zNUTTEyks2GA for <tls@ietfa.amsl.com>; Sun, 10 Nov 2013 19:49:28 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 742F121E81DA for <tls@ietf.org>; Sun, 10 Nov 2013 19:49:24 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 64E75E3CE; Sun, 10 Nov 2013 22:49:17 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Hgen9xzZlbgn OWBTxHJep4sxPhA=; b=Svth2pD1xoxc/YyR47UOxTh//3e2pjlvuNTSz+rUb7fU tphICdOvpVUNPbwsmmNhrR1TQEPdBUIfFrzRUse8ed2tr9NvVk9lFQs3bfK3PUbq SGW6Kswupbv/aCHNhfm7FLpgiaOZEVSxkEzLMYuE8M56ucDxRT+sbfbvP8ZUtRc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ubckcZ jcAemkZTtT2sk84CU8aeQ6oBItUVRGf9SGu3LHJpqShmAx2Zadk1JhjROpXorAKW gu7XkWplqqAN0ONVPhL9fW7I1LngHclNQOKd3CUo1jQXC/gMlJtS8iAgaOjboz5x tmwrylyswmwxHSpl363E+272W/Q92stmy/Qrs=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5B6FDE3CD; Sun, 10 Nov 2013 22:49:17 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id B86D7E3CC; Sun, 10 Nov 2013 22:49:16 -0500 (EST)
Message-ID: <528053BB.20801@pobox.com>
Date: Sun, 10 Nov 2013 19:49:15 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
References: <CEA59E7E.E9C5%kenny.paterson@rhul.ac.uk>
In-Reply-To: <CEA59E7E.E9C5%kenny.paterson@rhul.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 3CE90DF0-4A84-11E3-86ED-F66B0E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Mon, 11 Nov 2013 03:49:32 -0000

Paterson, Kenny wrote:
> So the issue you raise should not be holding things up.

Just to be clear, I didn't raise this issue.  It's the only
issue I came across that seems to be holding up the draft.

Mike

From lha@kth.se  Mon Nov 11 02:53:13 2013
Return-Path: <lha@kth.se>
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 9B0C711E815A for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 02:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.197
X-Spam-Level: 
X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_OBFU_ALL=0.751]
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 heJwNQ3glg3W for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 02:53:08 -0800 (PST)
Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de3]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97321E8091 for <tls@ietf.org>; Mon, 11 Nov 2013 02:53:08 -0800 (PST)
Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-4.sys.kth.se (Postfix) with ESMTP id 737461FF0 for <tls@ietf.org>; Mon, 11 Nov 2013 11:53:07 +0100 (CET)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-4.sys.kth.se ([130.237.48.193]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id m9U_r0vzT1yw for <tls@ietf.org>; Mon, 11 Nov 2013 11:53:02 +0100 (CET)
X-KTH-Auth: lha [80.216.20.112]
X-KTH-mail-from: lha@kth.se
X-KTH-rcpt-to: tls@ietf.org
Received: from [192.168.0.51] (c80-216-20-112.bredband.comhem.se [80.216.20.112]) by smtp-4.sys.kth.se (Postfix) with ESMTPSA id 0C41B1FD1 for <tls@ietf.org>; Mon, 11 Nov 2013 11:53:01 +0100 (CET)
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_41DEDA89-212D-49CF-83F3-C04912FB49B4"
Message-Id: <E4AD1150-692C-435F-924D-AF75DECE535D@kth.se>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1906\))
Date: Mon, 11 Nov 2013 11:52:55 +0100
References: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CEA27C78.1375B%uri@ll.mit.edu> <CAEKgtqk6D+q6-4Jb0afu2O9qRq=mE5_T_5UNrst2_BLmqVTFJw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <CAEKgtqk6D+q6-4Jb0afu2O9qRq=mE5_T_5UNrst2_BLmqVTFJw@mail.gmail.com>
X-Mailer: Apple Mail (2.1906)
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Mon, 11 Nov 2013 10:53:13 -0000

--Apple-Mail=_41DEDA89-212D-49CF-83F3-C04912FB49B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

[resend now that i=92m subscribed to the mailinglist]

AugPAKE is not defined for ECC, the draft just say that is possible to =
implement but not how. For example, is it safe for all kind of curves ?

AugPAKE have not test vectors in the draft. (very important because of =
the next point).

AugPAKE have no reference implementation that I=92ve found.

I have not seen a review of AugPAKE by IRTF CFRG.

AugPAKE is currently encumbered by IPR issues for all protocols.

Love


8 nov 2013 kl. 18:03 skrev SeongHan Shin <seonghan.shin@aist.go.jp>:

> FYI,
> AugPAKE is provably secure and can be used royal-free.
> AugPAKE
> https://tools.ietf.org/html/draft-shin-tls-augpake-01
> IPR Disclosures
> https://datatracker.ietf.org/ipr/2037/
>=20
> Regards,
> Shin
>=20
>=20
>=20
> On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL =
<uri@ll.mit.edu> wrote:
> On 11/8/13 1:50 , "Douglas Stebila" <stebila@qut.edu.au> wrote:
>=20
> >I believe that where possible the IETF should aim to standardize
> >cryptographic protocols that have provable security results.  Such =
proofs
> >of course don't guarantee the protocol is secure in all scenarios, =
but at
> >least rule out some classes of attacks.  In the field of password
> >authenticated key exchange, there are many provably secure protocols, =
and
> >so it would be preferable to see one such protocol adopted.
>=20
> I concur - except I believe that whenever possible the IETF should aim =
to
> standardize cryptographic protocols that are unencumbered by license =
fees
> and patents. If the choice arises between a protocol that carries both
> (provable security and Intellectual Property) and a protocol that has
> neither - I'd strongly prefer the latter.
>=20
>=20
>=20
> >On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)
> ><jsalowey@cisco.com> wrote:
> >
> >> This is the beginning of the working group last call for
> >>draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
> >>TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
> >>results.  The document needs particular attention paid to the
> >>integration of this mechanism into the TLS protocol.   Please send
> >>comments to the TLS list by December 2, 2013.
> >>
> >> - Joe
> >> (For the TLS chairs)
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >_______________________________________________
> >TLS mailing list
> >TLS@ietf.org
> >https://www.ietf.org/mailman/listinfo/tls
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
>=20
>=20
> --=20
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology =
(AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_41DEDA89-212D-49CF-83F3-C04912FB49B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>[resend now that i=92m subscribed to the =
mailinglist]</div><div><br></div><div>AugPAKE is not defined for ECC, =
the draft just say that is possible to implement but not how. For =
example, is it safe for all kind of curves =
?</div><div><br></div><div>AugPAKE have not test vectors in the draft. =
(very important because of the next =
point).</div><div><br></div><div>AugPAKE have no reference =
implementation that I=92ve found.</div><div><br></div><div>I have not =
seen a review of AugPAKE by IRTF CFRG.</div><div><br></div><div>AugPAKE =
is currently encumbered by IPR issues for all =
protocols.</div><div><br></div><div>Love</div><div><br></div><div><br></di=
v><div><div>8 nov 2013 kl. 18:03 skrev SeongHan Shin &lt;<a =
href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@aist.go.jp</a>&gt;:=
</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Diso-8859-1"><div dir=3D"ltr"><div><div>FYI,<br></div>AugPAKE =
is provably secure and can be used royal-free.<br>AugPAKE<br><a =
href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01">https://too=
ls.ietf.org/html/draft-shin-tls-augpake-01</a><br>
</div>IPR Disclosures<br><div><a =
href=3D"https://datatracker.ietf.org/ipr/2037/">https://datatracker.ietf.o=
rg/ipr/2037/</a><br><br></div><div>Regards,<br></div><div>Shin<br><br></di=
v></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <span =
dir=3D"ltr">&lt;<a href=3D"mailto:uri@ll.mit.edu" =
target=3D"_blank">uri@ll.mit.edu</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div class=3D"im">On 11/8/13 1:50 , "Douglas Stebila" &lt;<a =
href=3D"mailto:stebila@qut.edu.au">stebila@qut.edu.au</a>&gt; wrote:<br>
<br>
&gt;I believe that where possible the IETF should aim to standardize<br>
&gt;cryptographic protocols that have provable security results. =
&nbsp;Such proofs<br>
&gt;of course don't guarantee the protocol is secure in all scenarios, =
but at<br>
&gt;least rule out some classes of attacks. &nbsp;In the field of =
password<br>
&gt;authenticated key exchange, there are many provably secure =
protocols, and<br>
&gt;so it would be preferable to see one such protocol adopted.<br>
<br>
</div>I concur - except I believe that whenever possible the IETF should =
aim to<br>
standardize cryptographic protocols that are unencumbered by license =
fees<br>
and patents. If the choice arises between a protocol that carries =
both<br>
(provable security and Intellectual Property) and a protocol that =
has<br>
neither - I'd strongly prefer the latter.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
&gt;On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)<br>
&gt;&lt;<a href=3D"mailto:jsalowey@cisco.com">jsalowey@cisco.com</a>&gt; =
wrote:<br>
&gt;<br>
&gt;&gt; This is the beginning of the working group last call for<br>
&gt;&gt;draft-ietf-tls-pwd-01. &nbsp; The underlying cryptographic =
protocol for<br>
&gt;&gt;TLS-PWD has been reviewed by the IRTF CFRG group with =
satisfactory<br>
&gt;&gt;results. &nbsp;The document needs particular attention paid to =
the<br>
&gt;&gt;integration of this mechanism into the TLS protocol. &nbsp; =
Please send<br>
&gt;&gt;comments to the TLS list by December 2, 2013.<br>
&gt;&gt;<br>
&gt;&gt; - Joe<br>
&gt;&gt; (For the TLS chairs)<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; TLS mailing list<br>
&gt;&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;TLS mailing list<br>
&gt;<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/tls" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div><br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div =
style=3D"MARGIN:0mm 0mm 0pt"><span style=3D"FONT-FAMILY:'MS UI =
Gothic';FONT-SIZE:10pt" =
lang=3D"EN-US">-----------------------------------------------------------=
-------<br>
SeongHan Shin<br></span><span style=3D"FONT-FAMILY:'MS UI =
Gothic';FONT-SIZE:10pt" lang=3D"EN-US">Research Institute for Secure =
Systems (RISEC),<br>National Institute of Advanced Industrial Science =
and Technology (AIST),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : =
+81-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a =
href=3D"mailto:seonghan.shin@aist.go.jp" target=3D"_blank"><font =
color=3D"#0000ff">seonghan.shin@aist.go.jp</font></a><br>
=
------------------------------------------------------------------</span><=
/div>
</div>
_______________________________________________<br>TLS mailing =
list<br><a =
href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>https://www.ietf.org/mail=
man/listinfo/tls<br></blockquote></div><br></body></html>=

--Apple-Mail=_41DEDA89-212D-49CF-83F3-C04912FB49B4--

From lha@kth.se  Mon Nov 11 02:54:10 2013
Return-Path: <lha@kth.se>
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 E958511E815A for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 02:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.573
X-Spam-Level: 
X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.376,  BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3]
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 TdNTWtHOtZ0c for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 02:54:05 -0800 (PST)
Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de3]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1311E8158 for <tls@ietf.org>; Mon, 11 Nov 2013 02:54:05 -0800 (PST)
Received: from mailscan-2.sys.kth.se (mailscan-2.sys.kth.se [130.237.48.169]) by smtp-4.sys.kth.se (Postfix) with ESMTP id 2C97B1FD1; Mon, 11 Nov 2013 11:54:05 +0100 (CET)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-4.sys.kth.se ([130.237.48.193]) by mailscan-2.sys.kth.se (mailscan-2.sys.kth.se [130.237.48.169]) (amavisd-new, port 10024) with LMTP id erkVy7LIt7E7; Mon, 11 Nov 2013 11:54:00 +0100 (CET)
X-KTH-Auth: lha [80.216.20.112]
X-KTH-mail-from: lha@kth.se
Received: from [192.168.0.51] (c80-216-20-112.bredband.comhem.se [80.216.20.112]) by smtp-4.sys.kth.se (Postfix) with ESMTPSA id E23011E10; Mon, 11 Nov 2013 11:53:59 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1906\))
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
In-Reply-To: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
Date: Mon, 11 Nov 2013 11:53:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2258842-2FD1-4220-9428-74486A8FF232@kth.se>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
X-Mailer: Apple Mail (2.1906)
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Mon, 11 Nov 2013 10:54:11 -0000

No test vectors so hard to verify that implementation will have a chance =
to interoperate.

Love


8 nov 2013 kl. 02:11 skrev Joseph Salowey (jsalowey) =
<jsalowey@cisco.com>:

> This is the beginning of the working group last call for  =
draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for =
TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory =
results.  The document needs particular attention paid to the =
integration of this mechanism into the TLS protocol.   Please send =
comments to the TLS list by December 2, 2013. =20
>=20
> - Joe
> (For the TLS chairs)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From dharkins@lounge.org  Mon Nov 11 06:20:01 2013
Return-Path: <dharkins@lounge.org>
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 A805C21E8134 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 06:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.985
X-Spam-Level: 
X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 jYzEZqUxNbrv for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 06:19:57 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 84B6D21F9C7B for <tls@ietf.org>; Mon, 11 Nov 2013 06:19:57 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F08E7A888120; Mon, 11 Nov 2013 06:19:54 -0800 (PST)
Received: from 67.110.83.252 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 11 Nov 2013 06:19:55 -0800 (PST)
Message-ID: <590ea15a31d15e6a0a09cf41e53aeffa.squirrel@www.trepanning.net>
In-Reply-To: <F2258842-2FD1-4220-9428-74486A8FF232@kth.se>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <F2258842-2FD1-4220-9428-74486A8FF232@kth.se>
Date: Mon, 11 Nov 2013 06:19:55 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= <lha@kth.se>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Mon, 11 Nov 2013 14:20:01 -0000

  Hi Love,

On Mon, November 11, 2013 2:53 am, Love Hörnquist Åstrand wrote:
>
> No test vectors so hard to verify that implementation will have a chance
> to interoperate.

  Good comment. I will add test vectors showing a sample exchange in
an appendix of the next version. Speaking of interoperability, I have an
implementation and can put a server up on a globally-routable IP
address if anyone wants to try to interoperate, just let me know.

  thanks,

  Dan.

> 8 nov 2013 kl. 02:11 skrev Joseph Salowey (jsalowey) <jsalowey@cisco.com>:
>
>> This is the beginning of the working group last call for
>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>> TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
>> results.  The document needs particular attention paid to the
>> integration of this mechanism into the TLS protocol.   Please send
>> comments to the TLS list by December 2, 2013.
>>
>> - Joe
>> (For the TLS chairs)
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From lha@kth.se  Mon Nov 11 02:48:26 2013
Return-Path: <lha@kth.se>
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 E515C21E8210 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 02:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.197
X-Spam-Level: 
X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_OBFU_ALL=0.751]
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 8AR1JG6Azfj3 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 02:48:21 -0800 (PST)
Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de3]) by ietfa.amsl.com (Postfix) with ESMTP id 8411811E8156 for <tls@ietf.org>; Mon, 11 Nov 2013 02:48:20 -0800 (PST)
Received: from mailscan-3.sys.kth.se (mailscan-3.sys.kth.se [130.237.48.170]) by smtp-4.sys.kth.se (Postfix) with ESMTP id E52275F8; Mon, 11 Nov 2013 11:48:18 +0100 (CET)
X-Virus-Scanned: by amavisd-new at kth.se
Received: from smtp-4.sys.kth.se ([130.237.48.193]) by mailscan-3.sys.kth.se (mailscan-3.sys.kth.se [130.237.48.170]) (amavisd-new, port 10024) with LMTP id v-XcPMRGJ0Pt; Mon, 11 Nov 2013 11:48:16 +0100 (CET)
X-KTH-Auth: lha [80.216.20.112]
X-KTH-mail-from: lha@kth.se
Received: from [192.168.0.51] (c80-216-20-112.bredband.comhem.se [80.216.20.112]) by smtp-4.sys.kth.se (Postfix) with ESMTPSA id A3D521EDF; Mon, 11 Nov 2013 11:48:14 +0100 (CET)
Content-Type: multipart/alternative; boundary="Apple-Mail=_196A4D46-8479-4E0F-B77F-89CD1ACE142C"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1906\))
From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>
In-Reply-To: <CAEKgtqk6D+q6-4Jb0afu2O9qRq=mE5_T_5UNrst2_BLmqVTFJw@mail.gmail.com>
Date: Mon, 11 Nov 2013 11:48:07 +0100
Message-Id: <93F28FDE-EDF2-4FC0-BB45-383974A301F9@kth.se>
References: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CEA27C78.1375B%uri@ll.mit.edu> <CAEKgtqk6D+q6-4Jb0afu2O9qRq=mE5_T_5UNrst2_BLmqVTFJw@mail.gmail.com>
To: SeongHan Shin <seonghan.shin@aist.go.jp>
X-Mailer: Apple Mail (2.1906)
X-Mailman-Approved-At: Mon, 11 Nov 2013 08:49:22 -0800
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Mon, 11 Nov 2013 10:48:27 -0000

--Apple-Mail=_196A4D46-8479-4E0F-B77F-89CD1ACE142C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

AugPAKE is not defined for ECC, the draft just say that is possible to =
implement but not how. For example, is it safe for all kind of curves ?

AugPAKE have not test vectors in the draft. (very important because of =
the next point).

AugPAKE have no reference implementation that I=92ve found.

I have not seen a review of AugPAKE by IRTF CFRG.

AugPAKE is currently encumbered by IPR issues for all protocols.

Love

8 nov 2013 kl. 18:03 skrev SeongHan Shin <seonghan.shin@aist.go.jp>:

> FYI,
> AugPAKE is provably secure and can be used royal-free.
> AugPAKE
> https://tools.ietf.org/html/draft-shin-tls-augpake-01
> IPR Disclosures
> https://datatracker.ietf.org/ipr/2037/
>=20
> Regards,
> Shin
>=20
>=20
>=20
> On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL =
<uri@ll.mit.edu> wrote:
> On 11/8/13 1:50 , "Douglas Stebila" <stebila@qut.edu.au> wrote:
>=20
> >I believe that where possible the IETF should aim to standardize
> >cryptographic protocols that have provable security results.  Such =
proofs
> >of course don't guarantee the protocol is secure in all scenarios, =
but at
> >least rule out some classes of attacks.  In the field of password
> >authenticated key exchange, there are many provably secure protocols, =
and
> >so it would be preferable to see one such protocol adopted.
>=20
> I concur - except I believe that whenever possible the IETF should aim =
to
> standardize cryptographic protocols that are unencumbered by license =
fees
> and patents. If the choice arises between a protocol that carries both
> (provable security and Intellectual Property) and a protocol that has
> neither - I'd strongly prefer the latter.
>=20
>=20
>=20
> >On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)
> ><jsalowey@cisco.com> wrote:
> >
> >> This is the beginning of the working group last call for
> >>draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
> >>TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
> >>results.  The document needs particular attention paid to the
> >>integration of this mechanism into the TLS protocol.   Please send
> >>comments to the TLS list by December 2, 2013.
> >>
> >> - Joe
> >> (For the TLS chairs)
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >
> >_______________________________________________
> >TLS mailing list
> >TLS@ietf.org
> >https://www.ietf.org/mailman/listinfo/tls
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
>=20
>=20
> --=20
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology =
(AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_196A4D46-8479-4E0F-B77F-89CD1ACE142C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>AugPAKE is not defined for ECC, the draft just =
say that is possible to implement but not how. For example, is it safe =
for all kind of curves ?</div><div><br></div><div>AugPAKE have not test =
vectors in the draft. (very important because of the next =
point).</div><div><br></div><div>AugPAKE have no reference =
implementation that I=92ve found.</div><div><br></div><div>I have not =
seen a review of AugPAKE by IRTF CFRG.</div><div><br></div><div>AugPAKE =
is currently encumbered by IPR issues for all =
protocols.</div><div><br></div><div>Love</div><br><div><div>8 nov 2013 =
kl. 18:03 skrev SeongHan Shin &lt;<a =
href=3D"mailto:seonghan.shin@aist.go.jp">seonghan.shin@aist.go.jp</a>&gt;:=
</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Diso-8859-1"><div dir=3D"ltr"><div><div>FYI,<br></div>AugPAKE =
is provably secure and can be used royal-free.<br>AugPAKE<br><a =
href=3D"https://tools.ietf.org/html/draft-shin-tls-augpake-01">https://too=
ls.ietf.org/html/draft-shin-tls-augpake-01</a><br>
</div>IPR Disclosures<br><div><a =
href=3D"https://datatracker.ietf.org/ipr/2037/">https://datatracker.ietf.o=
rg/ipr/2037/</a><br><br></div><div>Regards,<br></div><div>Shin<br><br></di=
v></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <span =
dir=3D"ltr">&lt;<a href=3D"mailto:uri@ll.mit.edu" =
target=3D"_blank">uri@ll.mit.edu</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div class=3D"im">On 11/8/13 1:50 , "Douglas Stebila" &lt;<a =
href=3D"mailto:stebila@qut.edu.au">stebila@qut.edu.au</a>&gt; wrote:<br>
<br>
&gt;I believe that where possible the IETF should aim to standardize<br>
&gt;cryptographic protocols that have provable security results. =
&nbsp;Such proofs<br>
&gt;of course don't guarantee the protocol is secure in all scenarios, =
but at<br>
&gt;least rule out some classes of attacks. &nbsp;In the field of =
password<br>
&gt;authenticated key exchange, there are many provably secure =
protocols, and<br>
&gt;so it would be preferable to see one such protocol adopted.<br>
<br>
</div>I concur - except I believe that whenever possible the IETF should =
aim to<br>
standardize cryptographic protocols that are unencumbered by license =
fees<br>
and patents. If the choice arises between a protocol that carries =
both<br>
(provable security and Intellectual Property) and a protocol that =
has<br>
neither - I'd strongly prefer the latter.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
&gt;On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)<br>
&gt;&lt;<a href=3D"mailto:jsalowey@cisco.com">jsalowey@cisco.com</a>&gt; =
wrote:<br>
&gt;<br>
&gt;&gt; This is the beginning of the working group last call for<br>
&gt;&gt;draft-ietf-tls-pwd-01. &nbsp; The underlying cryptographic =
protocol for<br>
&gt;&gt;TLS-PWD has been reviewed by the IRTF CFRG group with =
satisfactory<br>
&gt;&gt;results. &nbsp;The document needs particular attention paid to =
the<br>
&gt;&gt;integration of this mechanism into the TLS protocol. &nbsp; =
Please send<br>
&gt;&gt;comments to the TLS list by December 2, 2013.<br>
&gt;&gt;<br>
&gt;&gt; - Joe<br>
&gt;&gt; (For the TLS chairs)<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; TLS mailing list<br>
&gt;&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;TLS mailing list<br>
&gt;<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/tls" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div><br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div =
style=3D"MARGIN:0mm 0mm 0pt"><span style=3D"FONT-FAMILY:'MS UI =
Gothic';FONT-SIZE:10pt" =
lang=3D"EN-US">-----------------------------------------------------------=
-------<br>
SeongHan Shin<br></span><span style=3D"FONT-FAMILY:'MS UI =
Gothic';FONT-SIZE:10pt" lang=3D"EN-US">Research Institute for Secure =
Systems (RISEC),<br>National Institute of Advanced Industrial Science =
and Technology (AIST),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : =
+81-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a =
href=3D"mailto:seonghan.shin@aist.go.jp" target=3D"_blank"><font =
color=3D"#0000ff">seonghan.shin@aist.go.jp</font></a><br>
=
------------------------------------------------------------------</span><=
/div>
</div>
_______________________________________________<br>TLS mailing =
list<br><a =
href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>https://www.ietf.org/mail=
man/listinfo/tls<br></blockquote></div><br></body></html>=

--Apple-Mail=_196A4D46-8479-4E0F-B77F-89CD1ACE142C--

From wtc@google.com  Mon Nov 11 10:18:21 2013
Return-Path: <wtc@google.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 D464F21E80C0 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, 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 Pt5VRqS0R9UA for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:18:21 -0800 (PST)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C503821E8203 for <tls@ietf.org>; Mon, 11 Nov 2013 10:18:18 -0800 (PST)
Received: by mail-vc0-f175.google.com with SMTP id ht17so1427003vcb.20 for <tls@ietf.org>; Mon, 11 Nov 2013 10:18:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jRuKeCXykT/6RK8eqTxbssUdBMAPQYsJ38ZOobfxaO0=; b=M0mSs+Hat/p4slCVJAmZgOwlP+NIaOlT9Qo6w5yzMX+l4qB1gT61SD6GeefQVf9prg 1HSSnbTukGDZjo/alJejAXbdCVMVq+bWNTDgmLpH2YtJ0PsBjXf1BXXMhVbTyppcbkVg eBYwuRDJ1UuzpQ9doBI6/W9GuuNcOLWawX3k2uGRtt6mZg7rEkPO2QL/N4zMJz8afOy/ CT5rdhP1dnd9WM8tLniq9xevjT5QLMG0WUgwSIqj1tMKMkKxC4h7UxFhuY2KHyFII+ad NsenciaI3lODLDE3soUazU0I9t8BPs9O6fSyCDcv4rbSNhCnp6Ummz33kbmjpcqcMrnb RDPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jRuKeCXykT/6RK8eqTxbssUdBMAPQYsJ38ZOobfxaO0=; b=fdV2ttRsLl+X2YG25oF9BuYAaC5x0QqdP0VTiatIIiptAVih+xNinEqZb5ykrtLe9a y1gG+Rxgu6hKSgjpK866GDku06oJf2V9EH/lumoiunQZ2Q53t6TsXkDkdhoBULry/Szh w3f+2027bBiAGJvpumuTMjsIO+nvVpJ9snKPiM46XnjahHPOO3mD1BOBqjpzCI6+ii0k JJHeEEwmEksJBPI32Rr7PBhBCvc0dMvrEmGwUmmR9UygNFoaELYTG4u/7t9A0R9oL10q +BLeuBrBi0xZHmmKlU7gYDH5hPtAs4Yb9LNqkDIdqSRIkx8Ygi8RgorFdTNaiGrzU+xQ yVLw==
X-Gm-Message-State: ALoCoQkJfeMkA7u+E42G15uwy+jwg5Od49LD9GdLjd7fxrmiqfse+msWJaEcb/HLZ9F7F2eIcUTt4szx7mBUgsCJqT9QK2AEziJc7B8CG3FwY1Rjo298LndSgQUEFapd7ZFQW22JSv5ajlXxEM286DdadyRrQ2eM30zGiJob1WtG702kEaYRGHP/pSZ/Zba13Y2lL0absnAL
MIME-Version: 1.0
X-Received: by 10.220.244.132 with SMTP id lq4mr118835vcb.31.1384193897325; Mon, 11 Nov 2013 10:18:17 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Mon, 11 Nov 2013 10:18:17 -0800 (PST)
In-Reply-To: <20131107213744.GQ18713@localhost>
References: <20131107213744.GQ18713@localhost>
Date: Mon, 11 Nov 2013 10:18:17 -0800
Message-ID: <CALTJjxEZ0UVH_Pba7YYhrN7T-P-hUYRjxDkrUJq9p_ij7fspNw@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
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: Mon, 11 Nov 2013 18:18:21 -0000

On Thu, Nov 7, 2013 at 1:37 PM, Nico Williams <nico@cryptonector.com> wrote:
> A non-subscriber (who doesn't want to subscribe just to send this) has
> asked me to forward this to the TLS WG list.  Without further ado:
>
> From: Viktor Dukhovni <postfix-users@dukhovni.org>
> Subject: Windows 2003 TLS 64 ciphersuite limit
> Date: Thu, 7 Nov 2013 19:40:16 +0000
>
> [ Please forward to TLS list ]
>
> While we're removing interoperability obstacles with TLSv1.2, ...
> There is another problem with expanded client HELLO messages.
>
> The Windows 2003 TLS stack (still used by a non-trivial number of
> Microsoft Exchange SMTP servers) only looks at the first 64 elements
> of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
> it sometimes chooses 3DES (for which it misimplements CBC padding)
> and fails during data transfer, or if that is suppressed or also
> too far down the list, just fails the handshake.

Thank you for forwarding this message. This is useful information.

This seems to imply we must include RC4-SHA or RC4-MD5 in the cipher
suite list to prevent the Windows Server 2003 from selecting 3DES.

> With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4
> at position:
>
>     $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-'
>     93:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>
>     $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4-'
>     111:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>
> so TLS handshakes with these servers fail!
>
> It is not clear what should be done here, the most practical
> reordering and trimming that comes to mind is:
>
>     $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA'
>     51:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

Yes, trimming weak, export, and rarely used ciphers is a good solution.

Wan-Teh

From watsonbladd@gmail.com  Mon Nov 11 10:28:26 2013
Return-Path: <watsonbladd@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 6AD4D11E8153 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level: 
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 YGjWqFk619LH for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:28:25 -0800 (PST)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 760B911E814D for <tls@ietf.org>; Mon, 11 Nov 2013 10:28:25 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id u57so5023439wes.29 for <tls@ietf.org>; Mon, 11 Nov 2013 10:28:24 -0800 (PST)
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=3BrRXlubdSLCxRcd8uO3h6ytMkM8GrvoFtCWnz+P8oU=; b=eENaXzoefvVstgz1dtQDjXNiCzv0aeOLbEIA5QYwCtDSx8aQqPPIRpPuuxHPS5xiMK CJ2vv7EEwk1wxgT0XaFVuT9WLxP1qZ1XCWuwtNrH8VlxCOUm0OZnG980MwG1JpUfyEmz sGh0aEPt+76rJrjGrb09r6VaLikpcE0z5m5uE7pP4ota9ea9XkCgMIzdUWvrpOCJJ0L5 fK/knXrau1E2cZEuF5yviBb1NUDbdGpx1sMrMGTIH0PN+GKWq/MNyMxbwCK+pLwqls57 I8YZH5T+3RTwee9LvAl7FAMHG1I8YiV/LZ8ApLVZcHL8X+4widPgZ35CQg3IYjl8oV0b SYMA==
MIME-Version: 1.0
X-Received: by 10.194.239.40 with SMTP id vp8mr2479429wjc.45.1384194504090; Mon, 11 Nov 2013 10:28:24 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 11 Nov 2013 10:28:24 -0800 (PST)
In-Reply-To: <CALTJjxEZ0UVH_Pba7YYhrN7T-P-hUYRjxDkrUJq9p_ij7fspNw@mail.gmail.com>
References: <20131107213744.GQ18713@localhost> <CALTJjxEZ0UVH_Pba7YYhrN7T-P-hUYRjxDkrUJq9p_ij7fspNw@mail.gmail.com>
Date: Mon, 11 Nov 2013 10:28:24 -0800
Message-ID: <CACsn0c=hZxPx840K--XGp0Bom0wao0Ka0ee1HB3t2OrO3_yoOw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Wan-Teh Chang <wtc@google.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
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: Mon, 11 Nov 2013 18:28:26 -0000

On Mon, Nov 11, 2013 at 10:18 AM, Wan-Teh Chang <wtc@google.com> wrote:
> On Thu, Nov 7, 2013 at 1:37 PM, Nico Williams <nico@cryptonector.com> wrote:
>> A non-subscriber (who doesn't want to subscribe just to send this) has
>> asked me to forward this to the TLS WG list.  Without further ado:
>>
>> From: Viktor Dukhovni <postfix-users@dukhovni.org>
>> Subject: Windows 2003 TLS 64 ciphersuite limit
>> Date: Thu, 7 Nov 2013 19:40:16 +0000
>>
>> [ Please forward to TLS list ]
>>
>> While we're removing interoperability obstacles with TLSv1.2, ...
>> There is another problem with expanded client HELLO messages.
>>
>> The Windows 2003 TLS stack (still used by a non-trivial number of
>> Microsoft Exchange SMTP servers) only looks at the first 64 elements
>> of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
>> it sometimes chooses 3DES (for which it misimplements CBC padding)
>> and fails during data transfer, or if that is suppressed or also
>> too far down the list, just fails the handshake.
>
> Thank you for forwarding this message. This is useful information.
>
> This seems to imply we must include RC4-SHA or RC4-MD5 in the cipher
> suite list to prevent the Windows Server 2003 from selecting 3DES.
What is so bad about 3DES? Last I checked it was stronger than RC4.
The misimplementation is a bigger problem.
>
>> With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4
>> at position:
>>
>>     $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-'
>>     93:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>>
>>     $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4-'
>>     111:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
>>
>> so TLS handshakes with these servers fail!
>>
>> It is not clear what should be done here, the most practical
>> reordering and trimming that comes to mind is:
>>
>>     $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA'
>>     51:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
This reordering enables DES with 56 bit keys. Yes it is at the bottom,
but it should never be allowed to happen.
>
> Yes, trimming weak, export, and rarely used ciphers is a good solution.
>
> Wan-Teh
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From mrex@sap.com  Mon Nov 11 10:47:58 2013
Return-Path: <mrex@sap.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 0AA6D21E80E4 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:47:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.17
X-Spam-Level: 
X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 yrKxLreBNTSE for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:47:52 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B421E80A5 for <tls@ietf.org>; Mon, 11 Nov 2013 10:47:52 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rABIlngB001872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Nov 2013 19:47:49 +0100 (MET)
In-Reply-To: <20131107213744.GQ18713@localhost>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 11 Nov 2013 19:47:48 +0100 (CET)
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: <20131111184748.F0D441AA74@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 11 Nov 2013 18:47:58 -0000

Nico Williams wrote:
> 
> The Windows 2003 TLS stack (still used by a non-trivial number of
> Microsoft Exchange SMTP servers) only looks at the first 64 elements
> of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
> it sometimes chooses 3DES (for which it misimplements CBC padding)
> and fails during data transfer, or if that is suppressed or also
> too far down the list, just fails the handshake.

Is there any further information available of what exactly does not
work with Windows 2003 3DES-CBC cipher suite?

I see other TLS implementations interoperate just fine with 
Windows 2003 using the DES3-CBC-SHA TLS cipher suite.

I do have installed the AES cipher suites update for schannel
on my Windows 2003 machine, but there is no mentioning that
it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.

  http://support.microsoft.com/kb/948963

-Martin

From mrex@sap.com  Mon Nov 11 10:53:35 2013
Return-Path: <mrex@sap.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 B577911E8165 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.173
X-Spam-Level: 
X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 sC8BeIGc+apW for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 10:53:30 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 575E821E80A5 for <tls@ietf.org>; Mon, 11 Nov 2013 10:53:30 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rABIrRKh002240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Nov 2013 19:53:27 +0100 (MET)
In-Reply-To: <20131111184748.F0D441AA74@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Mon, 11 Nov 2013 19:53:27 +0100 (CET)
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: <20131111185327.416681AA74@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 11 Nov 2013 18:53:35 -0000

Martin Rex wrote:
> Nico Williams wrote:
> > 
> > The Windows 2003 TLS stack (still used by a non-trivial number of
> > Microsoft Exchange SMTP servers) only looks at the first 64 elements
> > of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
> > it sometimes chooses 3DES (for which it misimplements CBC padding)
> > and fails during data transfer, or if that is suppressed or also
> > too far down the list, just fails the handshake.
> 
> Is there any further information available of what exactly does not
> work with Windows 2003 3DES-CBC cipher suite?
> 
> I see other TLS implementations interoperate just fine with 
> Windows 2003 using the DES3-CBC-SHA TLS cipher suite.
> 
> I do have installed the AES cipher suites update for schannel
> on my Windows 2003 machine, but there is no mentioning that
> it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.
> 
>   http://support.microsoft.com/kb/948963
 

Well, that KB-Article talks about fixing interop problems between
Exchange & Sendmail/Postfix in the "More Information" section.
It doesn't mention 3DES anywhere, though.

-Martin

From wtc@google.com  Mon Nov 11 11:08:47 2013
Return-Path: <wtc@google.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 B5C3311E81CB for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 11:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UAKrJBrkamek for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 11:08:43 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2114611E8165 for <tls@ietf.org>; Mon, 11 Nov 2013 11:08:33 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id c14so3625566vea.32 for <tls@ietf.org>; Mon, 11 Nov 2013 11:08:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yBCJcOPmmIHhW2GVxEvzKdgg5Hq+BqAFRlI31yYYuHE=; b=VMF+DE2K0oHQMZWw1LfITH6WaruKxZGJU2er2sRjQZFPgrT5MdlxXVWMVhrEupUyt3 U99F3Pqvzi1jHlPwdfpXoOBuWMa2u9UOV4wJ5CIe4Au3NCJ2/z9ofE1lx7nAx/BiLqwh 3HAEQSATjXmy6bd2fhdDWMS3V9D/0ab2Yy21q0D9b4LR3QjNRO8IBUjq6JvNSfQoaBVT fCbOfsRVQaGpNw7fn3pwkPbLZ8dpxb9oKeuwmXn8nC97xTVrnU7nTr2GaT8WAa/7GIgX 9W6ULXBvoxwmUduDneMLJcovqiucsld9YTObNLWJ5KvlzXEaWGQ7TR39/lzwZqzf84eB Tutg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yBCJcOPmmIHhW2GVxEvzKdgg5Hq+BqAFRlI31yYYuHE=; b=Ke1tRQDfozeUOcUkUSFmpWhhdHkQvcawhcVWEQYr8WYKoIMsZX5C8tc8vVMyiNd/7L ECyusyGoOtoxwevuyxlVwdow9PkdkA76kpK4I9rJ4aj+hcQV+D3zfhOynW+vtU7mULfa rk/TlE3D/whyOFA1TTZz5dvy3foZPg8AoO1Wjz2mqX2IcGzivuXbF3c8zHUfKNtHKDg/ wqZQ50D4wNyoM2UztMtIBBrBDL2UnUH1PxD/rEHJDCUI4P3AkQLlf4s1PCQzSKpezfiE xr60oJ3NuthiZ8quzSsswPfi69N50xkb3ZBxSJFiRbW73lRXK9XFffjAnWXAW9fKkOrl N65A==
X-Gm-Message-State: ALoCoQl2gEBMBX9QkPjLXSaCSkuRq/wMRf80CqvOwMB29le1n0x9w2QaME7QKLbOjzKHzgLyvIaflSZ2tKlOK5wIbooJR5qbIXiyXWQ/vnq7dNC3wkOEj7XUjuxs9G4sn+5dP3UT3w2Qc6EnUW+3VHGEu738fwGv7fvR3nQU2i/yhnqgLs4rnNhFy8g7Fl3FYNd4KinRuAEU
MIME-Version: 1.0
X-Received: by 10.221.51.206 with SMTP id vj14mr25323028vcb.17.1384196890119;  Mon, 11 Nov 2013 11:08:10 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Mon, 11 Nov 2013 11:08:10 -0800 (PST)
In-Reply-To: <CACsn0c=hZxPx840K--XGp0Bom0wao0Ka0ee1HB3t2OrO3_yoOw@mail.gmail.com>
References: <20131107213744.GQ18713@localhost> <CALTJjxEZ0UVH_Pba7YYhrN7T-P-hUYRjxDkrUJq9p_ij7fspNw@mail.gmail.com> <CACsn0c=hZxPx840K--XGp0Bom0wao0Ka0ee1HB3t2OrO3_yoOw@mail.gmail.com>
Date: Mon, 11 Nov 2013 11:08:10 -0800
Message-ID: <CALTJjxGwKge8PgG2ydot4Ve1V2szhnTGPi-s+Qcw5++p5NKcRQ@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
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: Mon, 11 Nov 2013 19:08:47 -0000

On Mon, Nov 11, 2013 at 10:28 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Mon, Nov 11, 2013 at 10:18 AM, Wan-Teh Chang <wtc@google.com> wrote:
>> On Thu, Nov 7, 2013 at 1:37 PM, Nico Williams <nico@cryptonector.com> wrote:
>>>
>>> The Windows 2003 TLS stack (still used by a non-trivial number of
>>> Microsoft Exchange SMTP servers) only looks at the first 64 elements
>>> of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
>>> it sometimes chooses 3DES (for which it misimplements CBC padding)
>>> and fails during data transfer, or if that is suppressed or also
>>> too far down the list, just fails the handshake.
>>
>> Thank you for forwarding this message. This is useful information.
>>
>> This seems to imply we must include RC4-SHA or RC4-MD5 in the cipher
>> suite list to prevent the Windows Server 2003 from selecting 3DES.
>
> What is so bad about 3DES? Last I checked it was stronger than RC4.
> The misimplementation is a bigger problem.

I was referring to the misimplementation of CBC padding that Viktor
Dukhovni mentioned.

Wan-Teh Chang

From lists@drh-consultancy.co.uk  Mon Nov 11 11:18:50 2013
Return-Path: <lists@drh-consultancy.co.uk>
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 45BAA11E8240 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 11:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 PV8dbJD2Nqaa for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 11:18:44 -0800 (PST)
Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF211E8243 for <tls@ietf.org>; Mon, 11 Nov 2013 11:18:39 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:44506 helo=[192.168.7.9]) by relay03.mail.eu.clara.net (relay.clara.net [213.253.3.43]:10465) with esmtpa (authdaemon_plain:drh) id 1Vfx0O-0005GL-An for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Mon, 11 Nov 2013 19:18:36 +0000
Message-ID: <52812D8B.8050808@drh-consultancy.co.uk>
Date: Mon, 11 Nov 2013 19:18:35 +0000
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131111184748.F0D441AA74@ld9781.wdf.sap.corp>
In-Reply-To: <20131111184748.F0D441AA74@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
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: Mon, 11 Nov 2013 19:18:50 -0000

On 11/11/2013 18:47, Martin Rex wrote:
> 
> I do have installed the AES cipher suites update for schannel
> on my Windows 2003 machine, but there is no mentioning that
> it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.
> 
>   http://support.microsoft.com/kb/948963
> 

That KB does seem a little bit confused...

"This update adds support for the following Advanced Encryption Standard (AES)
cipher suites in the Schannel.dll module for Windows Server 2003:

    TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
    TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

Note These cipher suites are based on the RC4 algorithm."

and later...

"For example, OpenSSL is used in Sendmail, Postfix, Firefox, and Thunderbird."

quite a few other strange statements follow too.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From mrex@sap.com  Mon Nov 11 11:39:10 2013
Return-Path: <mrex@sap.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 DBFC721E80EA for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 11:39:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.176
X-Spam-Level: 
X-Spam-Status: No, score=-10.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 8D-cXEopfyOh for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 11:39:05 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 616A511E81B3 for <tls@ietf.org>; Mon, 11 Nov 2013 11:39:04 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rABJd01K006018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Nov 2013 20:39:00 +0100 (MET)
In-Reply-To: <20131111185327.416681AA74@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Mon, 11 Nov 2013 20:39:00 +0100 (CET)
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: <20131111193900.AF0751AA74@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 11 Nov 2013 19:39:11 -0000

Martin Rex wrote:
> > > The Windows 2003 TLS stack
> > > ... sometimes chooses 3DES (for which it misimplements CBC padding)
> > > and fails during data transfer, or if that is suppressed or also
> > > too far down the list, just fails the handshake.
> > 
> > I see other TLS implementations interoperate just fine with 
> > Windows 2003 using the DES3-CBC-SHA TLS cipher suite.
> > 
> > I do have installed the AES cipher suites update for schannel
> > on my Windows 2003 machine, but there is no mentioning that
> > it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.
> > 
> >   http://support.microsoft.com/kb/948963

I just installed a Web-Server certificate on another Windows2003 server
that doesn't have the AES ciphersuites Hotfix installed.

Seems to interop fine on the DES3-CBC-SHA (0x00, 0x0a) cipher suite.
(using my own client, openssl-1.0.1c and Firefox 25)

-Martin

From mrex@sap.com  Mon Nov 11 12:27:40 2013
Return-Path: <mrex@sap.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 1269B11E8102 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 12:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.178
X-Spam-Level: 
X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 mfsTys0Pg-HC for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 12:27:33 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DE8B411E811D for <tls@ietf.org>; Mon, 11 Nov 2013 12:27:32 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rABKR61f025960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Nov 2013 21:27:06 +0100 (MET)
In-Reply-To: <527E067F.9010209@edelweb.fr>
To: Peter Sylvester <peter.sylvester@edelweb.fr>
Date: Mon, 11 Nov 2013 21:27:06 +0100 (CET)
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: <20131111202706.7522D1AA77@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 11 Nov 2013 20:27:40 -0000

Peter Sylvester wrote:
> > Johannes Merkle wrote:
> >> I think you are wrong: Section 7.4.2 of RFC 4346 states
> >>
> >>                                Unless otherwise specified, the signing
> >>        algorithm for the certificate MUST be the same as the algorithm
> >>        for the certificate key.
>
> Taking this out of context is not helpful
> The specifications makes statements about what the sender has to
> do, not what the receiver has to verify.

The words in the TLS specification do not say who should to what.
With your rationale, this is a mere prayer addressed at nobody.  :)


> 
> > The history of this obvious defect starts in rfc2246.
> >
> > There exists no such artificial limitation in SSLv3, and when I looked
> > at implementations I've been using for interop testing a few
> > years ago (Microsoft SChannel, OpenSSL, Firefox), they would
> > happily interoperate with an RSA server cert signed by a CA with a
> > DSA key.  To me it looks like most implementors were either not
> > aware of this bogus, backwards-incompatible requirement,
> > or they applied common sense and deliberately ignored it.
>
> What is bogus in restricting a sender to be conservative?


As if the _sender_ (implementation!!) had a choice.

Which TLS implementations are prepared of handling two server certificates
that differ only in the CAs signature algorithm (i.e. same server public
key, same name attributes, same key usages)?

That would be bridging PKIs at the end-entity level.  I assume
that bridging is normally done at the CA level.


And how many real-world TLS servers are actually configured
with such almost-twins server certificates?

The vast majority of Web Servers have only a single server
certificate, and those that have different certs, either
have certificates ditinct by public key algorithm or distinct
by (server)name.


-Martin

From n.mavrogiannopoulos@gmail.com  Mon Nov 11 14:15:04 2013
Return-Path: <n.mavrogiannopoulos@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 9944521E80F4 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 14:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 g7gX07duxyow for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 14:15:04 -0800 (PST)
Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id E76C821E8092 for <tls@ietf.org>; Mon, 11 Nov 2013 14:15:03 -0800 (PST)
Received: by mail-ee0-f53.google.com with SMTP id e51so2794415eek.12 for <tls@ietf.org>; Mon, 11 Nov 2013 14:15:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:date:content-type:mime-version :content-transfer-encoding; bh=mNDCYHRZDoOX7io9LpThLuTfDG8Wo7Lzu28ryMiMybM=; b=ookLhJ9E49kA5RBP5EeHLZr88Q31+kxwywL0BXHYrU+3/hsR0M2imelKJ53PIaQuBN W0LNlX2qJgkwP8SHAlDO6yHn/ZksWbE6mceC8UZStudfr2QOy/0QOgAs96mXIgAyLx+n k5Kp9k3BmAMeeD6f941FEbH45Tiv97m1FtuEhonw2DjnDpVDVZOCeUrl3c3GijRAxpLk aKoXL8iwzAmIYCN3j3JEh0ZG5ox0NFJ6/v3d4gUMH0Wy3h+9yzLP7UP0p7R425m90VbY tUt5YN89yg+ye2t4cguJh2V5rvM+DN5pdPpGbHYShgV/RZfCai1Bvcv8Yg28AJyvCS+o Kofg==
X-Received: by 10.14.5.3 with SMTP id 3mr11518214eek.49.1384208102819; Mon, 11 Nov 2013 14:15:02 -0800 (PST)
Received: from [10.100.2.3] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id z2sm68096621eee.7.2013.11.11.14.15.01 for <tls@ietf.org> (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 11 Nov 2013 14:15:02 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <1384208096.2754.4.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "tls@ietf.org" <tls@ietf.org>
Date: Mon, 11 Nov 2013 23:14:56 +0100
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.1 (3.10.1-1.fc20)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [TLS] draft-josefsson-salsa20-tls-03
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: Mon, 11 Nov 2013 22:15:04 -0000

Hello,
 Few days ago we updated draft-josefsson-salsa20-tls-03 [0]. The draft
is now focused on describing a cipher to replace RC4 that is applicable
in TLS and DTLS. In the updated draft we argue on the usage of salsa20
instead of Chacha proposed by some members of this list (and CFRG).

The main change is that this draft no longer copes with providing
combinations with universal hash-based MACs leaving that out of its
scope.

regards,
Nikos

[0]. http://tools.ietf.org/html/draft-josefsson-salsa20-tls-03



From mrex@sap.com  Mon Nov 11 15:34:09 2013
Return-Path: <mrex@sap.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 6F6F321E809C for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 15:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.18
X-Spam-Level: 
X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 Hi14-z6jSKEz for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 15:33:54 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2111E80D9 for <tls@ietf.org>; Mon, 11 Nov 2013 15:33:53 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rABNXo1m011655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Nov 2013 00:33:50 +0100 (MET)
In-Reply-To: <527FEC83.9020107@pobox.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Date: Tue, 12 Nov 2013 00:33:49 +0100 (CET)
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: <20131111233350.025031AA79@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 11 Nov 2013 23:34:09 -0000

Michael D'Errico wrote:
>
> In trying to figure out what's stalling the encrypt-then-mac draft
> I came across this old message (below).  The complaint against the
> draft appears to be that since the MAC is no longer encrypted, there
> may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
> as the problem, so I checked to see which cipher suites use it.

Personally, I would really prefer to _not_ move the MAC outside
of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
originally recommended.  In particular, keeping the hands off the
GenericStreamCipher PDU processing.

And in order to minimize the code changes and maximize the benefits,
I would use the same _fixed_ GenericBlockCipher PDU for all protocol
versions SSLv3->TLSv1.2 (i.e. including the random IV from TLSv1.1)
and with similar protection from downgrade attacks (for browsers doing
fallback reconnects) as rfc5746 renegotiation by defining another SCSV.


-Martin

From mrex@sap.com  Mon Nov 11 16:55:56 2013
Return-Path: <mrex@sap.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 A09DD21E8133 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 16:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.182
X-Spam-Level: 
X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 DYy+yMig5Cnn for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 16:55:50 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AA3E911E812A for <tls@ietf.org>; Mon, 11 Nov 2013 16:55:49 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAC0tkIo019764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Nov 2013 01:55:47 +0100 (MET)
In-Reply-To: <CA+BZK2onJUrHPegXwO4TWVaj-tirBnpXxEY32T_VA4SZDcnhJA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tue, 12 Nov 2013 01:55:46 +0100 (CET)
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: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 12 Nov 2013 00:55:57 -0000

Ralf Skyper Kaiser wrote:
> 
> On Fri, Nov 8, 2013 at 5:02 AM, Martin Rex <mrex@sap.com> wrote:
> >
> > Don't fix it if it ain't broken.
> > SNI was specifically DESIGNED to convey the server name in the clear.
> 
> SNI was NOT DESIGNED to be convey the server name in clear. SNI was
> designed so that the server can pick the right certificate.

SNI was DESIGNED to be in the clear.  In our server implementation,
I have implemented the server-side of SNI only at the application
level, not in the TLS protocol stack, i.e. I select the credential
that is used to perform the TLS handshake _before_ I start the
handshake.


> 
> SNI can be transmitted encrypted and should be transmitted encrypted (see
> recent plenary sessions at IETF88).

What you seem to want to do is not SNI, but something else.


> 
> Martin, with your argument why should we fix anything at all in any product
> or design?

Don't fix it if it ain't broken.  SNI is not broken.


> 
> The proposed solution FIXES passive pervasive surveillance in TLS 1.3.

This is going to be a waste of energy that is only making things
more complex, but neither better nor more secure.


> 
> Let's make pervasive passive surveillance harder.

To me, this is self-illusion.  Why should NSA look at SNI at all?
They're collecting meta-data based on information that is always present
and necessary for the communication to succeed at all.  There are still
lots of clients around which do not send SNI.  And you could send crap
in SNI to servers that don't implement or use SNI, but I strongly doubt
that you would confuse XKeyScore by doing this.


-Martin

From seonghan.shin@aist.go.jp  Mon Nov 11 18:14:32 2013
Return-Path: <seonghan.shin@aist.go.jp>
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 B3D1421E8106 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 18:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.409
X-Spam-Level: 
X-Spam-Status: No, score=-5.409 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751]
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 p6Icae4lXaCn for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 18:14:28 -0800 (PST)
Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id BABBF21E8105 for <tls@ietf.org>; Mon, 11 Nov 2013 18:14:27 -0800 (PST)
Received: from mail-lb0-f181.google.com ([209.85.217.181]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUoGPA/OVJS23JXq11GEa7JivEJTkUxYz@postini.com; Mon, 11 Nov 2013 18:14:27 PST
Received: by mail-lb0-f181.google.com with SMTP id x18so4022273lbi.40 for <tls@ietf.org>; Mon, 11 Nov 2013 18:14:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4O3Nq/LvGiTjYiaLVsManmIdzOZGMsISp2wlSekiSVw=; b=iBUcGYbIRxDtMRoXMshEBMXi9EkrFM0vK/1MgJ7+/rHl+yX/Y6K5skgxyLpymKrhJ4 7zJgYC3AOiXGFtTVknpBB2KB6EW6EPKTSqv816pM37TBhjZ8RBO6EBwCvVN40auW2Ugd 2DYTiGgcxqxfM0IMrQuasH0s9paRW4NUp0VDQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4O3Nq/LvGiTjYiaLVsManmIdzOZGMsISp2wlSekiSVw=; b=QG8l0/POM92xSBrONIBQNu4eyU5vJ68VVarjZ5REYNj25F9xgbKSmtWYlpTvVv5toP pBId8C9k22aA53T90gFOA7SRP5BT/1pSifCD3U1CHFzT5X6bVd4qjIL6FCbBjRyVKU7j sfKNLbUMbFR5+ejS7fpskYQ/V7/Dv7jFyiRQMvq3Jv4BpV+eo0PUuwiEERsD+dE/Nn4r LMmCq9BYaqywTPA8vMAkwt9aLuMyA1H4i7fdjK00L1YTbhUNinfBw3uHQdioogqo4fOi F1zc9mTpj9aiVyNw/CHuTUe0jXfY/VNCbR3z/sHtUlKes78/UsmaiZ8zqPk2dPngYTER z56w==
X-Gm-Message-State: ALoCoQkufZ7sqaXnb09vtDEiNqrIngTVX4l9PudKxMVsqM+SXbXf+O9X37uo9qimh3bxHf867IeIwQxQE0lC2J71K1mZOX+s2rgkXV+StVbU+04TgJHHUawDIxpEr1EjhLL3EQx83/L6+Vhv09RwsMmXN+lzkEFFmA==
X-Received: by 10.112.29.147 with SMTP id k19mr24658351lbh.9.1384222465730; Mon, 11 Nov 2013 18:14:25 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.29.147 with SMTP id k19mr24658333lbh.9.1384222465261; Mon, 11 Nov 2013 18:14:25 -0800 (PST)
Received: by 10.112.141.138 with HTTP; Mon, 11 Nov 2013 18:14:25 -0800 (PST)
In-Reply-To: <E4AD1150-692C-435F-924D-AF75DECE535D@kth.se>
References: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CEA27C78.1375B%uri@ll.mit.edu> <CAEKgtqk6D+q6-4Jb0afu2O9qRq=mE5_T_5UNrst2_BLmqVTFJw@mail.gmail.com> <E4AD1150-692C-435F-924D-AF75DECE535D@kth.se>
Date: Tue, 12 Nov 2013 11:14:25 +0900
Message-ID: <CAEKgtqn0bsx0pNpdMY-Zh5otT_u8y7Ofeijfu-Qo+BMdW055+w@mail.gmail.com>
From: SeongHan Shin <seonghan.shin@aist.go.jp>
To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= <lha@kth.se>,  "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a1133aa8655083504eaf1680d
Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= <k-kobara@aist.go.jp>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Tue, 12 Nov 2013 02:14:32 -0000

--001a1133aa8655083504eaf1680d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Love,

Thank you for your comments!

>AugPAKE is not defined for ECC, the draft just say that is possible to
implement but not how. For example, is it safe for all kind of curves ?
The ECC part will be added to the next version of our I-D.

>AugPAKE have not test vectors in the draft. (very important because of the
next point).
>AugPAKE have no reference implementation that I=92ve found.
We already implemented AugPAKE and the test vectors also will be added to
the next version of our I-D.
If you want to test interoperability, just let me know. :)

>I have not seen a review of AugPAKE by IRTF CFRG.
We already submitted the I-D to the CFRG. We hope to see reviews from the
CFRG soon.
http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00
For security proof. please refer to the below IACR eprint archive.
https://eprint.iacr.org/2010/334.pdf

>AugPAKE is currently encumbered by IPR issues for all protocols.
What does it mean?
The patent of AugPAKE was granted in Feb. and April of 2013 from Japan and
U.S. respectively.
As in IPR Disclosures, AugPAKE can be used royal-free for any conforming
implementations.
https://datatracker.ietf.org/ipr/2037/

Best regards,
Shin


On Mon, Nov 11, 2013 at 7:52 PM, Love H=F6rnquist =C5strand <lha@kth.se> wr=
ote:

> [resend now that i=92m subscribed to the mailinglist]
>
> AugPAKE is not defined for ECC, the draft just say that is possible to
> implement but not how. For example, is it safe for all kind of curves ?
>
> AugPAKE have not test vectors in the draft. (very important because of th=
e
> next point).
>
> AugPAKE have no reference implementation that I=92ve found.
>
> I have not seen a review of AugPAKE by IRTF CFRG.
>
> AugPAKE is currently encumbered by IPR issues for all protocols.
>
> Love
>
>
> 8 nov 2013 kl. 18:03 skrev SeongHan Shin <seonghan.shin@aist.go.jp>:
>
> FYI,
> AugPAKE is provably secure and can be used royal-free.
> AugPAKE
> https://tools.ietf.org/html/draft-shin-tls-augpake-01
> IPR Disclosures
> https://datatracker.ietf.org/ipr/2037/
>
> Regards,
> Shin
>
>
>
> On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <
> uri@ll.mit.edu> wrote:
>
>> On 11/8/13 1:50 , "Douglas Stebila" <stebila@qut.edu.au> wrote:
>>
>> >I believe that where possible the IETF should aim to standardize
>> >cryptographic protocols that have provable security results.  Such proo=
fs
>> >of course don't guarantee the protocol is secure in all scenarios, but =
at
>> >least rule out some classes of attacks.  In the field of password
>> >authenticated key exchange, there are many provably secure protocols, a=
nd
>> >so it would be preferable to see one such protocol adopted.
>>
>> I concur - except I believe that whenever possible the IETF should aim t=
o
>> standardize cryptographic protocols that are unencumbered by license fee=
s
>> and patents. If the choice arises between a protocol that carries both
>> (provable security and Intellectual Property) and a protocol that has
>> neither - I'd strongly prefer the latter.
>>
>>
>>
>> >On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)
>> ><jsalowey@cisco.com> wrote:
>> >
>> >> This is the beginning of the working group last call for
>> >>draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>> >>TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
>> >>results.  The document needs particular attention paid to the
>> >>integration of this mechanism into the TLS protocol.   Please send
>> >>comments to the TLS list by December 2, 2013.
>> >>
>> >> - Joe
>> >> (For the TLS chairs)
>> >> _______________________________________________
>> >> TLS mailing list
>> >> TLS@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/tls
>> >
>> >_______________________________________________
>> >TLS mailing list
>> >TLS@ietf.org
>> >https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
> --
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------
>  _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


--=20
------------------------------------------------------------------
SeongHan Shin
Research Institute for Secure Systems (RISEC),
National Institute of Advanced Industrial Science and Technology (AIST),
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------

--001a1133aa8655083504eaf1680d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Love,<br><br></div>Thank you for your comments!<br=
><br>&gt;AugPAKE is not defined for ECC, the draft just say that is possibl=
e to=20
implement but not how. For example, is it safe for all kind of curves ?<br>=
<div><div><div class=3D"gmail_extra">The ECC part will be added to the next=
 version of our I-D.<br><br><div>&gt;AugPAKE have not test vectors in the d=
raft. (very important because of the next point).</div>
<div>&gt;AugPAKE have no reference implementation that I=92ve found.</div>W=
e already implemented AugPAKE and the test vectors also will be added to th=
e next version of our I-D.<br></div><div class=3D"gmail_extra">If you want =
to test interoperability, just let me know. :)<br>
<br>&gt;I have not seen a review of AugPAKE by IRTF CFRG.<br></div><div cla=
ss=3D"gmail_extra">We already submitted the I-D to the CFRG. We hope to see=
 reviews from the CFRG soon.<br><a href=3D"http://tools.ietf.org/html/draft=
-irtf-cfrg-augpake-00">http://tools.ietf.org/html/draft-irtf-cfrg-augpake-0=
0</a><br>
</div><div class=3D"gmail_extra">For security proof. please refer to the be=
low IACR eprint archive.<br></div><div class=3D"gmail_extra"><a href=3D"htt=
ps://eprint.iacr.org/2010/334.pdf">https://eprint.iacr.org/2010/334.pdf</a>=
<br>
<br>&gt;AugPAKE is currently encumbered by IPR issues for all protocols.<br=
></div><div class=3D"gmail_extra">What does it mean?<br></div><div class=3D=
"gmail_extra">The patent of AugPAKE was granted in Feb. and April of 2013 f=
rom Japan and U.S. respectively.<br>
</div><div class=3D"gmail_extra">As in IPR Disclosures, AugPAKE can be used=
 royal-free for any conforming implementations.</div><div class=3D"gmail_ex=
tra"><a href=3D"https://datatracker.ietf.org/ipr/2037/" target=3D"_blank">h=
ttps://datatracker.ietf.org/ipr/2037/</a><br>
<br></div><div class=3D"gmail_extra">Best regards,<br>Shin<br></div><div cl=
ass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Nov 11, 2013=
 at 7:52 PM, Love H=F6rnquist =C5strand <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:lha@kth.se" target=3D"_blank">lha@kth.se</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"word-wrap:b=
reak-word"><div>[resend now that i=92m subscribed to the mailinglist]</div>=
<div class=3D"im">
<div><br></div><div>AugPAKE is not defined for ECC, the draft just say that=
 is possible to implement but not how. For example, is it safe for all kind=
 of curves ?</div><div><br></div><div>AugPAKE have not test vectors in the =
draft. (very important because of the next point).</div>
<div><br></div></div><div>AugPAKE have no reference implementation that I=
=92ve found.</div><div class=3D"im"><div><br></div><div>I have not seen a r=
eview of AugPAKE by IRTF CFRG.</div><div><br></div><div>AugPAKE is currentl=
y encumbered by IPR issues for all protocols.</div>
<div><br></div><div>Love</div><div><br></div><div><br></div></div><div><div=
 class=3D"im"><div>8 nov 2013 kl. 18:03 skrev SeongHan Shin &lt;<a href=3D"=
mailto:seonghan.shin@aist.go.jp" target=3D"_blank">seonghan.shin@aist.go.jp=
</a>&gt;:</div>
<br></div><div><div class=3D"h5"><blockquote type=3D"cite"><div dir=3D"ltr"=
><div><div>FYI,<br></div>AugPAKE is provably secure and can be used royal-f=
ree.<br>AugPAKE<br><a href=3D"https://tools.ietf.org/html/draft-shin-tls-au=
gpake-01" target=3D"_blank">https://tools.ietf.org/html/draft-shin-tls-augp=
ake-01</a><br>

</div>IPR Disclosures<br><div><a href=3D"https://datatracker.ietf.org/ipr/2=
037/" target=3D"_blank">https://datatracker.ietf.org/ipr/2037/</a><br><br><=
/div><div>Regards,<br></div><div>Shin<br><br></div></div><div class=3D"gmai=
l_extra">
<br><br><div class=3D"gmail_quote">
On Sat, Nov 9, 2013 at 1:35 AM, Blumenthal, Uri - 0558 - MITLL <span dir=3D=
"ltr">&lt;<a href=3D"mailto:uri@ll.mit.edu" target=3D"_blank">uri@ll.mit.ed=
u</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">

<div>On 11/8/13 1:50 , &quot;Douglas Stebila&quot; &lt;<a href=3D"mailto:st=
ebila@qut.edu.au" target=3D"_blank">stebila@qut.edu.au</a>&gt; wrote:<br>
<br>
&gt;I believe that where possible the IETF should aim to standardize<br>
&gt;cryptographic protocols that have provable security results. =A0Such pr=
oofs<br>
&gt;of course don&#39;t guarantee the protocol is secure in all scenarios, =
but at<br>
&gt;least rule out some classes of attacks. =A0In the field of password<br>
&gt;authenticated key exchange, there are many provably secure protocols, a=
nd<br>
&gt;so it would be preferable to see one such protocol adopted.<br>
<br>
</div>I concur - except I believe that whenever possible the IETF should ai=
m to<br>
standardize cryptographic protocols that are unencumbered by license fees<b=
r>
and patents. If the choice arises between a protocol that carries both<br>
(provable security and Intellectual Property) and a protocol that has<br>
neither - I&#39;d strongly prefer the latter.<br>
<div><div><br>
<br>
<br>
&gt;On Nov 8, 2013, at 2:11 AM, Joseph Salowey (jsalowey)<br>
&gt;&lt;<a href=3D"mailto:jsalowey@cisco.com" target=3D"_blank">jsalowey@ci=
sco.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; This is the beginning of the working group last call for<br>
&gt;&gt;draft-ietf-tls-pwd-01. =A0 The underlying cryptographic protocol fo=
r<br>
&gt;&gt;TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory<=
br>
&gt;&gt;results. =A0The document needs particular attention paid to the<br>
&gt;&gt;integration of this mechanism into the TLS protocol. =A0 Please sen=
d<br>
&gt;&gt;comments to the TLS list by December 2, 2013.<br>
&gt;&gt;<br>
&gt;&gt; - Joe<br>
&gt;&gt; (For the TLS chairs)<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; TLS mailing list<br>
&gt;&gt; <a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a>=
<br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;TLS mailing list<br>
&gt;<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div><br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margi=
n:0mm 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:=
10pt" lang=3D"EN-US">------------------------------------------------------=
------------<br>

SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>

Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : <a href=3D"tel:%2B81-29-861-5285" value=3D"+812=
98615285" target=3D"_blank">+81-29-861-5285</a><br>E-mail : <a href=3D"mail=
to:seonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seon=
ghan.shin@aist.go.jp</font></a><br>

------------------------------------------------------------------</span></=
div>
</div>
_______________________________________________<br>TLS mailing list<br><a h=
ref=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br><a href=
=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">https://ww=
w.ietf.org/mailman/listinfo/tls</a><br>
</blockquote></div></div></div><br></div><br>______________________________=
_________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div style=3D"margi=
n:0mm 0mm 0pt"><span style=3D"font-family:&#39;MS UI Gothic&#39;;font-size:=
10pt" lang=3D"EN-US">------------------------------------------------------=
------------<br>
SeongHan Shin<br></span><span style=3D"font-family:&#39;MS UI Gothic&#39;;f=
ont-size:10pt" lang=3D"EN-US">Research Institute for Secure Systems (RISEC)=
,<br>National Institute of Advanced Industrial Science and Technology (AIST=
),<br>
Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan<br>Tel : +8=
1-29-861-2670/5284<br>Fax : +81-29-861-5285<br>E-mail : <a href=3D"mailto:s=
eonghan.shin@aist.go.jp" target=3D"_blank"><font color=3D"#0000ff">seonghan=
.shin@aist.go.jp</font></a><br>
------------------------------------------------------------------</span></=
div>
</div></div></div></div>

--001a1133aa8655083504eaf1680d--

From dev+ietf@seantek.com  Mon Nov 11 18:35:24 2013
Return-Path: <dev+ietf@seantek.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 F20E211E80D9 for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 18:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 6Qbl-rQWjBTX for <tls@ietfa.amsl.com>; Mon, 11 Nov 2013 18:35:18 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D06C811E8191 for <tls@ietf.org>; Mon, 11 Nov 2013 18:35:17 -0800 (PST)
Received: from [192.168.123.7] (unknown [76.173.239.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 740F650A84 for <tls@ietf.org>; Mon, 11 Nov 2013 21:35:08 -0500 (EST)
Message-ID: <528193BC.9060804@seantek.com>
Date: Mon, 11 Nov 2013 18:34:36 -0800
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: tls@ietf.org
References: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp>
In-Reply-To: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060600090701020701050009"
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 02:35:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms060600090701020701050009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 11/11/2013 4:55 PM, Martin Rex wrote:
> Ralf Skyper Kaiser wrote:
>
>> SNI can be transmitted encrypted and should be transmitted encrypted (=
see
>> recent plenary sessions at IETF88).
> What you seem to want to do is not SNI, but something else.
>
>
>> Martin, with your argument why should we fix anything at all in any pr=
oduct
>> or design?
> Don't fix it if it ain't broken.  SNI is not broken.
>
>
>> The proposed solution FIXES passive pervasive surveillance in TLS 1.3.=

> [...]
>> Let's make pervasive passive surveillance harder.
> To me, this is self-illusion.  Why should NSA look at SNI at all?

Okay so here's the thing. A passive observer of the network can probably =

figure out that a particular TLS connection is intended for a particular =

hostname.

The client and server IP addresses are in the clear. No question.

To figure out the server's IP address from its hostname, the client must =

do a DNS lookup. This will be in the clear. Even if a particular client=20
doesn't go over the (surveiled) public Internet to do the DNS lookup=20
(due to local DNS server caching), for any nontrivial amount of=20
connections, the DNS record will float through the public Internet in=20
the clear at some point.

Thus an eavesdropper can easily correlate the reverse lookup, IP address =

-> hostname(s), in a minimal amount of time.

So, the fact that SNI is in the clear, is not really leaking additional=20
information that a passive (but consistent and pervasive) eavesdropper=20
would have figured out in the first place.

Unless of course you are using SNI to stuff in side-channel information=20
(i.e., something other than a hostname)...but then you are not obeying=20
the SNI protocol in the first place.

FWIW, I would prefer that all metadata (whether SNI or otherwise) not be =

in the clear. But as Martin Rex said, it being in the clear is not fatal =

to security.

-Sean



--------------ms060600090701020701050009
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSzCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIFKTCCBBGgAwIBAgIQZ6sVlrTEYjwLaBPoxUwEaTANBgkqhkiG9w0B
AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP
TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjEx
MjkwMDAwMDBaFw0xMzExMjkyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNl
YW50ZWsuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz
5zgTny0JRBE1mJZszV2s6EurahKPvku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/
+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cUvZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9r
BB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/MwNAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyV
ZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/syYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfc
k36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQABo4IB5DCCAeAwHwYDVR0jBBgwFoAU
ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBpm5d7y8PBT6NqnIVbfNK8hbpPGMA4G
A1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEE
AbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEw
KzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAw
TjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAC
hkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wHwYDVR0RBBgwFoEUZGV2K2lldGZAc2VhbnRlay5jb20wDQYJKoZIhvcNAQEFBQADggEB
AAY3GfgX0pLsz6qEOOG191EgYXSCpKW70wSFgSe+7AenZT88d/m8w0YtfOFVD7+94dNULDnH
4P6sD70hday7/ke4uYfgURxygemKN26KV3T7wBw8WbZSTmYJphzSoqUK5ISsQNwLaKf4yTmp
Ae9IR1AjZXP3oAZvsRvpZDtiaULQ+HfFTypLDsnrA7sTtoVtirJdImGBTHsVtZ+GEQlhuuJ6
G1cInzNxIbxgnLdn4pFF82FP60SsZxaW2VRqDK7CbHJX4LUH+oJ6kp9qxF5I/RIAhRHd3lMe
Xmq6vZPbnMUNhJyUC6TbYipe11+VDFPGiHZE/+y6RMSuRnepJzE4PLAxggQZMIIEFQIBATCB
qDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9E
TyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQZ6sVlrTEYjwL
aBPoxUwEaTAJBgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xMzExMTIwMjM0MzZaMCMGCSqGSIb3DQEJBDEWBBQ0ygW0vGJoTWC1t/Q2
7w8TIYuy9TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYI
KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG
SIb3DQMCAgEoMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQI
ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFu
ZCBTZWN1cmUgRW1haWwgQ0ECEGerFZa0xGI8C2gT6MVMBGkwgbsGCyqGSIb3DQEJEAILMYGr
oIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N
T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBnqxWWtMRi
PAtoE+jFTARpMA0GCSqGSIb3DQEBAQUABIIBACubOzrl8Sqmzm2Nke5Fn8dn1nryICitPljq
o4ccLIIZkOqY/IzjVVsACuTChsLTAlGEmNBppcv1DqFluakWDUhJLqK6rmp83GDgfV61gPsI
3JPvhrB586IcS+EcRcf5eoAn+dYn04K6QNJw8pBSOKfqrtXJJ1DE74xpn12+aeJDdy6EAGx5
VpxAwNh7es/Rhoxl+HAmfNnT8oTxwPpGxra6+kmZXy1Sbgred0BXBAIy6xm2/zGFeODqggoH
P5HFGMmPhDDkYF/NkQVG4qxzQzr7P2R238eSgxorhXy7Kmf4NSpbspoSg/JRlga7GNY2/R2l
Q8WZp+bgoMpAlj/IVOUAAAAAAAA=
--------------ms060600090701020701050009--

From n.mavrogiannopoulos@gmail.com  Tue Nov 12 01:14:19 2013
Return-Path: <n.mavrogiannopoulos@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 B94E021E80CE for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 01:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ELxsU-QVDcDo for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 01:14:19 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id ED19421E80AC for <tls@ietf.org>; Tue, 12 Nov 2013 01:13:54 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id eo20so5002501lab.9 for <tls@ietf.org>; Tue, 12 Nov 2013 01:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gmNGA8AN6ZqgZ7l4SdtBiHdnqu8yF7DScmj+igV9nX4=; b=HYgarOPcMltTw6QeZsiXLKWmX/q3APPq4IVFteigYt+fx2/xhUHGRY/jGYZe2U56TW ehprYdBMxQVvhe7eG5qj3w8qgH7szq4JxE5HnQVly4Qb96/1zumw5TNnSWrAGjvBm2Q0 bXg+CsoTSSjSnUbscC49TTjmlj4HhXlBUXvT3dTWNLLajh3rqIpSCAszlkl8LSppAoxs CPqfF2DCx28oYHH86gwrjtO196cuBcAjInsJMxaIj7b+JlZ90mN08J8WFDplHU0NE0yv rvqYLvP0RrhT/R/SlurNoAOjLRCKvL/CAyJjsfGXzBoKRz3ndQ8f1U/bgcO1YmVkpnO1 EQbg==
MIME-Version: 1.0
X-Received: by 10.112.205.164 with SMTP id lh4mr25414581lbc.15.1384247631544;  Tue, 12 Nov 2013 01:13:51 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Tue, 12 Nov 2013 01:13:51 -0800 (PST)
In-Reply-To: <20131111233350.025031AA79@ld9781.wdf.sap.corp>
References: <527FEC83.9020107@pobox.com> <20131111233350.025031AA79@ld9781.wdf.sap.corp>
Date: Tue, 12 Nov 2013 10:13:51 +0100
X-Google-Sender-Auth: 6D1NMFxDe01zRguDjDhDh5zr3Aw
Message-ID: <CAJU7zaLsJe-B3gOF9BrROKPeLSvbNdM9RzJgYxRAZtBWofc8ew@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Tue, 12 Nov 2013 09:14:19 -0000

On Tue, Nov 12, 2013 at 12:33 AM, Martin Rex <mrex@sap.com> wrote:
> Personally, I would really prefer to _not_ move the MAC outside
> of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
> originally recommended.  In particular, keeping the hands off the
> GenericStreamCipher PDU processing.

I prefer this approach too, so I've taken the parts from the
length-hiding draft and moved them to a draft that simply describes a
new padding approach to solve the padding oracles. In any case I still
believe that something needs to be done about that, whether it is
pad-encrypt-then-mac or pad-mac-then-encrypt.

http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00

regards,
Nikos

From skyper@thc.org  Tue Nov 12 01:54:01 2013
Return-Path: <skyper@thc.org>
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 320AD11E8208 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 01:54:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.452
X-Spam-Level: 
X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 wIJVS+TFfyo8 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 01:53:57 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CF9FA11E8209 for <tls@ietf.org>; Tue, 12 Nov 2013 01:53:41 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so3569980ieb.31 for <tls@ietf.org>; Tue, 12 Nov 2013 01:53:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H/4SoDNKxjBIBkCb6zd8BVgs+axuSpYffBL15ymOmIY=; b=HX0pqf4ksx39aV+GdZav7QJ+D35+C30NX5aDdjm/UA/xGIuSz2/ZgOS4iiADS1eBZE yUSXiXSRRqG/KAiOogPLR8rLJIwWz23lW5QAyKRoFi9cw7QUlDXUxi4lyVi9OMdY2PQf MpLgeE5Crn371ERgyxg6//E7F2V9NnGJ4tHC8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=H/4SoDNKxjBIBkCb6zd8BVgs+axuSpYffBL15ymOmIY=; b=QrY6UFf705/ftEnWgHrrAACQD7EbpjAeEuJes8TmVuEdrksPQYH1f0EkgcOLRcIeHQ 3eQtxzrWkyZEIGjq6f9N7s+ri+t7abw8X4qzhGaJVue7bxAUP2zhkSWPmFTCYXZ3oXuQ qCNIG8PTvIuYz5NXgrzEQGL/D7AnqmM+Je0BZBxbVfGAj9OE939RKg0Nqm/EIhOrtr9/ BjDfIoyB279r5+yhORpeoH5FWv8pMm0Khn3rI8xTPX5HmzTk2AayuITuRrSHdgfb5GmY TZfjvQmzzXpmstljphGU9kg554cFVHQY2vPS/I0Fx0ympMxBx3ej48I3ZCrpypSQgfgy 29Zw==
X-Gm-Message-State: ALoCoQkQPWKFb+vmE1bLSWS6Eb8/YAOgIRMZh9mu1QYTY2v9hdVLY3tmOT6AS0ubkLIemgGa3NYA
MIME-Version: 1.0
X-Received: by 10.50.30.229 with SMTP id v5mr15159720igh.27.1384250020819; Tue, 12 Nov 2013 01:53:40 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Tue, 12 Nov 2013 01:53:40 -0800 (PST)
X-Originating-IP: [217.39.7.72]
In-Reply-To: <20131111233350.025031AA79@ld9781.wdf.sap.corp>
References: <527FEC83.9020107@pobox.com> <20131111233350.025031AA79@ld9781.wdf.sap.corp>
Date: Tue, 12 Nov 2013 09:53:40 +0000
Message-ID: <CA+BZK2pu1F3zpRJNFX=QjFh=4JkooTgxkjDFPKBosnVCvuSonA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=047d7bacc30cc5910504eaf7d215
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Tue, 12 Nov 2013 09:54:01 -0000

--047d7bacc30cc5910504eaf7d215
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Is this preference based on security concerns or personal preference and
ease of implementation/adaption?

(Reading the Serge Vaudenary thread  suggest the latter - which is fine by
me - its worth considering the trade off.)

Encrypt-then-mac has some other security benefits. (Among others that the
decrypt routine never has
to process bogus/bad messages [e.g. those where the MAC would fail in
current encrypt-mac].).

regards,

ralf



On Mon, Nov 11, 2013 at 11:33 PM, Martin Rex <mrex@sap.com> wrote:

> Michael D'Errico wrote:
> >
> > In trying to figure out what's stalling the encrypt-then-mac draft
> > I came across this old message (below).  The complaint against the
> > draft appears to be that since the MAC is no longer encrypted, there
> > may be a way to recover the secret HMAC key.  HMAC-MD5 is mentioned
> > as the problem, so I checked to see which cipher suites use it.
>
> Personally, I would really prefer to _not_ move the MAC outside
> of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
> originally recommended.  In particular, keeping the hands off the
> GenericStreamCipher PDU processing.
>
> And in order to minimize the code changes and maximize the benefits,
> I would use the same _fixed_ GenericBlockCipher PDU for all protocol
> versions SSLv3->TLSv1.2 (i.e. including the random IV from TLSv1.1)
> and with similar protection from downgrade attacks (for browsers doing
> fallback reconnects) as rfc5746 renegotiation by defining another SCSV.
>
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7bacc30cc5910504eaf7d215
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi,<br><br>Is this preference based on security =
concerns or personal preference and ease of implementation/adaption?<br><br=
>(Reading the Serge Vaudenary thread=A0 suggest the latter - which is fine =
by me - its worth considering the trade off.)<br>
<br></div>Encrypt-then-mac has some other security benefits. (Among others =
that the decrypt routine never has<br>to process bogus/bad messages [e.g. t=
hose where the MAC would fail in current encrypt-mac].).<br><br>regards,<br=
>
<br></div>ralf<br><br></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Mon, Nov 11, 2013 at 11:33 PM, Martin Rex <span dir=3D"=
ltr">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">Michael D&#39;Errico wrote=
:<br>
&gt;<br>
&gt; In trying to figure out what&#39;s stalling the encrypt-then-mac draft=
<br>
&gt; I came across this old message (below). =A0The complaint against the<b=
r>
&gt; draft appears to be that since the MAC is no longer encrypted, there<b=
r>
&gt; may be a way to recover the secret HMAC key. =A0HMAC-MD5 is mentioned<=
br>
&gt; as the problem, so I checked to see which cipher suites use it.<br>
<br>
</div>Personally, I would really prefer to _not_ move the MAC outside<br>
of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay<br>
originally recommended. =A0In particular, keeping the hands off the<br>
GenericStreamCipher PDU processing.<br>
<br>
And in order to minimize the code changes and maximize the benefits,<br>
I would use the same _fixed_ GenericBlockCipher PDU for all protocol<br>
versions SSLv3-&gt;TLSv1.2 (i.e. including the random IV from TLSv1.1)<br>
and with similar protection from downgrade attacks (for browsers doing<br>
fallback reconnects) as rfc5746 renegotiation by defining another SCSV.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-Martin<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div>

--047d7bacc30cc5910504eaf7d215--

From n.mavrogiannopoulos@gmail.com  Tue Nov 12 01:54:56 2013
Return-Path: <n.mavrogiannopoulos@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 93F6E11E821C for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 01:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 3Hycrlh-PABL for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 01:54:56 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3BE11E8208 for <tls@ietf.org>; Tue, 12 Nov 2013 01:54:51 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id z5so866062lbh.29 for <tls@ietf.org>; Tue, 12 Nov 2013 01:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ioQHU8aO4mvEWs0aGnkNcfE7LpIQVRVlODHrk4/vvFk=; b=cUKLAthkHtYn2//CFxpJoY+Bx/41yFd0tqPVArrBg06vAlHib63Iy++6LZE+rlR4Ig K79eE4z6vG06BfLNo7WJ5oSetVV5ruFxrvx3piP617SuMYNIGEmjPGALj2xS6tTwGu/5 /Gnx/fIYjzEjuqMq+fVm/TEIFBoWATbXawJNzHQe47X3q/YY5tpDyO0SR5neKz86hs+Y WtZb+oNxPrSl3PWC5AC6u7Z5dJ7CkjzCBmOr7aa6FFpTjOq41nNkxPSrXd/h8RLmSDp+ TqdHzamrpK7mdMkVrfxP8WY+axXqyUozCM6BrH06lYPYJ8GI92KiZWQEUIEUJhpmKmzr deLA==
MIME-Version: 1.0
X-Received: by 10.152.170.133 with SMTP id am5mr27054994lac.9.1384250087454; Tue, 12 Nov 2013 01:54:47 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Tue, 12 Nov 2013 01:54:47 -0800 (PST)
Date: Tue, 12 Nov 2013 10:54:47 +0100
X-Google-Sender-Auth: uukDtpI99UBzzKUe1xMi_3m_5lk
Message-ID: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 09:54:56 -0000

Hello,
 Having seen the current discussion for TLS 1.3, I have some proposal.
Since the changes requested are large, I'd suggest not to design TLS 1.3
in this working group. I'd suggest this working group to set the specs
for the next TLS version (and better name it 2.0), and then announce a
competition for the initial draft of the protocol. Then have the WG
review the submitted proposals in a year or two, accept a winner, and
the WG starts working on the winning draft.

I'm pretty sure there are many research groups that will be honoured
to join such a competition and their results may outperform the
results of the limited number of participants in the working group.

best regards,
Nikos

From skyper@thc.org  Tue Nov 12 02:06:43 2013
Return-Path: <skyper@thc.org>
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 9C3F721E80BA for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:06:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.452
X-Spam-Level: 
X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 JkFiRUF2OI2N for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:06:28 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BC53821E80B0 for <tls@ietf.org>; Tue, 12 Nov 2013 02:06:27 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id tp5so3136720ieb.28 for <tls@ietf.org>; Tue, 12 Nov 2013 02:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vISWZKic3wjoD0mv7C1sqWAufbhEowuGAzPDA2sQ3Rk=; b=B/Uk2bsf0VHflmejkib0sOerDm3nUAJT4fcDY2OdEAEHuOx4ty2I5im8hurC8H/Fbd TfovHyCo0ONMTp/eJgi5R7/5V6v5YlEpX1EHDroCumDVbnwgoNWLlDFAR5s/YtRjMRKt 2ENipU4kzPi7+3VQEMzhQhQvPvkWmLca0k7Ck=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vISWZKic3wjoD0mv7C1sqWAufbhEowuGAzPDA2sQ3Rk=; b=Pn0YNRKJzabMnuvPLQSVHFhD6M3SDWRr6W+PUS9gMA2ceQjySY3ybPwgIekBLqAzQu D9O77qf0vn4QqxfPym0J/lVvoKZhBKKI/nRkvN6UHsqhe18JYa5Qbk/IoszVol10tuA3 cGvatCf7JdAJXVmWJhmjSyyphrbFunDF/RvJJNA8lmh1uCCgdvF97QdffTB5Zr4ylcDK kl2QT9DqPonzKnIAtEkT5i0np0XY3x5m4280C3sxRNqw9lc2zKaYPQKk6orokBHN15Ss /ftPviy9foJ26VaLIPSiRh5bzZgY0120tJ/ut7sPNzo8KB+4BY9An2WuRQOwz5LI8Q1P 9fag==
X-Gm-Message-State: ALoCoQknXD0QVxmj6zavDPJ/hloCJIUGZ1APZ0PAhaEKJSZms1xZe5InNk3KN3ibbGho1AVN5J5z
MIME-Version: 1.0
X-Received: by 10.50.128.137 with SMTP id no9mr15222000igb.36.1384250787212; Tue, 12 Nov 2013 02:06:27 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Tue, 12 Nov 2013 02:06:27 -0800 (PST)
X-Originating-IP: [217.39.7.72]
In-Reply-To: <528193BC.9060804@seantek.com>
References: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp> <528193BC.9060804@seantek.com>
Date: Tue, 12 Nov 2013 10:06:27 +0000
Message-ID: <CA+BZK2qiFM-xruwgRDU8Nf8K7=E6sLytnQYF9xp=VWB9jiuxtQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Sean Leonard <dev+ietf@seantek.com>
Content-Type: multipart/alternative; boundary=047d7b10cf0d73c35a04eaf800b5
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 10:06:43 -0000

--047d7b10cf0d73c35a04eaf800b5
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Martin, you are right that SNI is currently implemented and transmitted in
clear.
This was however not the primary design goal but rather a choice of
convenience
and lack of better/easier ideas. The primary design goal for SNI was to
allow
multi-homing HTTPS servers on the same IP (so that apache can select the
correct x509 certificate for whatever site the client requested). There is
no
practical or security benefit  or transmitting SNI in clear.

Sean, your argument "but DNS leaks infos as well, and the attacker can do
reverse
lookups, ..." etc are valid but shall not prevent us from fixing these
problems one by
one. DNS will support confidentiality. Reverse lookups do not work on
multi-homed
SSL servers [you only get 1 host name back but not 1,000 domains hosted on
that
host], .. etc etc).


I hear you loud and clear that a more work on other protocols (including
DNS) has to
done to prevent leaking of domain names. I agree.

Let's start with TLS and SNI.


regards,

ralf




On Tue, Nov 12, 2013 at 2:34 AM, Sean Leonard <dev+ietf@seantek.com> wrote:

> On 11/11/2013 4:55 PM, Martin Rex wrote:
>
>> Ralf Skyper Kaiser wrote:
>>
>>  SNI can be transmitted encrypted and should be transmitted encrypted (see
>>> recent plenary sessions at IETF88).
>>>
>> What you seem to want to do is not SNI, but something else.
>>
>>
>>  Martin, with your argument why should we fix anything at all in any
>>> product
>>> or design?
>>>
>> Don't fix it if it ain't broken.  SNI is not broken.
>>
>>
>>  The proposed solution FIXES passive pervasive surveillance in TLS 1.3.
>>>
>> [...]
>>
>>  Let's make pervasive passive surveillance harder.
>>>
>> To me, this is self-illusion.  Why should NSA look at SNI at all?
>>
>
> Okay so here's the thing. A passive observer of the network can probably
> figure out that a particular TLS connection is intended for a particular
> hostname.
>
> The client and server IP addresses are in the clear. No question.
>
> To figure out the server's IP address from its hostname, the client must
> do a DNS lookup. This will be in the clear. Even if a particular client
> doesn't go over the (surveiled) public Internet to do the DNS lookup (due
> to local DNS server caching), for any nontrivial amount of connections, the
> DNS record will float through the public Internet in the clear at some
> point.
>
> Thus an eavesdropper can easily correlate the reverse lookup, IP address
> -> hostname(s), in a minimal amount of time.
>
> So, the fact that SNI is in the clear, is not really leaking additional
> information that a passive (but consistent and pervasive) eavesdropper
> would have figured out in the first place.
>
> Unless of course you are using SNI to stuff in side-channel information
> (i.e., something other than a hostname)...but then you are not obeying the
> SNI protocol in the first place.
>
> FWIW, I would prefer that all metadata (whether SNI or otherwise) not be
> in the clear. But as Martin Rex said, it being in the clear is not fatal to
> security.
>
> -Sean
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--047d7b10cf0d73c35a04eaf800b5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi,<br><br>Martin, you are right that SNI is cur=
rently implemented and transmitted in clear.<br>This was however not the pr=
imary design goal but rather a choice of convenience<br>and lack of better/=
easier ideas. The primary design goal for SNI was to allow<br>
multi-homing HTTPS servers on the same IP (so that apache can select the<br=
>correct x509 certificate for whatever site the client requested). There is=
 no<br>practical or security benefit=A0 or transmitting SNI in clear. <br>
<br></div>Sean, your argument &quot;but DNS leaks infos as well, and the at=
tacker can do reverse<br>lookups, ...&quot; etc are valid but shall not pre=
vent us from fixing these problems one by<br>one. DNS will support confiden=
tiality. Reverse lookups do not work on multi-homed<br>
SSL servers [you only get 1 host name back but not 1,000 domains hosted on =
that<br>host], .. etc etc).<br><br></div><br><div>I hear you loud and clear=
 that a more work on other protocols (including DNS) has to<br>done to prev=
ent leaking of domain names. I agree.<br>
<br>Let&#39;s start with TLS and SNI. </div><br><div><br></div><div>regards=
,<br><br>ralf<br><br></div><div><br></div></div><div class=3D"gmail_extra">=
<br><br><div class=3D"gmail_quote">On Tue, Nov 12, 2013 at 2:34 AM, Sean Le=
onard <span dir=3D"ltr">&lt;<a href=3D"mailto:dev+ietf@seantek.com" target=
=3D"_blank">dev+ietf@seantek.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 11/11/2013 4:55 PM, Mar=
tin Rex wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
Ralf Skyper Kaiser wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
SNI can be transmitted encrypted and should be transmitted encrypted (see<b=
r>
recent plenary sessions at IETF88).<br>
</blockquote>
What you seem to want to do is not SNI, but something else.<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Martin, with your argument why should we fix anything at all in any product=
<br>
or design?<br>
</blockquote>
Don&#39;t fix it if it ain&#39;t broken. =A0SNI is not broken.<br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The proposed solution FIXES passive pervasive surveillance in TLS 1.3.<br>
</blockquote></div>
[...]<div class=3D"im"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Let&#39;s make pervasive passive surveillance harder.<br>
</blockquote>
To me, this is self-illusion. =A0Why should NSA look at SNI at all?<br>
</div></blockquote>
<br>
Okay so here&#39;s the thing. A passive observer of the network can probabl=
y figure out that a particular TLS connection is intended for a particular =
hostname.<br>
<br>
The client and server IP addresses are in the clear. No question.<br>
<br>
To figure out the server&#39;s IP address from its hostname, the client mus=
t do a DNS lookup. This will be in the clear. Even if a particular client d=
oesn&#39;t go over the (surveiled) public Internet to do the DNS lookup (du=
e to local DNS server caching), for any nontrivial amount of connections, t=
he DNS record will float through the public Internet in the clear at some p=
oint.<br>

<br>
Thus an eavesdropper can easily correlate the reverse lookup, IP address -&=
gt; hostname(s), in a minimal amount of time.<br>
<br>
So, the fact that SNI is in the clear, is not really leaking additional inf=
ormation that a passive (but consistent and pervasive) eavesdropper would h=
ave figured out in the first place.<br>
<br>
Unless of course you are using SNI to stuff in side-channel information (i.=
e., something other than a hostname)...but then you are not obeying the SNI=
 protocol in the first place.<br>
<br>
FWIW, I would prefer that all metadata (whether SNI or otherwise) not be in=
 the clear. But as Martin Rex said, it being in the clear is not fatal to s=
ecurity.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-Sean<br>
<br>
<br>
</font></span><br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br></div>

--047d7b10cf0d73c35a04eaf800b5--

From ynir@checkpoint.com  Tue Nov 12 02:06:53 2013
Return-Path: <ynir@checkpoint.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 69E1F11E80EE for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:06:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 QBvxOj4r8uZj for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:06:43 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5B94421E80AC for <tls@ietf.org>; Tue, 12 Nov 2013 02:06:23 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rACA6G28005320; Tue, 12 Nov 2013 12:06:18 +0200
X-CheckPoint: {5281FBCD-B-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.146]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:05:27 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] a proposal for TLS 1.3
Thread-Index: AQHO341DBtHKp83zBUGnzP2Y02GXX5ohXMpg
Date: Tue, 12 Nov 2013 10:05:27 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
In-Reply-To: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.27]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 10:06:54 -0000

Hi Nikos. This is pretty much what httpbis did for HTTP/2. Only it did not =
take a year or two - only two IETF cycles.=20

So a competition could be announced now, with proposals presented in London=
, and a decision reached before Toronto.

While there are many research groups, they don't do protocol work so much.=
=20

The real tricky thing here is not designing a "new TLS", but co-existence w=
ith SSLv3, TLS 1.0, 1.1, and 1.2 without resorting to the kind of fallback =
mechanism where you try with TLS 1.3 (or 2.0, or even better - 4.0) and if =
you get a reset, try again with TLS 1.2, and if that doesn't work, go strai=
ght to SSLv3.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nikos=
 Mavrogiannopoulos
Sent: Tuesday, November 12, 2013 11:55 AM
To: tls@ietf.org
Subject: [TLS] a proposal for TLS 1.3

Hello,
 Having seen the current discussion for TLS 1.3, I have some proposal.
Since the changes requested are large, I'd suggest not to design TLS 1.3 in=
 this working group. I'd suggest this working group to set the specs for th=
e next TLS version (and better name it 2.0), and then announce a competitio=
n for the initial draft of the protocol. Then have the WG review the submit=
ted proposals in a year or two, accept a winner, and the WG starts working =
on the winning draft.

I'm pretty sure there are many research groups that will be honoured to joi=
n such a competition and their results may outperform the results of the li=
mited number of participants in the working group.

best regards,
Nikos


From juhovh@iki.fi  Tue Nov 12 02:09:30 2013
Return-Path: <juhovh@iki.fi>
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 4418B11E80F1 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level: 
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
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 bl3j+aq5dXJ9 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:09:24 -0800 (PST)
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfa.amsl.com (Postfix) with ESMTP id 77E4D21E80E7 for <tls@ietf.org>; Tue, 12 Nov 2013 02:09:14 -0800 (PST)
Received: from [10.176.133.178] (85-76-119-92-nat.elisa-mobile.fi [85.76.119.92]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 22BC721698D; Tue, 12 Nov 2013 12:09:09 +0200 (EET)
References: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <DFB0ADD5-495D-4FEC-BF84-D209A41639C1@iki.fi>
X-Mailer: iPhone Mail (11B511)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Tue, 12 Nov 2013 12:05:32 +0200
To: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 10:09:30 -0000

> On 12.11.2013, at 2.55, mrex@sap.com (Martin Rex) wrote:
>=20
> To me, this is self-illusion.  Why should NSA look at SNI at all?

At this point I must point out that not everything is about NSA. There are c=
ertain countries that block DNS to the open internet and therefore all DNS q=
ueries are performed inside national borders. Some of these countries have a=
lso managed to block Tor with rather complicated active probing and IP block=
s.

I can confirm that a working solution to easily get to services like google/=
facebook without full VPN is to edit /etc/hosts to point to some unblocked I=
P e.g. in Europe and use HTTPS. What makes me sad is the knowledge that SNI i=
s leaking the hostname and makes those connections trivial to block, even th=
ough I haven't come across SNI based blocking yet.

I haven't put enough thought into this to say if encrypting SNI is technical=
ly feasible or adds too much complication. But I would like to hear how come=
 in the situation I have just described (and have personally experienced) le=
aking SNI is not a problem? AFAIK these countries only do passive surveillan=
ce, because active surveillance would be too expensive and slow down connect=
ions too much.


Juho=

From ynir@checkpoint.com  Tue Nov 12 02:18:19 2013
Return-Path: <ynir@checkpoint.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 DADEB11E8131 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:18:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.533
X-Spam-Level: 
X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 NlclTFhvmi+K for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:18:13 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C73CB21E80B0 for <tls@ietf.org>; Tue, 12 Nov 2013 02:17:56 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rACAHmQ5009011; Tue, 12 Nov 2013 12:17:52 +0200
X-CheckPoint: {5281FE81-2-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.77]) by IL-EX10.ad.checkpoint.com ([169.254.2.146]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:17:49 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJoZ/eSAgAACNYCAAKYnAIAArvgAgAVVagCAABudAIAAfj+AgAADBIA=
Date: Tue, 12 Nov 2013 10:17:48 +0000
Message-ID: <220A63FE-C205-4CB6-B78F-25EE9EE14355@checkpoint.com>
References: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp> <528193BC.9060804@seantek.com> <CA+BZK2qiFM-xruwgRDU8Nf8K7=E6sLytnQYF9xp=VWB9jiuxtQ@mail.gmail.com>
In-Reply-To: <CA+BZK2qiFM-xruwgRDU8Nf8K7=E6sLytnQYF9xp=VWB9jiuxtQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.122]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9A27C1558E0CB04493314182F021FDC1@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 10:18:19 -0000

On Nov 12, 2013, at 12:06 PM, Ralf Skyper Kaiser <skyper@thc.org>
 wrote:

> Hi,
>=20
> Martin, you are right that SNI is currently implemented and transmitted i=
n clear.
> This was however not the primary design goal but rather a choice of conve=
nience
> and lack of better/easier ideas. The primary design goal for SNI was to a=
llow
> multi-homing HTTPS servers on the same IP (so that apache can select the
> correct x509 certificate for whatever site the client requested). There i=
s no
> practical or security benefit  or transmitting SNI in clear.=20

There is a design I've seen at a site some years ago. I don't know how popu=
lar this is, but at least there's a non-empty set of servers doing this.

They have multiple servers within the datacenter and a reverse proxy. All s=
erver names resolve to the address of the reverse proxy. For each connectio=
n, it reads the ClientHello and extracts the SNI, and then forwards the Cli=
entHello (and the rest of the connection) to the appropriate server. In no =
SNI, there is a default server (which is where most of the traffic is going=
 anyways)

With encrypted SNI it would have to actually terminate the TLS rather than =
just look at the ClientHello.

Yoav


From skyper@thc.org  Tue Nov 12 02:28:43 2013
Return-Path: <skyper@thc.org>
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 1414B21F9FF6 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.098
X-Spam-Level: *
X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[AWL=-0.646,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 vQOq0v9zCli6 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:28:39 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6145321F9C10 for <tls@ietf.org>; Tue, 12 Nov 2013 02:28:28 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so9648049iec.13 for <tls@ietf.org>; Tue, 12 Nov 2013 02:28:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=3ngkZrGjoVetDCae2Bo/ooMbz3KSjU+RI0axdCvko9k=; b=adJyZDQFK2YlUAOIL04POMWel/Qs1yYOYYFZxwyx9JU4zvkoLHd2odgKao8mjG0E7K vf1BvDdTMfy5weeWTx+cz1O8JIIJCCj+9YNqcqf+AgBmLAcEAcBhm/x9u9WRI6t0qRVV hd/ccI5nlAK+IKjGSPUEmNM/xjFZFj224uc6c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=3ngkZrGjoVetDCae2Bo/ooMbz3KSjU+RI0axdCvko9k=; b=IqBf8Ac1MIdY4I6gYOoTsDDDnNTAVOKlEtKAYjU+KDN7KF6U7Z5dMuGn2AXRtHQluP YuC2tzam/GXgVJfNth/RR1kIsIrd7xSXCuZf8MfvZGnSF8+usV1tYS6DjU/t9gvtq/J2 Bx05DMHoq+B4N4Zfz3K4ytlaKiHvlq1l2OL9EoXf6oSFJLl9qnke6CwcWXIiot08JcV3 Yq6qAof2h3GktxauNwB00a/0wOU99NAysYFNrW1LuzhmdD8w+9fcqXhRLlCUhLQ60PGx uRA4enSgOYXbBMGuThf28D75bXGXIv42C1BJkcH/dXR8pbCsuU7tqV/yZzZ7Pd8iHAtZ Bdtg==
X-Gm-Message-State: ALoCoQlxxeqN9Bed9Mw6cKvA/hdTMEN3EYVyaKxusgyFSdaSa1K/XO64Bla1bmJmjmxZY0w156n4
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr15083466igb.46.1384252096344; Tue, 12 Nov 2013 02:28:16 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Tue, 12 Nov 2013 02:28:16 -0800 (PST)
X-Originating-IP: [217.39.7.72]
In-Reply-To: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
Date: Tue, 12 Nov 2013 10:28:16 +0000
Message-ID: <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e0d1f7b89c804eaf84efa
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Tue, 12 Nov 2013 10:28:43 -0000

--047d7b2e0d1f7b89c804eaf84efa
Content-Type: text/plain; charset=ISO-8859-1

Hi,

could not find it in the draft:

the interoperability with draft-ietf-websec-key-pinning-08 should be
mentioned explicitly to prevent
an attack scenario. (e.g. user has pinned certificate for google.com.
Attacker MITM forces
client to do tls-pwd. Client should not allow this). E.g. once a host is
pinned no other server-side
auth mechanism should be allowed.

regards,

ralf


On Fri, Nov 8, 2013 at 1:11 AM, Joseph Salowey (jsalowey) <
jsalowey@cisco.com> wrote:

> This is the beginning of the working group last call for
>  draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for TLS-PWD
> has been reviewed by the IRTF CFRG group with satisfactory results.  The
> document needs particular attention paid to the integration of this
> mechanism into the TLS protocol.   Please send comments to the TLS list by
> December 2, 2013.
>
> - Joe
> (For the TLS chairs)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b2e0d1f7b89c804eaf84efa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi,<br><br></div><div>could not find it in the <=
span class=3D"">draft</span>:<br><br></div>the interoperability with <span =
class=3D"">draft</span>-<span class=3D"">ietf</span>-websec-key-pinning-08 =
should be mentioned explicitly to prevent<br>
an attack scenario. (e.g. user has pinned certificate for <a href=3D"http:/=
/google.com" target=3D"_blank">google.com</a>. Attacker MITM forces<br>
</div><div>client to do <span class=3D"">tls</span>-<span class=3D"">pwd</s=
pan>. Client should not allow this). E.g. once a host is pinned no other se=
rver-side<br>auth mechanism should be allowed.<br><br></div>regards,<br><br=
>
ralf</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Fri, Nov 8, 2013 at 1:11 AM, Joseph Salowey (jsalowey) <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jsalowey@cisco.com" target=3D"_blank">jsalowey@cisco.co=
m</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">This is the beginning of the working group l=
ast call for =A0draft-ietf-tls-pwd-01. =A0 The underlying cryptographic pro=
tocol for TLS-PWD has been reviewed by the IRTF CFRG group with satisfactor=
y results. =A0The document needs particular attention paid to the integrati=
on of this mechanism into the TLS protocol. =A0 Please send comments to the=
 TLS list by December 2, 2013.<br>

<br>
- Joe<br>
(For the TLS chairs)<br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</blockquote></div><br></div>

--047d7b2e0d1f7b89c804eaf84efa--

From yaronf.ietf@gmail.com  Tue Nov 12 02:51:27 2013
Return-Path: <yaronf.ietf@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 1D58521E80A9 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 gJpAvQ+xHc4A for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:51:26 -0800 (PST)
Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF821E80A8 for <tls@ietf.org>; Tue, 12 Nov 2013 02:51:26 -0800 (PST)
Received: by mail-bk0-f42.google.com with SMTP id w16so2164425bkz.15 for <tls@ietf.org>; Tue, 12 Nov 2013 02:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B9k6+TjDqhYul9m1AKft4AI7zuIrT3Vu/tAffNdDO9s=; b=NOBOhgPh00Dk72HpXRhP3jAfHkCbcclrNMn1NWSjctd9iEJBQNx4IiBtAxHT4zWKt2 S4RlBWJrYwayzXldbZRx+X10x1EZO7qRghIw9pomJYxLLSI9Lns4F7VR5gg6YAsbbI86 Nj/F6+NVhXE1jr9xsNt+mq+ALfABqyjw6YMWyRoCW+vq8feNbnkxszHghwg3YrVTKY+1 Pw6toTUZM5u/nmPG3dIxlzoosAvxmC0/V/cVvN7czUxcgl51DtPuFX1yklsD38SVE9I4 NvzN0NUv9m48OCi6wJTLbcplD5o2sS6WBn+Jx1Me1c+vUk9rVMZKjI3h3grZHN2R4EWW xL2g==
X-Received: by 10.204.69.202 with SMTP id a10mr1156016bkj.36.1384253485307; Tue, 12 Nov 2013 02:51:25 -0800 (PST)
Received: from [10.0.0.8] (109-186-48-194.bb.netvision.net.il. [109.186.48.194]) by mx.google.com with ESMTPSA id on10sm17539964bkb.13.2013.11.12.02.51.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 02:51:24 -0800 (PST)
Message-ID: <5282082B.8060003@gmail.com>
Date: Tue, 12 Nov 2013 12:51:23 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>, "tls@ietf.org" <tls@ietf.org>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 10:51:27 -0000

What Nikos proposes is reminiscent of what happened with IKEv2. I wasn't 
following closely at the time (more than 10 years ago), but:

- This did bring in people from the research community. See for example, 
http://tools.ietf.org/html/draft-ietf-ipsec-jfk-03.
- It took WAY longer than 2 IETF cycles.
- As far as I know there was never a problem statement document.

So it's not a glowing example, but it proves this can be done.

Thanks,
	Yaron

On 11/12/2013 12:05 PM, Yoav Nir wrote:
> Hi Nikos. This is pretty much what httpbis did for HTTP/2. Only it did not take a year or two - only two IETF cycles.
>
> So a competition could be announced now, with proposals presented in London, and a decision reached before Toronto.
>
> While there are many research groups, they don't do protocol work so much.
>
> The real tricky thing here is not designing a "new TLS", but co-existence with SSLv3, TLS 1.0, 1.1, and 1.2 without resorting to the kind of fallback mechanism where you try with TLS 1.3 (or 2.0, or even better - 4.0) and if you get a reset, try again with TLS 1.2, and if that doesn't work, go straight to SSLv3.
>
> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos
> Sent: Tuesday, November 12, 2013 11:55 AM
> To: tls@ietf.org
> Subject: [TLS] a proposal for TLS 1.3
>
> Hello,
>   Having seen the current discussion for TLS 1.3, I have some proposal.
> Since the changes requested are large, I'd suggest not to design TLS 1.3 in this working group. I'd suggest this working group to set the specs for the next TLS version (and better name it 2.0), and then announce a competition for the initial draft of the protocol. Then have the WG review the submitted proposals in a year or two, accept a winner, and the WG starts working on the winning draft.
>
> I'm pretty sure there are many research groups that will be honoured to join such a competition and their results may outperform the results of the limited number of participants in the working group.
>
> best regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From skyper@thc.org  Tue Nov 12 03:11:15 2013
Return-Path: <skyper@thc.org>
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 8085111E8127 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.357
X-Spam-Level: *
X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 1jm0idt4J7bc for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:11:11 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31111E812B for <tls@ietf.org>; Tue, 12 Nov 2013 03:11:11 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id at1so3786021iec.30 for <tls@ietf.org>; Tue, 12 Nov 2013 03:11:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J4dIVlHqT+RxP/eazGbiC974ttK+/BdW7MtRgZFNYfk=; b=LmVsWpMrb/SNkAT9JWdUbGi8YlnUTEFYM4HEEeIm7CoQQkY2QH1OE54ixJpb4NoQ08 tFiXXvyqM1K6cWxPmN2hVtgvQHugW7eIgXgBvDJyUnHGrKGE1eECjzopJFFrm004fr/Z V4CXeQm/FfYcY5t9zwEmKAOJ6nOemrBo8HlL0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J4dIVlHqT+RxP/eazGbiC974ttK+/BdW7MtRgZFNYfk=; b=PYj3w5Nv9Bi+tYRobsnX4e+D/wC69hwrTimqAKFS4b+AZRF6DfxfVIJYURYV+duC7L 7PJG6ZbIIx3dQ/cJ6ROTqx6q3e6VwvW/+OzWv7Bzd6BEon0+ZAIAfPzSAt7k12lAPIGi J6qrC2JGk7OF1aEoooH5Zn0f3gcjUDVTejgfU4Hw4odfa9TMqnGs3zuvVQDn6JvyfiEE L7xz3LEHuMFe+XBxAtO+p+Y32wDnqFVszKJqEEm05Yseh6sZu7kq8is50Dt/1E5q9ZZO azzl15YmR7Utff/7S5xhR0braxoIRyo4tXOrbztAGdo6QXXgVvHhMkHqEmlqL4sEvQoX otKQ==
X-Gm-Message-State: ALoCoQnroMSJx0BLRnYtHn24LzczcFi/+6sYOpHxIPNa0EihPH3Pn5Iynt0M16a9/72GN8Uh5i+N
MIME-Version: 1.0
X-Received: by 10.50.6.99 with SMTP id z3mr15301241igz.27.1384254670457; Tue, 12 Nov 2013 03:11:10 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Tue, 12 Nov 2013 03:11:10 -0800 (PST)
X-Originating-IP: [86.152.141.101]
In-Reply-To: <220A63FE-C205-4CB6-B78F-25EE9EE14355@checkpoint.com>
References: <20131112005546.D6E781AA7B@ld9781.wdf.sap.corp> <528193BC.9060804@seantek.com> <CA+BZK2qiFM-xruwgRDU8Nf8K7=E6sLytnQYF9xp=VWB9jiuxtQ@mail.gmail.com> <220A63FE-C205-4CB6-B78F-25EE9EE14355@checkpoint.com>
Date: Tue, 12 Nov 2013 11:11:10 +0000
Message-ID: <CA+BZK2oaWjyTGf9xcAhsZpZROcVTucT8OsYje6q9_OfrrZhYaw@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary=e89a8f3b9c23e9612604eaf8e79a
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 11:11:15 -0000

--e89a8f3b9c23e9612604eaf8e79a
Content-Type: text/plain; charset=ISO-8859-1

Hi Yoav,

thanks for pointing this out. How widely is this technique used? (and
clients which do not support SNI [there are plenty!]
can not connect at all via HTTPS with what they are doing - odd. but i'm
not here to judge :>).

We shall not compromise the security of the many to accommodate the
performance needs of the few.

Get a F5 or equivalent SSL Proxy. Done.

regards,

ralf


On Tue, Nov 12, 2013 at 10:17 AM, Yoav Nir <ynir@checkpoint.com> wrote:

>
> On Nov 12, 2013, at 12:06 PM, Ralf Skyper Kaiser <skyper@thc.org>
>  wrote:
>
> > Hi,
> >
> > Martin, you are right that SNI is currently implemented and transmitted
> in clear.
> > This was however not the primary design goal but rather a choice of
> convenience
> > and lack of better/easier ideas. The primary design goal for SNI was to
> allow
> > multi-homing HTTPS servers on the same IP (so that apache can select the
> > correct x509 certificate for whatever site the client requested). There
> is no
> > practical or security benefit  or transmitting SNI in clear.
>
> There is a design I've seen at a site some years ago. I don't know how
> popular this is, but at least there's a non-empty set of servers doing this.
>
> They have multiple servers within the datacenter and a reverse proxy. All
> server names resolve to the address of the reverse proxy. For each
> connection, it reads the ClientHello and extracts the SNI, and then
> forwards the ClientHello (and the rest of the connection) to the
> appropriate server. In no SNI, there is a default server (which is where
> most of the traffic is going anyways)
>
> With encrypted SNI it would have to actually terminate the TLS rather than
> just look at the ClientHello.
>
> Yoav
>
>

--e89a8f3b9c23e9612604eaf8e79a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Hi Yoav,<br><br></div>thanks for point=
ing this out. How widely is this technique used? (and clients which do not =
support SNI [there are plenty!]<br>can not connect at all via HTTPS with wh=
at they are doing - odd. but i&#39;m not here to judge :&gt;).<br>
</div><div><br></div></div>We shall not compromise the security of the many=
 to accommodate the performance needs of the few.<br><br>Get a F5 or equiva=
lent SSL Proxy. Done.<br><br></div>regards,<br><br>ralf<br></div><div class=
=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Tue, Nov 12, 2013 at 10:17 AM, Yoav N=
ir <span dir=3D"ltr">&lt;<a href=3D"mailto:ynir@checkpoint.com" target=3D"_=
blank">ynir@checkpoint.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
On Nov 12, 2013, at 12:06 PM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyp=
er@thc.org">skyper@thc.org</a>&gt;<br>
<div class=3D"im">=A0wrote:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; Martin, you are right that SNI is currently implemented and transmitte=
d in clear.<br>
&gt; This was however not the primary design goal but rather a choice of co=
nvenience<br>
&gt; and lack of better/easier ideas. The primary design goal for SNI was t=
o allow<br>
&gt; multi-homing HTTPS servers on the same IP (so that apache can select t=
he<br>
&gt; correct x509 certificate for whatever site the client requested). Ther=
e is no<br>
&gt; practical or security benefit =A0or transmitting SNI in clear.<br>
<br>
</div>There is a design I&#39;ve seen at a site some years ago. I don&#39;t=
 know how popular this is, but at least there&#39;s a non-empty set of serv=
ers doing this.<br>
<br>
They have multiple servers within the datacenter and a reverse proxy. All s=
erver names resolve to the address of the reverse proxy. For each connectio=
n, it reads the ClientHello and extracts the SNI, and then forwards the Cli=
entHello (and the rest of the connection) to the appropriate server. In no =
SNI, there is a default server (which is where most of the traffic is going=
 anyways)<br>

<br>
With encrypted SNI it would have to actually terminate the TLS rather than =
just look at the ClientHello.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Yoav<br>
<br>
</font></span></blockquote></div><br></div>

--e89a8f3b9c23e9612604eaf8e79a--

From ietf-ietf-tls@m.gmane.org  Tue Nov 12 03:31:59 2013
Return-Path: <ietf-ietf-tls@m.gmane.org>
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 C04D421E80AC for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9TPXwaq61z3E for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:31:53 -0800 (PST)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 03A8721E80BA for <tls@ietf.org>; Tue, 12 Nov 2013 03:31:50 -0800 (PST)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <ietf-ietf-tls@m.gmane.org>) id 1VgCCC-00049Y-S3 for tls@ietf.org; Tue, 12 Nov 2013 12:31:48 +0100
Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Tue, 12 Nov 2013 12:31:48 +0100
Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Tue, 12 Nov 2013 12:31:48 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed <eternaleye@gmail.com>
Date: Tue, 12 Nov 2013 03:31:37 -0800
Lines: 24
Message-ID: <l5t3ig$2ev$1@ger.gmane.org>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com> <5282082B.8060003@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-50-132-41-203.hsd1.wa.comcast.net
User-Agent: KNode/4.11.1
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 11:31:59 -0000

I'd also suggest that the state of affairs is more optimistic than this 
would suggest simply due to the passage of time - look at the drastically 
increased participation between the AES competition and the SHA-3 
competition; cryptography research seems to only be getting better-
distributed.

Perhaps this could drive a boom in cryptographic protocol research the same 
way the AES and SHA-3 competitions seem to have done for their fields. 
There's certainly a better public awareness of the need for it.

Yaron Sheffer wrote:

> What Nikos proposes is reminiscent of what happened with IKEv2. I wasn't
> following closely at the time (more than 10 years ago), but:
> 
> - This did bring in people from the research community. See for example,
> http://tools.ietf.org/html/draft-ietf-ipsec-jfk-03.
> - It took WAY longer than 2 IETF cycles.
> - As far as I know there was never a problem statement document.
> 
> So it's not a glowing example, but it proves this can be done.
> 
> Thanks,
> Yaron


From hannes.tschofenig@gmx.net  Tue Nov 12 03:38:07 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 94FC611E8125 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 vvnuVhqEtmyl for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:37:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 56F6B11E8132 for <tls@ietf.org>; Tue, 12 Nov 2013 03:37:45 -0800 (PST)
Received: from Masham-MAC.local ([91.179.213.128]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M7ojs-1VTBiQ2DRY-00vPre for <tls@ietf.org>; Tue, 12 Nov 2013 12:37:42 +0100
Message-ID: <52821305.6070104@gmx.net>
Date: Tue, 12 Nov 2013 12:37:41 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com> <5282082B.8060003@gmail.com>
In-Reply-To: <5282082B.8060003@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:SKrMNkQg4r4V/7XJBIHZUxRHsbi9CZpAGsPKuOmsh9hHEjW5WmQ X+/CebfcZYv12Z+3DRBfE2xNBKkwSjoyodCdvEB2ghrKc4U0HwNR27h8+HkpcY5y3N0Uv3p rjas7bkxHkH+zeR14N8b45n41N5e8d3HCBdzbY1VOIYM/DbsHdQxGo944wMRAAVSmac1A7a HEN+KvTnd/oZ8BaETYXBg==
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 11:38:07 -0000

The story in IKEv2 was different. There were a few guys (already active 
in the IETF for a long time) proposing designs and there wasn't really 
an outreach to the research  outside the IETF, as far as I recall.

There was some work on documenting the design decisions (which also 
explains the problem being solved and captures the requirements) but 
that did not go anywhere. Here is the document: 
http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-tutorial-01

Of course it takes longer than 2 IETF when it comes to such a complex task.

Am 12.11.13 11:51, schrieb Yaron Sheffer:
> What Nikos proposes is reminiscent of what happened with IKEv2. I wasn't
> following closely at the time (more than 10 years ago), but:
>
> - This did bring in people from the research community. See for example,
> http://tools.ietf.org/html/draft-ietf-ipsec-jfk-03.
> - It took WAY longer than 2 IETF cycles.
> - As far as I know there was never a problem statement document.
>
> So it's not a glowing example, but it proves this can be done.
>
> Thanks,
>      Yaron
>
> On 11/12/2013 12:05 PM, Yoav Nir wrote:
>> Hi Nikos. This is pretty much what httpbis did for HTTP/2. Only it did
>> not take a year or two - only two IETF cycles.
>>
>> So a competition could be announced now, with proposals presented in
>> London, and a decision reached before Toronto.
>>
>> While there are many research groups, they don't do protocol work so
>> much.
>>
>> The real tricky thing here is not designing a "new TLS", but
>> co-existence with SSLv3, TLS 1.0, 1.1, and 1.2 without resorting to
>> the kind of fallback mechanism where you try with TLS 1.3 (or 2.0, or
>> even better - 4.0) and if you get a reset, try again with TLS 1.2, and
>> if that doesn't work, go straight to SSLv3.
>>
>> -----Original Message-----
>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
>> Nikos Mavrogiannopoulos
>> Sent: Tuesday, November 12, 2013 11:55 AM
>> To: tls@ietf.org
>> Subject: [TLS] a proposal for TLS 1.3
>>
>> Hello,
>>   Having seen the current discussion for TLS 1.3, I have some proposal.
>> Since the changes requested are large, I'd suggest not to design TLS
>> 1.3 in this working group. I'd suggest this working group to set the
>> specs for the next TLS version (and better name it 2.0), and then
>> announce a competition for the initial draft of the protocol. Then
>> have the WG review the submitted proposals in a year or two, accept a
>> winner, and the WG starts working on the winning draft.
>>
>> I'm pretty sure there are many research groups that will be honoured
>> to join such a competition and their results may outperform the
>> results of the limited number of participants in the working group.
>>
>> best regards,
>> Nikos
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From hallam@gmail.com  Tue Nov 12 06:13:41 2013
Return-Path: <hallam@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 BD47521E811F for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 06:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nN69b6Ohcwp4 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 06:13:41 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F172511E8143 for <tls@ietf.org>; Tue, 12 Nov 2013 06:13:36 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id ep20so2234744lab.3 for <tls@ietf.org>; Tue, 12 Nov 2013 06:13:35 -0800 (PST)
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=zPYFZG1M1Pv/sVSzq7Geitti+o2tM2Qi8QT4NwscnBA=; b=VVUGxL7+htxsdJRogmLaGVD3UFTwJS82S610US+ZTyU3rrMA/i7HqQzRKhr3e8z0Fw UO6AQnf5X6XJ4vjxdpuRnvGmj2gbQOXZItGs8g3xAmxoPvzJ/7AUq8P3oKVZexjv3U6N LrYy50HatwV/sdRaO2x7I2gnVdwSkAkCbFmFRPqHRKCE7vwMFR27VO2feMLqiHOBOBcq cSgHMFvqe0pJGPqNhGiL7DfIKLc83pJOVZD+PvzTDFIfAM+4drHARs4XlCZFxhmcoQRY ThkDtq7g9JP3/4zQN/zy/4GCs7IQZ1Pq5Nrt1/hzoVWivVHie7uBfIxwyb+Gs6nXPW1Y kGJA==
MIME-Version: 1.0
X-Received: by 10.152.36.225 with SMTP id t1mr12502789laj.5.1384265615830; Tue, 12 Nov 2013 06:13:35 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Tue, 12 Nov 2013 06:13:35 -0800 (PST)
In-Reply-To: <CA+BZK2qa3tiHWVQF+DGn5XRRvdWCKYYUMdEEQjOQQpidioFqOw@mail.gmail.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <527D3E04.9050206@pobox.com> <CA+BZK2qa3tiHWVQF+DGn5XRRvdWCKYYUMdEEQjOQQpidioFqOw@mail.gmail.com>
Date: Tue, 12 Nov 2013 06:13:35 -0800
Message-ID: <CAMm+LwjXTc_70PV0L552BTYs7sv37EUjsazbZ_4tddUR6Qd9xg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: multipart/alternative; boundary=089e0158b5d44e7dd704eafb74c7
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 14:13:41 -0000

--089e0158b5d44e7dd704eafb74c7
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 8, 2013 at 1:42 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:

> Hi,
>
> absolutely. Encrypted SNI in TLS 1.3 will be received by server prior to
> selecting a certificate.
>
> ALPN could be encrypted as well (same reason, same solution).
>
> regards,
>
> ralf
>

What am I missing here, how do you turn on encryption before the client
sees the encryption credential.

Sure you could soft encrypt under a non authenticated key, but that does
not provide a lot of security.


As for economic issues 'not being a consideration', if the group does not
make TLS 1.3 viable commercially then either nobody will use it or the
commercial providers will fork. We have already had two forks in PKIX
because people refused to consider practicality over ideology.

Multihosting is not becoming less common, it is becoming more so. We cannot
burn one IPv4 address per session. And if we did the mapping of domain to
IP address would become 1:1 and the name would leak anyway.

Modern multihosting is dynamic. The provider has no idea which machine a
site is going to pop up on and it can change from day to day. Any scheme
that required all certs to be issued by the same provider is going to be
unacceptable.


-- 
Website: http://hallambaker.com/

--089e0158b5d44e7dd704eafb74c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Nov 8, 2013 at 1:42 PM, Ralf Skyper Kaiser <span dir=3D"ltr=
">&lt;<a href=3D"mailto:skyper@thc.org" target=3D"_blank">skyper@thc.org</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br></div><div>=
absolutely. Encrypted SNI in TLS 1.3 will be received by server prior to se=
lecting a certificate.<br>
<br></div><div>ALPN could be encrypted as well (same reason, same solution)=
.<br>
</div><div><br>regards,<br><br></div><div>ralf</div></div></blockquote><div=
><br></div><div>What am I missing here, how do you turn on encryption befor=
e the client sees the encryption credential.</div><div><br></div><div>
Sure you could soft encrypt under a non authenticated key, but that does no=
t provide a lot of security.</div><div><br></div><div><br></div><div>As for=
 economic issues &#39;not being a consideration&#39;, if the group does not=
 make TLS 1.3 viable commercially then either nobody will use it or the com=
mercial providers will fork. We have already had two forks in PKIX because =
people refused to consider practicality over ideology.</div>
<div><br></div><div>Multihosting is not becoming less common, it is becomin=
g more so. We cannot burn one IPv4 address per session. And if we did the m=
apping of domain to IP address would become 1:1 and the name would leak any=
way.</div>
<div><br></div><div>Modern multihosting is dynamic. The provider has no ide=
a which machine a site is going to pop up on and it can change from day to =
day. Any scheme that required all certs to be issued by the same provider i=
s going to be unacceptable.=A0</div>
<div><br></div></div><div><br></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br>
</div></div>

--089e0158b5d44e7dd704eafb74c7--

From dkg@fifthhorseman.net  Tue Nov 12 06:28:48 2013
Return-Path: <dkg@fifthhorseman.net>
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 DC80721E8124 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 06:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 taLAEPZ3kA77 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 06:28:32 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4F31A11E815C for <tls@ietf.org>; Tue, 12 Nov 2013 06:28:30 -0800 (PST)
Received: from [192.168.13.151] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id E177CF986 for <tls@ietf.org>; Tue, 12 Nov 2013 09:28:18 -0500 (EST)
Message-ID: <52823B00.8090607@fifthhorseman.net>
Date: Tue, 12 Nov 2013 09:28:16 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: "tls@ietf.org" <tls@ietf.org>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com>	<527D3E04.9050206@pobox.com>	<CA+BZK2qa3tiHWVQF+DGn5XRRvdWCKYYUMdEEQjOQQpidioFqOw@mail.gmail.com> <CAMm+LwjXTc_70PV0L552BTYs7sv37EUjsazbZ_4tddUR6Qd9xg@mail.gmail.com>
In-Reply-To: <CAMm+LwjXTc_70PV0L552BTYs7sv37EUjsazbZ_4tddUR6Qd9xg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1lWIVco9He51rVSe9GtCEGT8kSHuisRcC"
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 14:28:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--1lWIVco9He51rVSe9GtCEGT8kSHuisRcC
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/12/2013 09:13 AM, Phillip Hallam-Baker wrote:
> What am I missing here, how do you turn on encryption before the client=

> sees the encryption credential.

e.g. using a PFS key exchange, you could include the SNI data after the
key negotiation, but before the server certificate. (i think this
introduces an extra round trip)

> Sure you could soft encrypt under a non authenticated key, but that doe=
s
> not provide a lot of security.

it provides confidentiality in the face of a passive attacker, which is
specifically what is being asked for.  I think it's clear that this
information is not possible to hide from an active attacker who is
willing to cause connection failures to find out the name of the server
the client is trying to reach.

	--dkg


--1lWIVco9He51rVSe9GtCEGT8kSHuisRcC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSgjsAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcxMgP/01honOYVsD+lK0VZkCsKUBX
9p5UvcjtT/+d3ICMa3TJoQkciy2pWkgYYkcDpExw8sxnTaLMKljDcIO7Wfcdp3Y/
fAWPq0zbdbIJ/aT1JKMIaAwsOa+xi1E8ykpVBofFMF9GNThZ3fuzcHHjBBcPQh7g
zPcoQDuzDOoNPVxrltRMglIu8p6yegoqFWOB2o9INtsF5bobq69tCWTsv38fAwzz
QAQz00AqHlfEl9U88DCOhM2o0YGUOXzi+nT9XXcMLAGXaGC5ldQGXsvAUg8C/r8Z
agK0YiqOwk/kxcT8yNrj830giMexWCu1hhUTdk5YGwrUK3JU38UY+WdHpc/ySMds
wpOq30TdnWHsTSgcuniSNdgNb0sXbBiabdwmXzZfNHds2flF3XiYRiEwtPEQsOC5
0G6PSOwN8cotekiInVI52IVOanoqZ0zJV4PqXqS80FYOgkv3cqXoYKOyOEpxN97q
dESdy20WR/bpl+KzBQdcn0sdmNBFuM5/J0HBqaz0nij5IomVi4i8DYt+rkIjFdSY
ObkNIAmPqMs2XPasbIMcegXN8dkjUZDGw+w9SelfajVdPkt18fTtfM302yMEWjcn
vqKJwpXe3KaRua+mIegMq/mbH4NM2G8xaknngr69iUtSDKZ79+ywCuV/yIbwu7GP
/a/G9CL3p1brC5CM5s7z
=PjT4
-----END PGP SIGNATURE-----

--1lWIVco9He51rVSe9GtCEGT8kSHuisRcC--

From skyper@thc.org  Tue Nov 12 06:56:35 2013
Return-Path: <skyper@thc.org>
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 0586711E8170 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 06:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 CgCAf2JRqRrD for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 06:56:28 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C010C11E8169 for <tls@ietf.org>; Tue, 12 Nov 2013 06:56:27 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id to1so4681728ieb.15 for <tls@ietf.org>; Tue, 12 Nov 2013 06:56:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cli9yTGWoO6RkT0KszWpMLvOeIT6TXCwRr8ezET2FPg=; b=edGV9CY51OH8pF8aUL7KWe+6E8jQmO9f8Lt9OpyiNW8GFmh0enOeFM5khvv2hvJW4I RwsEBjqQBiirmj9Bz6vflsFdnA+ZZgxdtnSYuIZvFxYm1lO5Di/r+R9VxOQXo18z4Jfo UPeHSF6xIp3mURIy7nQ3D07dqxE/lLwdILMoc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cli9yTGWoO6RkT0KszWpMLvOeIT6TXCwRr8ezET2FPg=; b=dX9RzQ2oCj92KQceEAoz/AZi20iyn3iULE02qw5Xu8Rk8EMJteDOe0FKhv9NELP3za hr8CGQ2tDedCRK9E+6hVMT6AysdtAn/16UXDKGTB4pAbtD7bI07sOc3g6ETrLUshEbpq DT5kKFXZWIYNRHKQjOaTGwnfKk/YFKGYZiLKP8HeMd2IIQq0Vq8XJxXtzFKD6z5ghkwo /TD/15tuQMSK5p5vqCXPSCDCaCFFaEdx8g7XCRVvxhb9mBF1/DTz3Kt4SFOGuezW/lYU 32LymDg8nOo/fGKpWfrsLqazfp/WmhACnKvdV2lwFyWpg8RySU3UoVAbumraiin+ccYs LtCw==
X-Gm-Message-State: ALoCoQkVLF0m8e2KRwzZ/5YwGKAlVrIR7X1ig7MXXaLYUUGqRuK9Ctx1peTEElW/2DNZwlFxVKcY
MIME-Version: 1.0
X-Received: by 10.50.106.20 with SMTP id gq20mr15869965igb.36.1384268186198; Tue, 12 Nov 2013 06:56:26 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Tue, 12 Nov 2013 06:56:26 -0800 (PST)
X-Originating-IP: [31.55.54.252]
In-Reply-To: <CAMm+LwjXTc_70PV0L552BTYs7sv37EUjsazbZ_4tddUR6Qd9xg@mail.gmail.com>
References: <CA+BZK2qUE3oS6Sbp1HbKZ7Wgen9gEjjdepON1egLhGqCPpoVBw@mail.gmail.com> <527D3E04.9050206@pobox.com> <CA+BZK2qa3tiHWVQF+DGn5XRRvdWCKYYUMdEEQjOQQpidioFqOw@mail.gmail.com> <CAMm+LwjXTc_70PV0L552BTYs7sv37EUjsazbZ_4tddUR6Qd9xg@mail.gmail.com>
Date: Tue, 12 Nov 2013 14:56:26 +0000
Message-ID: <CA+BZK2pcoZTRbchwPmKV98E06L7-9KqzrBfD1=y+kW8viWpEGw@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bea3434833d6f04eafc0d1b
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 14:56:35 -0000

--047d7bea3434833d6f04eafc0d1b
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Tue, Nov 12, 2013 at 2:13 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

>
>
>
> On Fri, Nov 8, 2013 at 1:42 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>
>> Hi,
>>
>> absolutely. Encrypted SNI in TLS 1.3 will be received by server prior to
>> selecting a certificate.
>>
>> ALPN could be encrypted as well (same reason, same solution).
>>
>> regards,
>>
>> ralf
>>
>
> What am I missing here, how do you turn on encryption before the client
> sees the encryption credential.
>
>
The certificate does not contain the encryption credentials.
The certificate can be transmitted after encryption has started.

- server/client: negotiate credentials (not certificate), start encryption
- client: send SNI, ...
- server: send certificate, ...
- authenticate (HMAC over all data that has been send and received during
handshake).

(This is incomplete. Please refer to the protocol-flow that Eric showed at
the IETF88 TLS WG gathering.)



>
>
> As for economic issues 'not being a consideration', if the group does not
> make TLS 1.3 viable commercially then either nobody will use it or the
> commercial providers will fork. We have already had two forks in PKIX
> because people refused to consider practicality over ideology.
>

absolutely. The believe is that Tansport-Layer-Security (encrypted SNI)
will be more widely adapted than Transport-Layer-Kind-Of-Security
(cleartext SNI leakage). Surely for those Atheist in Saudi Arabia or the
Alan Turing's in Britain it would be bad to have the SNI leaked....


>
> Multihosting is not becoming less common, it is becoming more so. We
> cannot burn one IPv4 address per session. And if we did the mapping of
> domain to IP address would become 1:1 and the name would leak anyway.
>

correct. That's why we have SNI (encrypted or not. both serve this purpose).


>
> Modern multihosting is dynamic. The provider has no idea which machine a
> site is going to pop up on and it can change from day to day. Any scheme
> that required all certs to be issued by the same provider is going to be
> unacceptable.
>

I agree.

regards,

ralf

--047d7bea3434833d6f04eafc0d1b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Tue, Nov 12, 2013 at 2:13 PM, Phillip Hallam-Baker <span dir=
=3D"ltr">&lt;<a href=3D"mailto:hallam@gmail.com" target=3D"_blank">hallam@g=
mail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On Fri, Nov 8, 201=
3 at 1:42 PM, Ralf Skyper Kaiser <span dir=3D"ltr">&lt;<a href=3D"mailto:sk=
yper@thc.org" target=3D"_blank">skyper@thc.org</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br></div><div>=
absolutely. Encrypted SNI in TLS 1.3 will be received by server prior to se=
lecting a certificate.<br>

<br></div><div>ALPN could be encrypted as well (same reason, same solution)=
.<br>
</div><div><br>regards,<br><br></div><div>ralf</div></div></blockquote><div=
><br></div></div><div>What am I missing here, how do you turn on encryption=
 before the client sees the encryption credential.</div><div><br></div>
</div></div></div></blockquote><div><br></div><div>The certificate does not=
 contain the encryption credentials.<br>The certificate can be transmitted =
after encryption has started. <br><br></div><div>- server/client: negotiate=
 credentials (not certificate), start encryption<br>
</div><div>- client: send SNI, ...<br></div><div>- server: send certificate=
, ...<br></div><div>- authenticate (HMAC over all data that has been send a=
nd received during handshake).<br><br></div><div>(This is incomplete. Pleas=
e refer to the protocol-flow that Eric showed at the IETF88 TLS WG gatherin=
g.)<br>
<br></div>=A0<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div></div><br><div><br></div><=
div>As for economic issues &#39;not being a consideration&#39;, if the grou=
p does not make TLS 1.3 viable commercially then either nobody will use it =
or the commercial providers will fork. We have already had two forks in PKI=
X because people refused to consider practicality over ideology.</div>
</div></div></div></blockquote><div><br></div><div>absolutely. The believe =
is that Tansport-Layer-Security (encrypted SNI) will be more widely adapted=
 than Transport-Layer-Kind-Of-Security (cleartext SNI leakage). Surely for =
those Atheist in Saudi Arabia or the Alan Turing&#39;s in Britain it would =
be bad to have the SNI leaked....<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"=
gmail_extra"><div class=3D"gmail_quote">
<div><br></div><div>Multihosting is not becoming less common, it is becomin=
g more so. We cannot burn one IPv4 address per session. And if we did the m=
apping of domain to IP address would become 1:1 and the name would leak any=
way.</div>
</div></div></div></blockquote><div><br></div><div>correct. That&#39;s why =
we have SNI (encrypted or not. both serve this purpose).<br>=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div><br></div><div>Modern multihosting is dynamic. The provider has no ide=
a which machine a site is going to pop up on and it can change from day to =
day. Any scheme that required all certs to be issued by the same provider i=
s going to be unacceptable.=A0</div>
</div></div></div></blockquote><div><br></div><div>I agree.<br></div></div>=
<br></div><div class=3D"gmail_extra">regards,<br><br>ralf<br><br></div></di=
v></div>

--047d7bea3434833d6f04eafc0d1b--

From paul.hoffman@vpnc.org  Tue Nov 12 07:13:12 2013
Return-Path: <paul.hoffman@vpnc.org>
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 7394C11E8142 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 07:13:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level: 
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 zJdMoifTbKXh for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 07:13:11 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F06411E8121 for <tls@ietf.org>; Tue, 12 Nov 2013 07:13:11 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rACFD5UJ024282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Nov 2013 08:13:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <52821305.6070104@gmx.net>
Date: Tue, 12 Nov 2013 07:13:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F0635F4-42BE-45DB-8C7C-9FE39E3C4BE3@vpnc.org>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com> <5282082B.8060003@gmail.com> <52821305.6070104@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1822)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 15:13:12 -0000

On Nov 12, 2013, at 3:37 AM, Hannes Tschofenig =
<hannes.tschofenig@gmx.net> wrote:

> The story in IKEv2 was different. There were a few guys (already =
active in the IETF for a long time) proposing designs and there wasn't =
really an outreach to the research  outside the IETF, as far as I =
recall.

You recall incorrectly. There was definite outreach, and this caused =
some good review input but not different proposals. This WG could =
certainly use review from the crypto community.

> There was some work on documenting the design decisions (which also =
explains the problem being solved and captures the requirements) but =
that did not go anywhere. Here is the document: =
http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-tutorial-01

Right, but for a different reason: the WG was never clear on the design =
decisions. Some people were insistent on "has to look like IKEv1" while =
others were insistent on "has to be simpler" and those two could not =
come to any consensus. It came down to the chairs making a decision.

> Of course it takes longer than 2 IETF when it comes to such a complex =
task.

IPsec is important to networks; TLS is important to applications. In the =
past decade, the latter has become more important in the public eye and =
therefore might attract a larger contingent of hopefully-useful input.

--Paul Hoffman=

From watsonbladd@gmail.com  Tue Nov 12 08:05:12 2013
Return-Path: <watsonbladd@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 418D921E8255 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 08:05:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level: 
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057,  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 SIF00tZaqA0o for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 08:05:11 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3D44E21E80C5 for <tls@ietf.org>; Tue, 12 Nov 2013 08:05:11 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id ez12so3909027wid.11 for <tls@ietf.org>; Tue, 12 Nov 2013 08:05:10 -0800 (PST)
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=Gsc6eRF5TcQ+xj2ZdO7DzA3C7A/nAhzq366bf+8Ab10=; b=EY5U8MzWTQRDtu56ZDIzdE5TO/a13BpFBe0asDdFEP4V1TaqXYx9VCNzIJJ3Fsx2S4 Kbp22tIwniXM5Zm4/7pIoyhXjV8WLHK7TiidUAygoLTw2po6EUlx8G2U5y5drqUAkMk+ D0AhO6UUKbZD9OcsKzr6PIJWh4bSMjIdyoz68UIactcGdTkTFJ3KxMSGr+7NOZD22N60 xOEWH8QeOgQH6zKtMhykoTF919qEpde/Ei46FzcUuRzU2hsfGg3Hrh6fuNO9lKy9dTd8 B0x+TG4X0ij4hrIsKRNJFdS+IzzHPCu/2vcQ1Rhs3x9ReI+MsdbJJUp7dbu7BRDOfqaJ 6H7A==
MIME-Version: 1.0
X-Received: by 10.180.78.132 with SMTP id b4mr3802368wix.0.1384272310312; Tue, 12 Nov 2013 08:05:10 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 12 Nov 2013 08:05:10 -0800 (PST)
In-Reply-To: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
Date: Tue, 12 Nov 2013 08:05:10 -0800
Message-ID: <CACsn0cmdH-1GU1tMp5RFpTi2oB-K6Q5dvP_UFC+feJzNY+x1DA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 16:05:12 -0000

On Tue, Nov 12, 2013 at 1:54 AM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> Hello,
>  Having seen the current discussion for TLS 1.3, I have some proposal.
> Since the changes requested are large, I'd suggest not to design TLS 1.3
> in this working group. I'd suggest this working group to set the specs
> for the next TLS version (and better name it 2.0), and then announce a
> competition for the initial draft of the protocol. Then have the WG
> review the submitted proposals in a year or two, accept a winner, and
> the WG starts working on the winning draft.
We need to begin by identifying the problems that require TLS 1.3 to be solved.
Most issues TLS 1.2 with extensions can fix AFAIK. (other than the
multiple round trips, but I'm sure
optimistic extensions can fix that one)
>
> I'm pretty sure there are many research groups that will be honoured
> to join such a competition and their results may outperform the
> results of the limited number of participants in the working group.
Actually, TLS is a very solved problem: creating a secured channel
between two participants,
one of whom has certificates to show the other. What about this isn't
solved in TLS 1.2?
We would get better bang for the buck kicking RC4 out and getting
people to upgrade to TLS 1.2
Sincerely,
Watson
>
> best regards,
> Nikos
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From mrex@sap.com  Tue Nov 12 08:53:52 2013
Return-Path: <mrex@sap.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 3578C21E80AC for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 08:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.184
X-Spam-Level: 
X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 C6U8uKBYmThx for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 08:53:47 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A221E80A1 for <tls@ietf.org>; Tue, 12 Nov 2013 08:53:45 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rACGrhC2003546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Nov 2013 17:53:43 +0100 (MET)
In-Reply-To: <CA+BZK2pu1F3zpRJNFX=QjFh=4JkooTgxkjDFPKBosnVCvuSonA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tue, 12 Nov 2013 17:53:43 +0100 (CET)
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: <20131112165343.CA1101AA80@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 12 Nov 2013 16:53:52 -0000

Ralf Skyper Kaiser wrote:
> 
> Is this preference based on security concerns or personal preference and
> ease of implementation/adaption?

  - kiss principle (least amount of protocol and code changes)
  - don't fix if it ain't broken
  - conservative design, higher security margin.
  - personal preference

Stream & AEAD ciphers use XOR for encryption and neither supports random
padding, so manipulating known plaintext can be achieved with 100% precision.
I therefore want to ensure that my integrity protection has a very high
security margin.


> 
> (Reading the Serge Vaudenary thread  suggest the latter - which is fine by
> me - its worth considering the trade off.)
> 
> Encrypt-then-mac has some other security benefits. (Among others that the
> decrypt routine never has to process bogus/bad messages
> [e.g. those where the MAC would fail in current encrypt-mac].).

Which benefits are this?

I am not aware of any security benefit for the real world from
doing EtA over AtE.

If MAC erros were common in the wild, I would know about it,
because I would get customer inquiries about it and regularly see
it in error logs from customers.  During the last 10 years there was
only one occasion where a customer had a low, but persistent amount
of MAC errors.  On investigation, it wasn't MAC errors, it was
actually RSA decryption failures, caused by a firmware bug in
that customers SSL accellerator (for which the vendor produced
a firmware patch after we reported the problem).

-Martin

From trevp@trevp.net  Tue Nov 12 09:52:22 2013
Return-Path: <trevp@trevp.net>
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 37AE721F9D7E for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 09:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.877
X-Spam-Level: 
X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 FQJU9DuA5TSx for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 09:52:16 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBDD21F9D39 for <tls@ietf.org>; Tue, 12 Nov 2013 09:52:15 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id hn6so1196693wib.5 for <tls@ietf.org>; Tue, 12 Nov 2013 09:52:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5kk5K9hf9D0rA5HBpSOo/Pmbd4SNwQAf5+evzX80Txo=; b=aeiWmTg1fn09juH7u7T3c1kCY1QUuFOAnAomqF7v26El35eIz1aA6F+ed6uiwtiZaS Usq76MVagv3fJ6Kd+WxUA4JEbnkDkVGLIENTEEyuw4RgLMG7D3J1XqhIwwkboSB2b9cG qh2t9GvfiZmodRmA+GEJCMkvhDo0Aepb/0fON7fcqc+64Lw2BOJhIoVYBgF0JeLGbFlR gTTm4pJr1b4O7BwPofp1nyTwe9PZfoJ90fZ5s+PpSy0KbOVfYuHjTJYH4QOfb+/piPLt e2dv+0RY52z0V7ny+ox9Vsk73JqVNprsjeQ9mqZENLuWW3FvXuPI0uUYUbGbQfrNjq4i dxvA==
X-Gm-Message-State: ALoCoQnucM+NRsd+el0GlB/VTRuYUEHE9+cSavXByQ9YE0iOUJMep8ijs/FyxipdFCc1UgnbM7Qn
MIME-Version: 1.0
X-Received: by 10.180.20.102 with SMTP id m6mr9149933wie.22.1384278735254; Tue, 12 Nov 2013 09:52:15 -0800 (PST)
Received: by 10.216.163.5 with HTTP; Tue, 12 Nov 2013 09:52:15 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com>
Date: Tue, 12 Nov 2013 09:52:15 -0800
Message-ID: <CAGZ8ZG0encNJn_G_32LB9=ovRt4dEQpm0q2CBbq=2D0Re2vv4w@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] a proposal for TLS 1.3
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: Tue, 12 Nov 2013 17:52:22 -0000

On Tue, Nov 12, 2013 at 1:54 AM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> Hello,
>  Having seen the current discussion for TLS 1.3, I have some proposal.
> Since the changes requested are large, I'd suggest not to design TLS 1.3
> in this working group. I'd suggest this working group to set the specs
> for the next TLS version (and better name it 2.0), and then announce a
> competition for the initial draft of the protocol.

Agree with Nikos.

There's a lot of interrelated technical issues, and some different
strategies that could be taken.

Having the WG make all these decisions seems likely to produce a
disjointed, frankenstein protocol.  It would be better to have a few
groups producing coherent proposals.

There are proposals already floating around (QUIC, MinimaLT, EKR's),
and we've seen increasing academic interest here (Kenny Paterson,
others), so it seems likely we could get some good designs and
comparative analysis.


Trevor

From mrex@sap.com  Tue Nov 12 10:50:43 2013
Return-Path: <mrex@sap.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 C949611E810F for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 10:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.886
X-Spam-Level: 
X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-8]
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 iJi6EjOK1ekF for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 10:50:38 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 62CE421F9F9E for <tls@ietf.org>; Tue, 12 Nov 2013 10:50:38 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rACIoaMW013717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Nov 2013 19:50:36 +0100 (MET)
In-Reply-To: <52823B00.8090607@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Tue, 12 Nov 2013 19:50:35 +0100 (CET)
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: <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 12 Nov 2013 18:50:43 -0000

Daniel Kahn Gillmor wrote:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
[ Charset UTF-8 unsupported, converting... ]
> On 11/12/2013 09:13 AM, Phillip Hallam-Baker wrote:
> > What am I missing here, how do you turn on encryption before the client
> > sees the encryption credential.
> 
> e.g. using a PFS key exchange, you could include the SNI data after the
> key negotiation, but before the server certificate. (i think this
> introduces an extra round trip)
> 
> > Sure you could soft encrypt under a non authenticated key, but that does
> > not provide a lot of security.
> 
> it provides confidentiality in the face of a passive attacker, which is
> specifically what is being asked for.  I think it's clear that this
> information is not possible to hide from an active attacker who is
> willing to cause connection failures to find out the name of the server
> the client is trying to reach.

Browsers perform the reconnect fallback failures transparently and
silently, and NSA hat their Foxacid servers in place to shoot down
any TLSv1.3 requests they like with a TCP RST.

A single connection failure per client&server pair per day would be
sufficient to elicit cleartext SNIs from clients & cleartext certificates
from servers.

We should design our protocol to provide security in a robust and
resilient fashion, not in a brittle "weather permitting" fashion
that is being suggested.

-Martin

From dkg@fifthhorseman.net  Tue Nov 12 11:10:35 2013
Return-Path: <dkg@fifthhorseman.net>
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 3A8FA11E8138 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 11:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6]
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 feDQYypRrdUP for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 11:10:29 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17E11E810F for <tls@ietf.org>; Tue, 12 Nov 2013 11:10:28 -0800 (PST)
Received: from [192.168.13.151] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2FDFAF986 for <tls@ietf.org>; Tue, 12 Nov 2013 14:10:26 -0500 (EST)
Message-ID: <52827D21.7090007@fifthhorseman.net>
Date: Tue, 12 Nov 2013 14:10:25 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: IETF TLS WG <tls@ietf.org>
References: <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
In-Reply-To: <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FCVrJXVaned5SN7QNfcGXjFv8vI1qRjuW"
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 19:10:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FCVrJXVaned5SN7QNfcGXjFv8vI1qRjuW
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/12/2013 01:50 PM, Martin Rex wrote:
> Browsers perform the reconnect fallback failures transparently and
> silently, and NSA hat their Foxacid servers in place to shoot down
> any TLSv1.3 requests they like with a TCP RST.

I note that you're talking about an active attacker here.

But in general, yes, any tool that silently performs a fallback to an
older version will not get any of the security enhancements offered by a
newer version.  This doesn't mewn we shouldn't try to add any security
enhancements to newer versions, though.  It means we should try to
figure out ways to discourage fallback, or to identify and isolate and
expose peers who require these fallback mechanisms.

> A single connection failure per client&server pair per day would be
> sufficient to elicit cleartext SNIs from clients & cleartext certificat=
es
> from servers.

Yes, it would, i agree.  These mechanisms seem unlikely to protect the
requested identity of the server in the face of an active attacker.  If
we assume that the client has never connected to the server before (i.e.
no pre-cached server public keys, etc), then i don't see any way to
design a protocol that could hide the identity of the party that the
client is trying to reach from an active attacker who is willing to
cause connection failures.  Do you?

> We should design our protocol to provide security in a robust and
> resilient fashion, not in a brittle "weather permitting" fashion
> that is being suggested.

That's exactly what this discussion is trying to do.  It's clear that
the current SNI mechanism always leaks the requested server identity to
anyone on the network path.  The proposal to encrypt it with keys
derived from the as-yet-unauthenticated DH exchange will hide this
information from any passive attacker on the network path.  It even
allows the client to detect a failed connection (and possible requested
server name leak) when an active attacker attempts a MITM.  These are
both a clear improvements over the current situation.

If you have a proposal for a way to hide this information from everyone
on the network path, including active attackers who are willing to cause
connection failures, that would be an even better improvement.

	--dkg


--FCVrJXVaned5SN7QNfcGXjFv8vI1qRjuW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSgn0hXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcstsQANsYljpjv2IIGw3P294aCLwV
k8gH8Foa1UP3mMEzIZMDy+CxIB9BEdJf3CEDUJZ65ahjCgqYbFndHSC3xoUJ1YiS
qTb3aZCiBIuefYZzxQ8v/+MdidXSi1BHI9I4Pvtn5Re28iz6Vw4rmTWGZKGA6x2W
M0LiC72NjxqppiAy/lSfyD7n1ea9OGcn4AQVoVJetDVwVjiGpTh/7BR8hCp/qNc8
VAN8Tbw7+nAXWc5d08xOO2jD21hgM773Y8X2VKfsZ3+q5YoxeSKX5PeaP1bBwPbY
N5JXdWRgrSsYc72XzEkrzQaodp7q4LwHjQXZUsztv34EFxcC9tpCFcbPV+Uem4PE
VnUia/cibn8w6zv3ZyxtwQFyG+KmQDM+2oQUmmeso2VJnkv9VINd0AUgBl5ZCnAW
1EcEYuKvYFhOjjT2YFl0oFWyJIKEwHsBgUJL4f1kfIo9eqUb52XCfkz5Ido3ppLC
gxAeLdQdF//5cssffxywE7Vi1bLMLg1B0BINqVJWQ2uEfHQKVSMDQ9Q8pMLJsRPX
4d1Y8d4RN7PvLwcZWyOjpgoVoTjX7qJGAlk33P8j1OEYGZ6rymcPBbeFywAcfueg
8g0bp7JRg/u5hdxDB0A+fuOKjQo7RdLysUfdlMD5QC9NGSmy4mnixoUKvz9h/eLO
WogBqQyfSUW1pSz0vN1u
=T2Ud
-----END PGP SIGNATURE-----

--FCVrJXVaned5SN7QNfcGXjFv8vI1qRjuW--

From juhovh@iki.fi  Tue Nov 12 11:57:25 2013
Return-Path: <juhovh@iki.fi>
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 BF10B21F9F21 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 11:57:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level: 
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
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 8nrMItv6dcXm for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 11:57:18 -0800 (PST)
Received: from smtp.surffi.net (stardust.surffi.net [82.116.225.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0B38021F9EED for <tls@ietf.org>; Tue, 12 Nov 2013 11:57:17 -0800 (PST)
Received: from mail.visino.fi (N243-201.surffi.net [80.247.243.201]) by smtp.surffi.net (Postfix) with ESMTP id 336495A1FC; Tue, 12 Nov 2013 21:58:49 +0200 (EET)
Received: from [192.168.1.149] (N248-45.surffi.net [80.247.248.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 6B0513FA3B; Tue, 12 Nov 2013 21:57:15 +0200 (EET)
References: <20131112183359.34A6C1AA80@ld9781.wdf.sap.corp>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131112183359.34A6C1AA80@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EA9A50C-4AD0-43F6-B11D-2967C8CC0333@iki.fi>
X-Mailer: iPhone Mail (11B511)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Tue, 12 Nov 2013 21:57:04 +0200
To: "mrex@sap.com" <mrex@sap.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 19:57:25 -0000

> On 12.11.2013, at 20.33, mrex@sap.com (Martin Rex) wrote:
>=20
> Juho V=C3=A4h=C3=A4-Herttua wrote:
>>=20
>> What makes me sad is
>> the knowledge that SNI is leaking the hostname and makes those
>> connections trivial to block, even though I haven't come across
>> SNI based blocking yet.
>=20
> There is _no_ requirement for the TLS client to send SNI at all.

Of course not, but many servers require it in practice.

> In the normal mode of operation of TLS, the server name that the client
> announces through SNI is the name that the client will match against
> the server's certificate.  So blocking based on the names in the
> server's certificate would work for current SSLv3->TLSv1.2, even
> when the client does not send SNI.

That is true, I assumed if there's a common shared secret for encrypting SNI=
 in place, it could also be used for encrypting the certificate.

> One of the problems with making a "solution" part of the official
> standard is that, if anything, the tools in use by the relevant authoritie=
s
> will be able to deal with the "standard" at the time when it becomes usabl=
e
> in the installed base (if that happens at all).

I guess the question is about how transparently they can do that. If a TLS h=
andshake fails halfway is a bit different than failing after ClientHello. Fa=
iling after ClientHello can be interpreted as server simply not accepting th=
e parameters.

> Homegrown/unofficial workarounds tend to work better and longer.

Naturally, but it's not impossible to make official protocols secure enough t=
o at least detect eavesdropping, even if it would be impossible to prevent.

However, I don't see how encrypting SNI and certificate would be possible wi=
thout an extra round-trip, and that might be too expensive even considering t=
he benefits. The current 4-way handshake combined with 3-way handshake of TC=
P is already a bit much. So I'm not completely supporting the encryption, ev=
en though it would be a really nice option if it was widely supported.


Juho=

From skyper@thc.org  Tue Nov 12 12:01:19 2013
Return-Path: <skyper@thc.org>
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 5783D11E8217 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 12:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.657
X-Spam-Level: *
X-Spam-Status: No, score=1.657 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 1gc3R0stbZRZ for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 12:01:15 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD911E81A7 for <tls@ietf.org>; Tue, 12 Nov 2013 12:01:14 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id e14so330927iej.13 for <tls@ietf.org>; Tue, 12 Nov 2013 12:01:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ETkRucJok0wdnyDDdKsOySPwiRVUO6RSUujuTjWHC+c=; b=QqJ8EfPDt+lwAZ8FrYnOb4R53nORPUvlUXFmqAXOkZEivh8o/VnVtpmgxPaorOO7cd FBIqpXFVORJi5K1cm1B2JEUCINK8kk/BPtusXOxJ54JjPTh7U85qINMnSuktewZ1KpOJ zs1uBv526T2u4oVDz9R1GYyt+9/H6QdS2T+F0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ETkRucJok0wdnyDDdKsOySPwiRVUO6RSUujuTjWHC+c=; b=KM6sZxLImhi6pYYjOrSig1b/JFdvg0GnKhHNmvE5T99dVQ9odnubr+oMyboyEwu2+O QO8wZ+tOU/41BnrKMrtq7HnMW9siEpfFF9Itu5+IkvPHZ2u7NUwapvsPbpMWvnlCceXt gihxJFu3lj0m0UES5tP8CCehbBU8lPffw3WVq4RWwq+S7e0OZ/67gOKDh1a2LY3+4T4I 6Y05e9iOovtiGhctNkntdN/60cU0ym/8nuyqggquohJvkg86BGmtM4X14Pqy6AJUFOyx wAzc5isgkLNhg/istr9nJbhrgYjXxet3ifVPwsfPtedTryfJWO7tc6qFXczlAi3fvl6n 6d4w==
X-Gm-Message-State: ALoCoQlk6hyT1mpqhm+LTLtFzqpzBS4vKBv7Dr8zrV54QqU1SFeKLANyb2o62Z2Cn1qANBRNNmpe
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr16474054igb.46.1384286474232; Tue, 12 Nov 2013 12:01:14 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Tue, 12 Nov 2013 12:01:14 -0800 (PST)
X-Originating-IP: [80.195.189.45]
In-Reply-To: <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
References: <52823B00.8090607@fifthhorseman.net> <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
Date: Tue, 12 Nov 2013 20:01:14 +0000
Message-ID: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=047d7b2e0d1f911eb704eb004fcf
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 20:01:19 -0000

--047d7b2e0d1f911eb704eb004fcf
Content-Type: text/plain; charset=ISO-8859-1

Martin,

I disagree.

1. The user can decide to force TLS 1.3
2. The attack that you describe requires active packet injection. We just
increased the cost for the attacker from passive recording of data to
active packet injection. Active packet injection does not scale and is
detectable. The proposed solution solves pervasive surveillance. That's the
goal.

I hear you loud and clear that you wish for a protocol where the SNI is
transmitted encrypted _and_ without the attacker
being able to reveal the SNI during an active attack. I'm certain that a
proposal by you of how to do this would be highly appreciated and
educational to the readers.

regards,

ralf



On Tue, Nov 12, 2013 at 6:50 PM, Martin Rex <mrex@sap.com> wrote:

> Daniel Kahn Gillmor wrote:
>
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
> [ Charset UTF-8 unsupported, converting... ]
> > On 11/12/2013 09:13 AM, Phillip Hallam-Baker wrote:
> > > What am I missing here, how do you turn on encryption before the client
> > > sees the encryption credential.
> >
> > e.g. using a PFS key exchange, you could include the SNI data after the
> > key negotiation, but before the server certificate. (i think this
> > introduces an extra round trip)
> >
> > > Sure you could soft encrypt under a non authenticated key, but that
> does
> > > not provide a lot of security.
> >
> > it provides confidentiality in the face of a passive attacker, which is
> > specifically what is being asked for.  I think it's clear that this
> > information is not possible to hide from an active attacker who is
> > willing to cause connection failures to find out the name of the server
> > the client is trying to reach.
>
> Browsers perform the reconnect fallback failures transparently and
> silently, and NSA hat their Foxacid servers in place to shoot down
> any TLSv1.3 requests they like with a TCP RST.
>
> A single connection failure per client&server pair per day would be
> sufficient to elicit cleartext SNIs from clients & cleartext certificates
> from servers.
>
> We should design our protocol to provide security in a robust and
> resilient fashion, not in a brittle "weather permitting" fashion
> that is being suggested.
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b2e0d1f911eb704eb004fcf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Martin,<br><br></div>I disagree.<=
br><br></div>1. The user can decide to force TLS 1.3<br></div>2. The attack=
 that you describe requires active packet injection. We just increased the =
cost for the attacker from passive recording of data to active packet injec=
tion. Active packet injection does not scale and is detectable. The propose=
d solution solves pervasive surveillance. That&#39;s the goal.<br>
<br></div>I hear you loud and clear that you wish for a protocol where the =
SNI is transmitted encrypted _and_ without the attacker<br>being able to re=
veal the SNI during an active attack. I&#39;m certain that a proposal by yo=
u of how to do this would be highly appreciated and educational to the read=
ers. <br>
<br></div>regards,<br><br>ralf<br><br></div><div class=3D"gmail_extra"><br>=
<br><div class=3D"gmail_quote">On Tue, Nov 12, 2013 at 6:50 PM, Martin Rex =
<span dir=3D"ltr">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mre=
x@sap.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Daniel Kahn Gillmor wrote:<br>
<br>
Checking application/pgp-signature: FAILURE<br>
-- Start of PGP signed section.<br>
[ Charset UTF-8 unsupported, converting... ]<br>
<div><div class=3D"h5">&gt; On 11/12/2013 09:13 AM, Phillip Hallam-Baker wr=
ote:<br>
&gt; &gt; What am I missing here, how do you turn on encryption before the =
client<br>
&gt; &gt; sees the encryption credential.<br>
&gt;<br>
&gt; e.g. using a PFS key exchange, you could include the SNI data after th=
e<br>
&gt; key negotiation, but before the server certificate. (i think this<br>
&gt; introduces an extra round trip)<br>
&gt;<br>
&gt; &gt; Sure you could soft encrypt under a non authenticated key, but th=
at does<br>
&gt; &gt; not provide a lot of security.<br>
&gt;<br>
&gt; it provides confidentiality in the face of a passive attacker, which i=
s<br>
&gt; specifically what is being asked for. =A0I think it&#39;s clear that t=
his<br>
&gt; information is not possible to hide from an active attacker who is<br>
&gt; willing to cause connection failures to find out the name of the serve=
r<br>
&gt; the client is trying to reach.<br>
<br>
</div></div>Browsers perform the reconnect fallback failures transparently =
and<br>
silently, and NSA hat their Foxacid servers in place to shoot down<br>
any TLSv1.3 requests they like with a TCP RST.<br>
<br>
A single connection failure per client&amp;server pair per day would be<br>
sufficient to elicit cleartext SNIs from clients &amp; cleartext certificat=
es<br>
from servers.<br>
<br>
We should design our protocol to provide security in a robust and<br>
resilient fashion, not in a brittle &quot;weather permitting&quot; fashion<=
br>
that is being suggested.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div>

--047d7b2e0d1f911eb704eb004fcf--

From nico@cryptonector.com  Tue Nov 12 13:06:39 2013
Return-Path: <nico@cryptonector.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 A0A5B11E80FC for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 13:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level: 
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 2Rme8pF1kX86 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 13:06:33 -0800 (PST)
Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id ABAFD11E810A for <tls@ietf.org>; Tue, 12 Nov 2013 13:06:27 -0800 (PST)
Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 4209A35007A for <tls@ietf.org>; Tue, 12 Nov 2013 13:06:27 -0800 (PST)
Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id B7A5235005B for <tls@ietf.org>; Tue, 12 Nov 2013 13:06:26 -0800 (PST)
Received: by mail-we0-f173.google.com with SMTP id u56so617851wes.32 for <tls@ietf.org>; Tue, 12 Nov 2013 13:06:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=heCghbzA1fD2AViGbWOEf7/61BnbBY1/BTEmn1OOuj4=; b=T3uaoheEoXliVOAsCxWF7GqqRgWNb96pPJF3X+vQL8IFNVVXBuVrR0Fn8f8umVpx6m gV6QW1ENyMCX4nYNKZBsjtzudtNNgyNS6XM7lkLJGxxX65cBkHfXB9iE8Axy1rhdL/+c HXWjbHN3kSSl7Gr6etksW4TXYsdxne2MeIRHCs79S/q/hjL37F8tTVxHgA1NlQrPBjBh K8xM5iIBhxVpYJkqf5hXt6SsUXFSXUmHyQrLDKJSYGzrOaEjFTSj+frDTW1K2aImS1QH buwuzIccKrkQmPpL1Vfc4a1BHspHGkKo+4R3iuL5ttzgyLRHWKhg3J6ZoFJzHgMZJLG/ 8cdw==
MIME-Version: 1.0
X-Received: by 10.180.184.112 with SMTP id et16mr18225183wic.4.1384290384870;  Tue, 12 Nov 2013 13:06:24 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Tue, 12 Nov 2013 13:06:24 -0800 (PST)
In-Reply-To: <20131111184748.F0D441AA74@ld9781.wdf.sap.corp>
References: <20131107213744.GQ18713@localhost> <20131111184748.F0D441AA74@ld9781.wdf.sap.corp>
Date: Tue, 12 Nov 2013 15:06:24 -0600
Message-ID: <CAK3OfOiAfX-JHwmBaLSP0RVQRQD8aMyZf4+r=m6hGa9KeGaOmw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary=001a11c2269aa80ec804eb0138a6
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Windows 2003 TLS 64 ciphersuite limit
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: Tue, 12 Nov 2013 21:06:39 -0000

--001a11c2269aa80ec804eb0138a6
Content-Type: text/plain; charset=UTF-8

On Monday, November 11, 2013, Martin Rex wrote:

> Nico Williams wrote:
> >
> > The Windows 2003 TLS stack (still used by a non-trivial number of
> > Microsoft Exchange SMTP servers) only looks at the first 64 elements
> > of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
> > it sometimes chooses 3DES (for which it misimplements CBC padding)
> > and fails during data transfer, or if that is suppressed or also
> > too far down the list, just fails the handshake.
>
> Is there any further information available of what exactly does not
> work with Windows 2003 3DES-CBC cipher suite?
>
> I see other TLS implementations interoperate just fine with
> Windows 2003 using the DES3-CBC-SHA TLS cipher suite.
>
> I do have installed the AES cipher suites update for schannel
> on my Windows 2003 machine, but there is no mentioning that
> it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.
>
>   http://support.microsoft.com/kb/948963

<http://support.microsoft.com/kb/948963>



Viktor and I conjecture that this is an example of an SSPI application that
doesn't handle variable padding cipher suites.  I.e., this is an example of
an SSPI app that would break (were it using GSS instead of TLS) if we add a
Kerberos enctype with variable padding.  Moreover, Microsoft could now
produce up some sample code demonstrating this so we know what to look for
when auditing apps, but anyways, if our conjecture is correct then MSFT
engineers are quite right to be uncomfortable about adding a variable
padding enctype.

For those of you not up on Kerberos, there is a proposal to add a new
"enctype" (cipher suite) with variable padding, and Microsoft engineers
have objected that this would break unspecified apps.  Since TLS, GSS,
NTLM, and SASL share roughly the same API in WIN32, the same API usage
pattern defect may well be at work in both, the Kerberos case and the TLS
case that Viktor noted in the note I forwarded to this list.  This may
constrain what new cipher suites are safe to use in Windows apps, but
because the negotiation is not dependent on a third party, it's mostly a
non-issue for TLS as long as there's a sufficiently strong ciphersuite with
desired properties and no variable padding for SSPI apps to pick.  For TLS
going forward this is a non-issue: all new ciphersuites will almost
certainly be stream ciphers or AEAD counter modes.

Forwarding this to KITTEN WG shortly.

Nico
--

--001a11c2269aa80ec804eb0138a6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, November 11, 2013, Martin Rex  wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">Nico Williams wrote:<br>
&gt;<br>
&gt; The Windows 2003 TLS stack (still used by a non-trivial number of<br>
&gt; Microsoft Exchange SMTP servers) only looks at the first 64 elements<b=
r>
&gt; of the cipherlist. =C2=A0If neither RC4-SHA nor RC4-MD5 are among thes=
e,<br>
&gt; it sometimes chooses 3DES (for which it misimplements CBC padding)<br>
&gt; and fails during data transfer, or if that is suppressed or also<br>
&gt; too far down the list, just fails the handshake.<br>
<br>
Is there any further information available of what exactly does not<br>
work with Windows 2003 3DES-CBC cipher suite?<br>
<br>
I see other TLS implementations interoperate just fine with<br>
Windows 2003 using the DES3-CBC-SHA TLS cipher suite.<br>
<br>
I do have installed the AES cipher suites update for schannel<br>
on my Windows 2003 machine, but there is no mentioning that<br>
it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.<br>
<br>
=C2=A0 <a href=3D"http://support.microsoft.com/kb/948963" target=3D"_blank"=
>http://support.microsoft.com/kb/948963</a></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<a href=3D"http://support.microsoft.com/kb/948963" target=3D"_blank"></a></=
blockquote><div><br></div><div><br></div><div>Viktor and I conjecture that =
this is an example of an SSPI application that doesn&#39;t handle variable =
padding cipher suites. =C2=A0I.e., this is an example of an SSPI app that w=
ould break (were it using GSS instead of TLS) if we add a Kerberos enctype =
with variable padding. =C2=A0Moreover, Microsoft could now produce up some =
sample code demonstrating this so we know what to look for when auditing ap=
ps, but anyways, if our conjecture is correct then MSFT engineers are quite=
 right to be uncomfortable about adding a variable padding enctype.</div>
<div><br></div><div>For those of you not up on Kerberos, there is a proposa=
l to add a new &quot;enctype&quot; (cipher suite) with variable padding, an=
d Microsoft engineers have objected that this would break unspecified apps.=
 =C2=A0Since TLS, GSS, NTLM, and SASL share roughly the same API in WIN32, =
the same API usage pattern defect may well=C2=A0be at work in both, the Ker=
beros case and the TLS case that Viktor noted in the note I forwarded to th=
is list. =C2=A0This may constrain what new cipher suites are safe to use in=
 Windows apps, but because the negotiation is not dependent on a third part=
y, it&#39;s mostly a non-issue for TLS as long as there&#39;s a sufficientl=
y strong ciphersuite with desired properties and no variable padding for SS=
PI apps to pick. =C2=A0For TLS going forward this is a non-issue: all new c=
iphersuites will almost certainly be stream ciphers or AEAD counter modes.<=
/div>
<div><br></div><div>Forwarding this to KITTEN WG shortly.</div><div><br></d=
iv><div>Nico</div><div>--=C2=A0</div>

--001a11c2269aa80ec804eb0138a6--

From ynir@checkpoint.com  Tue Nov 12 13:23:30 2013
Return-Path: <ynir@checkpoint.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 1DF1421E80CF for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 13:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.534
X-Spam-Level: 
X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 87lFA51X4Gpb for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 13:23:24 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4E19121E811E for <tls@ietf.org>; Tue, 12 Nov 2013 13:23:06 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rACLMkRt020239; Tue, 12 Nov 2013 23:22:46 +0200
X-CheckPoint: {52829A53-15-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 23:22:45 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<mrex@sap.com>" <mrex@sap.com>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cQ9VyMic6aPkyI1tVd5LOXZJobm1sAgAAiKgCABcwFgIAABBoAgABJS4CAACqCAA==
Date: Tue, 12 Nov 2013 21:22:45 +0000
Message-ID: <1891E14E-A9C7-47AE-A6E6-FF0C55713AEA@checkpoint.com>
References: <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
In-Reply-To: <20131112185035.EBB631AA80@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.68]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1488DE9AA94FE944AF57D03B4E131A7F@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
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: Tue, 12 Nov 2013 21:23:30 -0000

On Nov 12, 2013, at 8:50 PM, Martin Rex <mrex@sap.com> wrote:

> Daniel Kahn Gillmor wrote:
>=20
> Checking application/pgp-signature: FAILURE
> -- Start of PGP signed section.
> [ Charset UTF-8 unsupported, converting... ]
>> On 11/12/2013 09:13 AM, Phillip Hallam-Baker wrote:
>>> What am I missing here, how do you turn on encryption before the client
>>> sees the encryption credential.
>>=20
>> e.g. using a PFS key exchange, you could include the SNI data after the
>> key negotiation, but before the server certificate. (i think this
>> introduces an extra round trip)
>>=20
>>> Sure you could soft encrypt under a non authenticated key, but that doe=
s
>>> not provide a lot of security.
>>=20
>> it provides confidentiality in the face of a passive attacker, which is
>> specifically what is being asked for.  I think it's clear that this
>> information is not possible to hide from an active attacker who is
>> willing to cause connection failures to find out the name of the server
>> the client is trying to reach.
>=20
> Browsers perform the reconnect fallback failures transparently and
> silently, and NSA hat their Foxacid servers in place to shoot down
> any TLSv1.3 requests they like with a TCP RST.

I think it would actually be worse than that. Browsers don't want reconnect=
 fallback. So whatever TLS 1.3 looks like, the ClientHello that browsers se=
nd will be such that it can be accepted by at least TLS 1.0 servers (and th=
ere are plenty of those around). And as others have mentioned, SNI is neede=
d in many cases. Without it, https://www.gmail.com will give you a certific=
ate error.

So you might have a clientHello that leads to super-duper TLS 1.3, but to a=
void the need for fallback, you include the SNI (and presumably ALPN) in th=
e ClientHello.

When can we actually avoid having them in the ClientHello?  When servers wi=
thout TLS 1.3 become such a rarity, that browsers can take the cost of a fa=
llback every time they hit such a server. When will TLS 1.3 penetration rea=
ch 95%?

When can we actually remove fallback to <1.3 in our browsers?  When servers=
 without TLS 1.3 become such a rarity, that browsers can live with not supp=
orting those servers. That's pretty much where SSLv2 is, maybe SSLv3. When =
will TLS 1.3 penetration reach 99.9%?

Yoav


From mrex@sap.com  Tue Nov 12 13:41:31 2013
Return-Path: <mrex@sap.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 4CBE321F9FAE for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 13:41:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.18
X-Spam-Level: 
X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 5KhMF026ZVBe for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 13:41:27 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DB2CF21F9F7F for <tls@ietf.org>; Tue, 12 Nov 2013 13:41:26 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rACLfFI8020081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Nov 2013 22:41:15 +0100 (MET)
In-Reply-To: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Tue, 12 Nov 2013 22:41:15 +0100 (CET)
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: <20131112214115.9095A1AA81@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 12 Nov 2013 21:41:31 -0000

Ralf Skyper Kaiser wrote:
> 
> 1. The user can decide to force TLS 1.3

Dumping this kind of decision onto the user is going to make
things worse -- on average and in the long run.

(see also the findings in "Alice in Warningsland"
  http://www.cs.berkeley.edu/~devdatta/papers/alice-in-warningland.pdf


>
> 2. The attack that you describe requires active packet injection.  We just
> increased the cost for the attacker from passive recording of data to
> active packet injection. Active packet injection does not scale and is
> detectable. The proposed solution solves pervasive surveillance. That's the
> goal.

You're misrepresenting the issue.  For a passive observer, i.e. someone
watching the media where the connection data travels, inserting a
fake IP datagram with TCP RST in it is **TRIVIAL**, i.e. the cost is
infinitesimal close to zero.  A man-in-the-middle requirement would
be real cost, but we do not have that here.

We already *KNOW* that the FiveEyes folks doing the pervasive surveillance
have their active attack servers in place (Foxacid, Quantum, ...),
so you will actually obtain zero protection here.


> 
> I hear you loud and clear that you wish for a protocol where the SNI is
> transmitted encrypted _and_ without the attacker
> being able to reveal the SNI during an active attack. I'm certain that a
> proposal by you of how to do this would be highly appreciated and
> educational to the readers.

I never said that.

What you seem to be looking for is a protocol where an observer does not
know which parties are talking.  That will either require fully dynamic
addresses for both communication peers, pre-shared keys and out-of-band
protected&secure discovery where to find the dynamic address of the
communication acceptor.  Or require the use of a bunch of third parties
like a TOR network, which will hide who is talking to whom.


This is not something you can solve with a few tweaks of the TLS protocol.
And may get the consumers of TLS in big trouble if you continue boasting
that you could achieve this, because some might fall for this myth.


-Martin

From mrex@sap.com  Tue Nov 12 14:29:52 2013
Return-Path: <mrex@sap.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 AE1C411E8112 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 14:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.181
X-Spam-Level: 
X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 ZW2tZqLqzQIN for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 14:29:48 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2211E810B for <tls@ietf.org>; Tue, 12 Nov 2013 14:29:47 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rACMTiK5002702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Nov 2013 23:29:44 +0100 (MET)
In-Reply-To: <CAJU7zaLsJe-B3gOF9BrROKPeLSvbNdM9RzJgYxRAZtBWofc8ew@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Tue, 12 Nov 2013 23:29:44 +0100 (CET)
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: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 12 Nov 2013 22:29:52 -0000

Nikos Mavrogiannopoulos wrote:
> Martin Rex <mrex@sap.com> wrote:
>> Personally, I would really prefer to _not_ move the MAC outside
>> of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
>> originally recommended.  In particular, keeping the hands off the
>> GenericStreamCipher PDU processing.
> 
> I prefer this approach too, so I've taken the parts from the
> length-hiding draft and moved them to a draft that simply describes a
> new padding approach to solve the padding oracles. In any case I still
> believe that something needs to be done about that, whether it is
> pad-encrypt-then-mac or pad-mac-then-encrypt.
> 
> http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00

This is a whole new extension adding bells and whistles, not a fix to
any existing issues, and appears to be heading for TLSv1.2-only.

Padding with arbitrary length is something that every application
could do with every TLS implementation already in the installed base
and every existing cipher suite, no changes to TLS necessary,
requiring only minor changes of the application protocol.


I would really like to see a _simple_ TLS extension that fixes the two
CBC issues for the GenericBlockCipher PDU for *ALL* versions of TLS
including SSLv3, making _all_ protocol versions use the same
GenericblockCipher PDU format again (the way this should have been
done in 2003).


You proposal adds the padding at the beginning only.  Since the
problem exhibited by RC4 is inherent to any XOR-encryption with
a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
extension use random fraction, random content, authenticated padding
on both sides of the plaintext, with a combined minimum padding length of
at least 16 bytes, in order to mitigate statistical attacks on
any bias that may be found in the pseudo-random-pad.

But that is just an idea for what could be done if I had lots of free
time and nothing else important to do.


Seeing how slowly TLSv1.2(rfc5246) and TLS renegotiation extension (rfc5746)
are adopted by the installed base, I'm currently more interessted in
small changes and fixes to TLS that address real issues of the installed
base, such as interoperability problems (such as DHE parameter negotiation
and TLS protocol version intolerance and rsa premaster version goofs)
and weaknesses (published and unpublished).


-Martin

From mrex@sap.com  Tue Nov 12 16:29:29 2013
Return-Path: <mrex@sap.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 B3AB521E8122 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 16:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
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 H4DvQ5cJY+kr for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 16:29:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2B68A21E80F8 for <tls@ietf.org>; Tue, 12 Nov 2013 16:29:25 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAD0TNX3006685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Nov 2013 01:29:23 +0100 (MET)
In-Reply-To: <5EA9A50C-4AD0-43F6-B11D-2967C8CC0333@iki.fi>
To: =?UTF-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Wed, 13 Nov 2013 01:29:23 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20131113002923.829C71AA84@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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, 13 Nov 2013 00:29:29 -0000

Juho V=E4h=E4-Herttua wrote:
>=20
> mrex@sap.com (Martin Rex) wrote:
> >=20
> > Juho V=E4h=E4-Herttua wrote:
> >>=20
> >> What makes me sad is
> >> the knowledge that SNI is leaking the hostname and makes those
> >> connections trivial to block, even though I haven't come across
> >> SNI based blocking yet.
> >=20
> > There is _no_ requirement for the TLS client to send SNI at all.
>=20
> Of course not, but many servers require it in practice.

The number of servers that require SNI seems to be somewhere between
marginal and negligible.

SChannel in Windows XP doesn't support SNI, and the global market
share of Windows XP is still significant:
  http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=3D=
10&qpcustomd=3D0

(and may be the reason why MSIE 8 is still the most common version in use)

Sometimes, IT departments even deploy Windows 7 in a fashion that
even Win7 MSIE/SChannel will not send SNI.  I'm sure they would be
swamped with support calls if that would cause noticable usability issues.


>=20
> > In the normal mode of operation of TLS, the server name that the client
> > announces through SNI is the name that the client will match against
> > the server's certificate.  So blocking based on the names in the
> > server's certificate would work for current SSLv3->TLSv1.2, even
> > when the client does not send SNI.
>=20
> That is true, I assumed if there's a common shared secret for encrypting
> SNI in place, it could also be used for encrypting the certificate.

There are currently two other activities in the IETF with respect to
the server certificate: DANE, where the Server cert (hash) ends up
in DNS(SEC), and Certificate Transparency, where the Server's certificate
ends up on a signed public record.

And what about the Server certificate revocation checking through OCSP?


I assume that the primary reason for the NSA/GCHQ and spooky friends to
"collect it all" is the prevalent lack of "crypto hygiene" in pretty
much all network protocols and in common user behaviour,
except for some stuff that is run entirely through TOR.

You're leaking the information, that you're trying to hide here with great
effort, in so many other places, that they're going to laugh at you.

They may not be able to (or not care for) connecting the dots between
terrorist plots, but they likely can and do connect the dots between
IP addresses and hostnames of servers for stuff that doesn't go through TOR.


-Martin

From peter.sylvester@edelweb.fr  Wed Nov 13 01:41:40 2013
Return-Path: <peter.sylvester@edelweb.fr>
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 2966821E808D for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 01:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 TBnx0auHqDqM for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 01:41:35 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id A4BFB11E80E7 for <tls@ietf.org>; Wed, 13 Nov 2013 01:41:34 -0800 (PST)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 546F538002; Wed, 13 Nov 2013 10:35:47 +0100 (CET)
Received: from [127.0.0.1] (unknown [192.168.11.68]) by mx1.on-x.com (Postfix) with ESMTP id 97D6038001; Wed, 13 Nov 2013 10:35:46 +0100 (CET)
Message-ID: <52834946.3010002@edelweb.fr>
Date: Wed, 13 Nov 2013 10:41:26 +0100
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20131111202706.7522D1AA77@ld9781.wdf.sap.corp>
In-Reply-To: <20131111202706.7522D1AA77@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 certificate delegation?
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, 13 Nov 2013 09:41:40 -0000

On 11/11/2013 09:27 PM, Martin Rex wrote:
> Peter Sylvester wrote:
>>> Johannes Merkle wrote:
>>>> I think you are wrong: Section 7.4.2 of RFC 4346 states
>>>>
>>>>                                 Unless otherwise specified, the signing
>>>>         algorithm for the certificate MUST be the same as the algorithm
>>>>         for the certificate key.
>> Taking this out of context is not helpful
>> The specifications makes statements about what the sender has to
>> do, not what the receiver has to verify.
> The words in the TLS specification do not say who should to what.
> With your rationale, this is a mere prayer addressed at nobody.  :)
The spec doesn't say: "The client MUST reject the certficate message
if the  certficate signing algo is not the same as the algo for the signd key."

Among the 4 possibilities the MUST could apply, i.e.,

1 - to the sender AND the receiver
2 - to the sender only
3 - to the receiver only
4 - to nobody

at least 2 seems non controversal (the wording, not the
staement itsself!).

Concerning 1, As soon as a client can verify the signature
and can use the key, they accept the cert anyway as you say.

Other protocol texts have better wordings indicating
what a cerator must do and what a receiver must do.

The sentence about 'prayer' remains obscure to me.
"Wunschdenken" for whom?

Ok..
>
>
>>> The history of this obvious defect starts in rfc2246.
>>>
>>> There exists no such artificial limitation in SSLv3, and when I looked
>>> at implementations I've been using for interop testing a few
>>> years ago (Microsoft SChannel, OpenSSL, Firefox), they would
>>> happily interoperate with an RSA server cert signed by a CA with a
>>> DSA key.  To me it looks like most implementors were either not
>>> aware of this bogus, backwards-incompatible requirement,
>>> or they applied common sense and deliberately ignored it.
It ssems at least useful to me to distinguish client and server implementation.
Since in the above examples are clients, ok. They ignore it, and they can.
>> What is bogus in restricting a sender to be conservative?
>
> As if the _sender_ (implementation!!) had a choice.
One can now look whether the requirements are
useful for the sender.  As for the DSA/RSA combination,
the requirement doesn't seem necessary. well, some
implementation might not like SHAxxx in the CA signature.

>
> Which TLS implementations are prepared of handling two server certificates
> that differ only in the CAs signature algorithm (i.e. same server public
> key, same name attributes, same key usages)?
In which scenario you would need 2 certs if you follow
the requirement but only one if not?

Any logic for several does not create more difficulties than the
support for SNI. At least, one or more  callbacks that presents the more
or less interpreted client hello data (in a defined order)
to the application or to configuration module (as with mod_ssl)
of the application.
This in not rocket science, well, rocket science is still faster:-),
  and, as far as I can tell from the SNI experience, it is implementatable
with reasonable technical effort (opening the door to
a cathedral is another story).

>
> That would be bridging PKIs at the end-entity level.  I assume
> that bridging is normally done at the CA level.
If the signing algo of the cert differs, then I think the
CA key (DSA vs RSA for example) may be different.
I would think that different signing algorithm mean
different CA profiles.
>
>
> And how many real-world TLS servers are actually configured
> with such almost-twins server certificates?

Probably none, people keep asking me whether one needs
to support SSL V3.
At least with SNI, code in apache is there since 5 years.

>
> The vast majority of Web Servers have only a single server
> certificate, and those that have different certs, either
> have certificates ditinct by public key algorithm or distinct
> by (server)name.
>
I am lost.

I agree that we talk about one sentence

Unless otherwise specified, the signing
       algorithm for the certificate MUST be the same as the algorithm
       for the certificate key.


and I think that we also agree that the discussion can be
about the server only (since there is no restriction to the client
and clients may accept differences anyway.

What I was saying is only that if the server respects that, i.e.
there is only ONE algorithm. In reality, this does not apply
to the RSA/DSA combination because all clients support both.

Going back: If the servers wants to have two different types of
keys, it needs two certs?
I interate the advocatus diaboli argument: If you have two
value, you can fail for two reasons, if you have one, you *may*
have better chances.
Where does this requirement actually harm?
What are the possible errors:

Error message: "You server presents a certificate that we are
able to use but unfortunately, we cannot verify the certficate
because we do not have  the code to do verify the intermediate
certificate at level 42."

Hm, or was that to get rid of CA certs with MD5.

Best
/P

> -Martin


From benl@google.com  Wed Nov 13 04:36:08 2013
Return-Path: <benl@google.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 5A89211E8114 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 04:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dMxBnWreSeoF for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 04:36:07 -0800 (PST)
Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9C21E80C2 for <tls@ietf.org>; Wed, 13 Nov 2013 04:36:01 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id hz11so225789vcb.38 for <tls@ietf.org>; Wed, 13 Nov 2013 04:35:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8N/cZ+nzDV75vXP9ljN7YSWh4V7aOLrh5oq5wI3YvII=; b=U2z8/ZMUYWjpQh7NKvozYnbh3y2XphzCnZ6kNyZDhbp8B+WVQmcEjNTLWoulQUzBFx RctyeYdjh39oI9P0ggNyxtUC5AYjcK04kIZahFHfn6LGYpzMr37Uh+7gCdgP1p8Ks5kd j1ddmGpMCDx3/ova6RzD7rz2CLA5r2gwV+2K28yl6lLPH8VpQGXOwGwnuG5YkPzA+yqu cllZiP4AO4NVYUl16RXYT89c6tnj9VTOXgFVw8F8IwjYRKd6uoiZZl9aqs2jgCk1EoSQ c0cHh+qMdkPrEl9akz5fu1KcOJ3VD8Dc7aHEyrEqJd7CeM5JvGMEs5iW1tXZ4e5CK1Fu HXkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8N/cZ+nzDV75vXP9ljN7YSWh4V7aOLrh5oq5wI3YvII=; b=mf9hHKC7LloNfVrX5MByE4yPXQSuMAKnBu29SqTI89XKF2vjKg+75cLjmKpXRLiDkt ZmB/wb2onnjinw/3NqMMXwj0EJ5SEBJ5pTCHSW7pylfWgsUBbmmrV7XoM1Hn2ITmP9Pf QlOyL1QnL/OjKxlHA9qIW45LcOxn0tn5s+cXeIRuwXiT9UAd2BwD7KgBKOl8wJoj95GH o1Q15s0YZzxsFfzHK6d63L/BfY4VdWfml4hog3TjpN2MJAXg+qy5k8clZjOU+8qCtZ0Y N532zowwqzlyQRz2a2Y/hqPKEv6YcFDVU6hAoxho+ZgZjgt/teLysBwnZcbeYyZS0LhZ xo0w==
X-Gm-Message-State: ALoCoQm5YChcRshRB3aD3H8YG2V1+DnvxWh1anrEGMNCAf4e+IFX+6qUD1LEL0l932xxyZYTr4Xekv3WCmyjECqiVBByviw7AzWTE4CqM5LtSsNfbIwUm6bZcLH2JgHeciT7xSSDcWFF2pE56lKyTqNpNLNxfcNIP+5rbwjIQhrbISsEKHoR3ol7v5JasuS/S1qFce2/2cMO
MIME-Version: 1.0
X-Received: by 10.220.173.134 with SMTP id p6mr651115vcz.36.1384346154526; Wed, 13 Nov 2013 04:35:54 -0800 (PST)
Received: by 10.52.183.65 with HTTP; Wed, 13 Nov 2013 04:35:54 -0800 (PST)
In-Reply-To: <20131112165343.CA1101AA80@ld9781.wdf.sap.corp>
References: <CA+BZK2pu1F3zpRJNFX=QjFh=4JkooTgxkjDFPKBosnVCvuSonA@mail.gmail.com> <20131112165343.CA1101AA80@ld9781.wdf.sap.corp>
Date: Wed, 13 Nov 2013 12:35:54 +0000
Message-ID: <CABrd9STnQr95ri9EswXzLYurF81kvka7QHo=+8yuEe+oA2zLVQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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, 13 Nov 2013 12:36:08 -0000

On 12 November 2013 16:53, Martin Rex <mrex@sap.com> wrote:
> AEAD ciphers use XOR for encryption

Surely not by definition? It may be that the AEAD ciphers we use
currently use XOR, but we could create ones that don't, right?

From bryan@ravensight.org  Wed Nov 13 13:47:40 2013
Return-Path: <bryan@ravensight.org>
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 F120521E8160 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 13:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 y+5Vo0-tcc7g for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 13:47:34 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 28DA721E8104 for <tls@ietf.org>; Wed, 13 Nov 2013 13:47:33 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id uz6so1175012obc.40 for <tls@ietf.org>; Wed, 13 Nov 2013 13:47:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=Pe64U1aU39Jy3SIBvr5dg+j0g9APppQURk+3RSyd29g=; b=AQpCVyP4hBbblEAT2U/pySHWdJMtYVmuW3WrMA86KAjYpMJqJYrg4n/GmC/2wmjHF/ N43axOKR2SCwEOFzEPV9LkFAC/jOxcUdc4Yv4aM/SS6N0htLvi/UdnC42FKWTGJ5UoVN FLlz/cqpaz98iozWYQ/Wg59SgxycwMxU5W8a3mJDinsQlFeh6ancskROTdz+bOGzy28e 2kSHyzWr7MIxEzkG8aGyTLE4tU3J/UP6HyVCbyMTKakAa4NxUEsZJmwG2PnDEksM2XMY wbN9r0INSASaiXYpkAWLZOlsoTOEj6AidZ2yHxD/kvfZqdGUe/6w+XYce2gkjdEfwl0y ahXA==
X-Gm-Message-State: ALoCoQk0L8lASZ5+1ZL+PW2V5N5xYVqzAqYZ3DnP5gCicafDsGB49Ilx8iplom9YkrfnfIxfKvO9
X-Received: by 10.60.131.232 with SMTP id op8mr14495539oeb.75.1384379252443; Wed, 13 Nov 2013 13:47:32 -0800 (PST)
Received: from Genie (108-202-93-53.lightspeed.mssnks.sbcglobal.net. [108.202.93.53]) by mx.google.com with ESMTPSA id f2sm1500055oes.3.2013.11.13.13.47.31 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Nov 2013 13:47:31 -0800 (PST)
From: "Bryan C. Geraghty" <bryan@ravensight.org>
To: <mrex@sap.com>, "'Ralf Skyper Kaiser'" <skyper@thc.org>
References: <CA+BZK2pu1F3zpRJNFX=QjFh=4JkooTgxkjDFPKBosnVCvuSonA@mail.gmail.com> <20131112165343.CA1101AA80@ld9781.wdf.sap.corp>
In-Reply-To: <20131112165343.CA1101AA80@ld9781.wdf.sap.corp>
Date: Wed, 13 Nov 2013 15:47:49 -0600
Message-ID: <007d01cee0b9$ffbe8290$ff3b87b0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7fx8XH4QDYrsA3RHygm+svrEa6UAA8LVSQ
Content-Language: en-us
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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, 13 Nov 2013 21:47:40 -0000

Martin Rex wrote:

> Ralf Skyper Kaiser wrote:
>> 
>> Encrypt-then-mac has some other security benefits. (Among others that 
>> the decrypt routine never has to process bogus/bad messages [e.g. 
>> those where the MAC would fail in current encrypt-mac].).
> 
> Which benefits are this?
> 
> I am not aware of any security benefit for the real world from doing EtA
over AtE.

Look up "padding oracle attack". Lucky13 is a fairly recent example of a
real-world attack against AtE.
 
Bryan


From n.mavrogiannopoulos@gmail.com  Wed Nov 13 19:49:39 2013
Return-Path: <n.mavrogiannopoulos@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 D207721E8157 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 19:49:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 kMtzYuaqpDd3 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 19:49:39 -0800 (PST)
Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7D21E8121 for <tls@ietf.org>; Wed, 13 Nov 2013 19:49:38 -0800 (PST)
Received: by mail-ea0-f170.google.com with SMTP id q10so570768eaj.29 for <tls@ietf.org>; Wed, 13 Nov 2013 19:49:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=CRbRHGvy+1fjmM3KCXWzF2YsTlH5pI0LhCX052V2nlM=; b=qM7UpQhu4vS/sGz80E3okrpaRCfk66/lVazvORRxeoczzbCq2+j3I7LibIdkpQAUWL jhLCLuu6kFS65BradVOQd6/M2EV6Zq0FAwngbFGpJx1/T1b67Bp0tUIgfLmjcQ3zS/XY vmfDRZd6HExalpSxf1jTG1pQ/N5hozAFVMEmtGeN3dd4NLjVjijUdvOBSiabpC23FYKo mDniAPJ4XF8xHwZbt7+7pcvvoZqdH7z7009BR7L+RDHMhOBbyhT4xtxVtzk9F11sJ0K2 pdCCXuLX2EjHeNy5UNKnM9Qlmfe1GemmvIPDUqnc8zsIcpgtEDTmoEzW/Hvn92AsUWBH F2kQ==
X-Received: by 10.14.94.199 with SMTP id n47mr5231115eef.81.1384400977863; Wed, 13 Nov 2013 19:49:37 -0800 (PST)
Received: from [10.100.2.3] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id z2sm94999600eee.7.2013.11.13.19.49.36 for <multiple recipients> (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 13 Nov 2013 19:49:37 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <1384400970.2092.7.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: mrex@sap.com
Date: Thu, 14 Nov 2013 04:49:30 +0100
In-Reply-To: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp>
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.10.1 (3.10.1-1.fc20)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 03:49:39 -0000

On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
> Nikos Mavrogiannopoulos wrote:
> > Martin Rex <mrex@sap.com> wrote:
> >> Personally, I would really prefer to _not_ move the MAC outside
> >> of the encryption, i.e. leave it as pad-mac-encrypt like Serge Vaudenay
> >> originally recommended.  In particular, keeping the hands off the
> >> GenericStreamCipher PDU processing.
> > 
> > I prefer this approach too, so I've taken the parts from the
> > length-hiding draft and moved them to a draft that simply describes a
> > new padding approach to solve the padding oracles. In any case I still
> > believe that something needs to be done about that, whether it is
> > pad-encrypt-then-mac or pad-mac-then-encrypt.
> > 
> > http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00
> 
> This is a whole new extension adding bells and whistles, not a fix to
> any existing issues, and appears to be heading for TLSv1.2-only.
> Padding with arbitrary length is something that every application
> could do with every TLS implementation already in the installed base
> and every existing cipher suite, no changes to TLS necessary,
> requiring only minor changes of the application protocol.

There are two options. (a) Minor changes to the application protocol
(for all application protocols), or (b) minor changes to the TLS
protocol. The draft above takes the latter approach.

I also don't understand what do you mean by heading TLSv1.2-only. The
proposal in the above draft works from SSL 3.0 to TLS 1.2. There is
nothing TLS 1.2-specific there.

> You proposal adds the padding at the beginning only.  Since the
> problem exhibited by RC4 is inherent to any XOR-encryption with
> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
> extension use random fraction, random content, authenticated padding
> on both sides of the plaintext, with a combined minimum padding length of
> at least 16 bytes, in order to mitigate statistical attacks on
> any bias that may be found in the pseudo-random-pad.

The above draft does:
1. prevent padding oracle attacks
2. hide the length of the plaintext

What you propose there is having the plaintext appear and finish in an
unpredictable position. That's an interesting approach, not handled by
the draft above.

In simple terms you're asking for more bells and whistles :)

regards,
Nikos



From mike-list@pobox.com  Wed Nov 13 20:15:27 2013
Return-Path: <mike-list@pobox.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 A927821E80C6 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 zkIScdThBPBy for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:15:22 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id A6EB521E8085 for <tls@ietf.org>; Wed, 13 Nov 2013 20:15:22 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 35EBFDE27; Wed, 13 Nov 2013 23:15:20 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=GdAYsnjND/hM GsxDi6lfLJj1eFU=; b=FyXU1lHyEubhwS8Mp/Jendcc0PSBt6snLF7Z37bBCub5 6aKCdAKxYSFgndBWONdUGi8Lo3YUcM8bxj9Df9t0BVuK6p6WchJz5LDoWpjeUUvx cd+ziAY7IBjnCjaE9+mWnyrzBfvIiTcTrUCQy4d/rPgAlrUqo0Egfm0R3OY+KHc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=hYGsjR /cDuEL0YdrGkEcsj236TD33pHdx/CENstvAbAVCo9a0n6TaDdxwaMBi0PcVf4p7g 6Owh/tt4SfLO/d/Szupu4Ydz/zsNzYZf301NuWpuY4bI6NYdk2/4g+gmANwnBm9z c57QuIsO+BQP50VngYbNy0LEfOaHiFOe1RnYE=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2CDA9DE26; Wed, 13 Nov 2013 23:15:20 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 544E7DE23; Wed, 13 Nov 2013 23:15:17 -0500 (EST)
Message-ID: <52844E54.8000606@pobox.com>
Date: Wed, 13 Nov 2013 20:15:16 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp> <1384400970.2092.7.camel@aspire.lan>
In-Reply-To: <1384400970.2092.7.camel@aspire.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 5E60EAA0-4CE3-11E3-97A7-F66B0E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
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: Thu, 14 Nov 2013 04:15:27 -0000

Nikos Mavrogiannopoulos wrote:
> On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
>> You proposal adds the padding at the beginning only.  Since the
>> problem exhibited by RC4 is inherent to any XOR-encryption with
>> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
>> extension use random fraction, random content, authenticated padding
>> on both sides of the plaintext, with a combined minimum padding length of
>> at least 16 bytes, in order to mitigate statistical attacks on
>> any bias that may be found in the pseudo-random-pad.
> 
> The above draft does:
> 1. prevent padding oracle attacks
> 2. hide the length of the plaintext
> 
> What you propose there is having the plaintext appear and finish in an
> unpredictable position. That's an interesting approach, not handled by
> the draft above.
> 
> In simple terms you're asking for more bells and whistles :)

If I recall correctly from DJB's paper, the problem with RC4 is bias in
the first 256 or so bytes of the key stream.  Would it be possible to
"fix" RC4 using this extension?  Simply insert a random amount (at
least 256 bytes) of pseudo-random padding at the beginning of the first
record sent using an RC4 cipher suite?

Mike

From watsonbladd@gmail.com  Wed Nov 13 20:48:43 2013
Return-Path: <watsonbladd@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 B8A0921E81A2 for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.052,  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 Z6BUBJdTFJhs for <tls@ietfa.amsl.com>; Wed, 13 Nov 2013 20:48:43 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD221F9FF3 for <tls@ietf.org>; Wed, 13 Nov 2013 20:48:35 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id t61so1349739wes.30 for <tls@ietf.org>; Wed, 13 Nov 2013 20:48:35 -0800 (PST)
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=tUmOlXAFgPRPFTD/mSqhvTiJJ6j2S6f2cPlii33RKIY=; b=GvapaLSOCzJzPAPaC7/bT+OSMkV0sxSB41wLNqqgPduqdAhb3ylCYYWxlDi23rRcU4 2dmaFj19YQvbJ2lTgoAbPHHqnj6VS1UCxp+kak4QEZGh5Ny18ppnUDng7ZuBgN208kfG ynwHAG+FjMkrgFpoaCZ6x9LGOLk4KC+zXtN+sLrYqMIGnNTagPnSylYnJv6cYVIc3utu /A8HXUd81DNaOD96Ok7aMcl23p4w70Ip+NAkqZ3mQ2F3hdtruJ00kyiCdR3J10xTmrQr HIBfbmKw+dmdNod6ywfdMo1Q+GEcxYFWeKb8HsE87CSZAwVBrv3SfbJ4lFlMy0c251Z5 RsBw==
MIME-Version: 1.0
X-Received: by 10.180.78.132 with SMTP id b4mr459014wix.0.1384404515027; Wed, 13 Nov 2013 20:48:35 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Wed, 13 Nov 2013 20:48:34 -0800 (PST)
In-Reply-To: <52844E54.8000606@pobox.com>
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp> <1384400970.2092.7.camel@aspire.lan> <52844E54.8000606@pobox.com>
Date: Wed, 13 Nov 2013 20:48:34 -0800
Message-ID: <CACsn0c=d+tsDLcJFWpcDpbQdPRBNy3WERCQzepNWsyJfp2-cWA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
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: Thu, 14 Nov 2013 04:48:43 -0000

On Wed, Nov 13, 2013 at 8:15 PM, Michael D'Errico <mike-list@pobox.com> wrote:
> Nikos Mavrogiannopoulos wrote:
>>
>> On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
>>>
>>> You proposal adds the padding at the beginning only.  Since the
>>> problem exhibited by RC4 is inherent to any XOR-encryption with
>>> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
>>> extension use random fraction, random content, authenticated padding
>>> on both sides of the plaintext, with a combined minimum padding length of
>>> at least 16 bytes, in order to mitigate statistical attacks on
>>> any bias that may be found in the pseudo-random-pad.
>>
>>
>> The above draft does:
>> 1. prevent padding oracle attacks
>> 2. hide the length of the plaintext
>>
>> What you propose there is having the plaintext appear and finish in an
>> unpredictable position. That's an interesting approach, not handled by
>> the draft above.
>>
>> In simple terms you're asking for more bells and whistles :)
>
>
> If I recall correctly from DJB's paper, the problem with RC4 is bias in
> the first 256 or so bytes of the key stream.  Would it be possible to
> "fix" RC4 using this extension?  Simply insert a random amount (at
> least 256 bytes) of pseudo-random padding at the beginning of the first
> record sent using an RC4 cipher suite?
You recall incorrectly. The bias DJB et al. discovered was not the bias that
explains why RC4 should not be used: the Fluhrer-McGrew bias in all
bytes dooms RC4.

We have a perfectly good mode: AES-GCM. We should use it.
This whole topic is a waste of time: For a good stream cipher it does nothing,
for a bad stream cipher it also does nothing.

Let's talk about the real problems: slow deployment of TLS 1.2, Suite
B not being used extensively,
reducing round trips, lack of protection against downgrades, TCP shenanigans.
> Mike
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From Kenny.Paterson@rhul.ac.uk  Thu Nov 14 01:48:48 2013
Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 2BD2D21E8092 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 01:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
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 bUZUkSw+Xqpr for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 01:48:33 -0800 (PST)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8475521E81E2 for <tls@ietf.org>; Thu, 14 Nov 2013 01:48:31 -0800 (PST)
Received: from mail163-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE019.bigfish.com (10.174.4.82) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 09:48:30 +0000
Received: from mail163-db8 (localhost [127.0.0.1])	by mail163-db8-R.bigfish.com (Postfix) with ESMTP id EA24920402; Thu, 14 Nov 2013 09:48:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -12
X-BigFish: PS-12(z579ehzbb2dIdb82h98dI936eI1444M1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275bh1de097h186068h5eeeKz2dh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(377424004)(479174003)(243025003)(24454002)(51884002)(51704005)(81686001)(81342001)(561944002)(80976001)(74366001)(65816001)(80022001)(66066001)(19580395003)(83322001)(19580405001)(36756003)(63696002)(81542001)(83506001)(76176001)(74876001)(46102001)(15975445006)(4396001)(83072001)(51856001)(47736001)(54316002)(49866001)(47976001)(50986001)(74482001)(85306002)(87266001)(74662001)(31966008)(77096001)(56816003)(54356001)(47446002)(74502001)(56776001)(76482001)(81816001)(79102001)(53806001)(77982001)(59766001)(69226001)(74706001)(2656002)(76786001)(15202345003)(76796001)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277; H:AMXPR03MB277.eurprd03.prod.outlook.com; CLIP:80.42.233.244; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail163-db8 (localhost.localdomain [127.0.0.1]) by mail163-db8 (MessageSwitch) id 1384422485514938_13838; Thu, 14 Nov 2013 09:48:05 +0000 (UTC)
Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.236])	by mail163-db8.bigfish.com (Postfix) with ESMTP id 5DDB1B400A2; Thu, 14 Nov 2013 09:47:58 +0000 (UTC)
Received: from AM2PRD0311HT004.eurprd03.prod.outlook.com (157.56.249.149) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 09:47:58 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AM2PRD0311HT004.eurprd03.prod.outlook.com (10.255.162.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 09:47:47 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 09:47:47 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.247]) by AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.247]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 09:47:47 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Michael D'Errico <mike-list@pobox.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Thread-Topic: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
Thread-Index: AQHO4PAxMRQ/mzXm60e0wr02WrBPbZokez6A
Date: Thu, 14 Nov 2013 09:47:46 +0000
Message-ID: <CEAA4BE3.EE7B%kenny.paterson@rhul.ac.uk>
In-Reply-To: <52844E54.8000606@pobox.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.233.244]
x-forefront-prvs: 0030839EEE
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4EB9E47C9478214FAFAE0A6D83D7AFCD@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
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: Thu, 14 Nov 2013 09:48:48 -0000

On 14/11/2013 04:15, "Michael D'Errico" <mike-list@pobox.com> wrote:

>Nikos Mavrogiannopoulos wrote:
>> On Tue, 2013-11-12 at 23:29 +0100, Martin Rex wrote:
>>> You proposal adds the padding at the beginning only.  Since the
>>> problem exhibited by RC4 is inherent to any XOR-encryption with
>>> a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
>>> extension use random fraction, random content, authenticated padding
>>> on both sides of the plaintext, with a combined minimum padding length
>>>of
>>> at least 16 bytes, in order to mitigate statistical attacks on
>>> any bias that may be found in the pseudo-random-pad.
>>=20
>> The above draft does:
>> 1. prevent padding oracle attacks
>> 2. hide the length of the plaintext
>>=20
>> What you propose there is having the plaintext appear and finish in an
>> unpredictable position. That's an interesting approach, not handled by
>> the draft above.
>>=20
>> In simple terms you're asking for more bells and whistles :)
>
>If I recall correctly from DJB's paper, the problem with RC4 is bias in
>the first 256 or so bytes of the key stream.

You recall incorrectly. Re-read sections 4.2, 5.2, 5.3.3 and 7 of the
paper:

http://www.isg.rhul.ac.uk/tls/RC4biases.pdf


>Would it be possible to
>"fix" RC4 using this extension? Simply insert a random amount (at
>least 256 bytes) of pseudo-random padding at the beginning of the first
>record sent using an RC4 cipher suite?

No.

Please read Section 7 of the paper. This idea, and variants of it, are
specifically addressed and dismissed.

Regards,

Kenny



From n.mavrogiannopoulos@gmail.com  Thu Nov 14 01:52:15 2013
Return-Path: <n.mavrogiannopoulos@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 3E73621E81E2 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 01:52:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 F+xG5RCgiBVg for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 01:52:14 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 844EC21E8175 for <tls@ietf.org>; Thu, 14 Nov 2013 01:52:14 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id ep20so1325404lab.6 for <tls@ietf.org>; Thu, 14 Nov 2013 01:52:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9uY5in2ICez0RAYjUdRmobS/f8IrZADbhtihfE1AsVc=; b=nIaueCD89EP2EZPTCTq2LIjZyVJINEVgMDH42Aj0XFVltfHqSPS9s+Zd8FIBsbKj4j grfQYrLrTL8I7UwaAz7qAzcHzM4YX2gq2L4SbZe8mK8Sp8oHj/eOJi2kaxCCr62lo0IM ERxPGcz4zaSFcysc99zQSm7iPra/hB2/wU464llUOl5hYyJvIZPvgUB4u+bavcslr2MB gc7wPeJOC098JvMzm7RYt96LnVYJutfxf7jZSL0iUWU0cTpWNkqfHcklnK+fEMWKoq0k VnWShEbNrFsHeX+Lzb3ALnOa0szLo7vEQTPxVH9iaGs5kL2ElxUKKhKyTY4i2MMjOeoZ /9BA==
MIME-Version: 1.0
X-Received: by 10.152.4.230 with SMTP id n6mr292950lan.1.1384422733422; Thu, 14 Nov 2013 01:52:13 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Thu, 14 Nov 2013 01:52:13 -0800 (PST)
In-Reply-To: <52844E54.8000606@pobox.com>
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp> <1384400970.2092.7.camel@aspire.lan> <52844E54.8000606@pobox.com>
Date: Thu, 14 Nov 2013 10:52:13 +0100
X-Google-Sender-Auth: -E1R-DOR1Ta3L1bQYDN2jMlsjq0
Message-ID: <CAJU7zaJ6dho55VWAHQcyHhOqwpkDy+VzXUiquLqNZr2YSCM-Sw@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "Michael D'Errico" <mike-list@pobox.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
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: Thu, 14 Nov 2013 09:52:15 -0000

On Thu, Nov 14, 2013 at 5:15 AM, Michael D'Errico <mike-list@pobox.com> wrote:

>> The above draft does:
>> 1. prevent padding oracle attacks
>> 2. hide the length of the plaintext
>> What you propose there is having the plaintext appear and finish in an
>> unpredictable position. That's an interesting approach, not handled by
>> the draft above.
>>
>> In simple terms you're asking for more bells and whistles :)
> If I recall correctly from DJB's paper, the problem with RC4 is bias in
> the first 256 or so bytes of the key stream.  Would it be possible to
> "fix" RC4 using this extension?  Simply insert a random amount (at
> least 256 bytes) of pseudo-random padding at the beginning of the first
> record sent using an RC4 cipher suite?

Kenny answered on the question. However, even if it would solve it,
would it really be worth it to make hacks to save RC4?

regards,
Nikos

From jacob@appelbaum.net  Thu Nov 14 02:18:54 2013
Return-Path: <jacob@appelbaum.net>
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 1A4B921E81F7 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 02:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 FjJZRadFhrsv for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 02:18:49 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA0921E81DF for <tls@ietf.org>; Thu, 14 Nov 2013 02:18:43 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id x18so198827lbi.28 for <tls@ietf.org>; Thu, 14 Nov 2013 02:18:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=Qx5Y35fsVsgNCngJK0tJLeSICtTzpua48dic8ggpsEw=; b=S5kIYVLevJ3sqCoH2nZ5p2Lsk/zoUALp0nqtDHUCo+QFbs4wYAQmtc7FhDfcmydqpw wc+RJlXABjUfclJEN3eSyZnmTSn7Law0SbhVYwLo2QfIhVthYA6uwmL2jKG73krLxfLk sCRlRCSESYqrC49B7qhKdU0Mq+yEWsGHaoqm6RH5Miv+eFPFkMeQV6/Aouf4W9oNH/pg x/LoV7Ew3eoHBaNOMe8oNwwOddaumNwhVYkoTLQZsR5p5p+Bpt86Jm4qTeTJr3qlFr7O ES30bBSyUuTkTM0yyJZPF8Mc4eGttb4TK0St+cE+8xdXRw8v3XHl9F2QoZd9IPVbTMro 7sIQ==
X-Gm-Message-State: ALoCoQn82nleTNO2VbnafT7GNyVkLeoGtnfaxViH/Sf7/BqMGo6lQjGUJI23b6Wdj+Fh7jrt1oXJ
X-Received: by 10.152.8.199 with SMTP id t7mr267237laa.63.1384424318249; Thu, 14 Nov 2013 02:18:38 -0800 (PST)
Received: from 127.0.0.1 (exit1.ipredator.se. [194.132.32.42]) by mx.google.com with ESMTPSA id bf4sm5830563lbc.10.2013.11.14.02.18.35 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 02:18:37 -0800 (PST)
Message-ID: <5284A1A7.7010305@appelbaum.net>
Date: Thu, 14 Nov 2013 10:10:47 +0000
From: Jacob Appelbaum <jacob@appelbaum.net>
MIME-Version: 1.0
To: tls@ietf.org
References: <20131112222944.2B0FD1AA82@ld9781.wdf.sap.corp> <1384400970.2092.7.camel@aspire.lan> <52844E54.8000606@pobox.com> <CACsn0c=d+tsDLcJFWpcDpbQdPRBNy3WERCQzepNWsyJfp2-cWA@mail.gmail.com>
In-Reply-To: <CACsn0c=d+tsDLcJFWpcDpbQdPRBNy3WERCQzepNWsyJfp2-cWA@mail.gmail.com>
OpenPGP: id=4193A197
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Would this fix RC4 again? (was Re: Encrypt-then-MAC again (was Re: padding bug))
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: Thu, 14 Nov 2013 10:18:54 -0000

Watson Ladd:
> Suite B not being used extensively,

As a side note, they call it Suite B for a reason, no?

I think that agl's plan of "ChaCha20 and Poly1305 for TLS" is much better:

  https://www.imperialviolet.org/2013/10/07/chacha20.html

All the best,
Jacob

From mrex@sap.com  Thu Nov 14 07:05:42 2013
Return-Path: <mrex@sap.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 284CC11E8132 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 07:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.183
X-Spam-Level: 
X-Spam-Status: No, score=-10.183 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 8+426aJWvyld for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 07:05:36 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id F14A811E80F2 for <tls@ietf.org>; Thu, 14 Nov 2013 07:05:34 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAEF5VBl017782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 16:05:31 +0100 (MET)
In-Reply-To: <007d01cee0b9$ffbe8290$ff3b87b0$@org>
To: "Bryan C. Geraghty" <bryan@ravensight.org>
Date: Thu, 14 Nov 2013 16:05:31 +0100 (CET)
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: <20131114150531.66A001AA90@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 14 Nov 2013 15:05:42 -0000

Bryan C. Geraghty wrote:
> Martin Rex wrote:
> 
> > Ralf Skyper Kaiser wrote:
> >> 
> >> Encrypt-then-mac has some other security benefits. (Among others that 
> >> the decrypt routine never has to process bogus/bad messages [e.g. 
> >> those where the MAC would fail in current encrypt-mac].).
> > 
> > Which benefits are this?
> > 
> > I am not aware of any security benefit for the real world from doing EtA
> over AtE.
> 
> Look up "padding oracle attack". Lucky13 is a fairly recent example of a
> real-world attack against AtE.

You're mistaken.

The "padding oracle attacks" against CBC, both originally described
by Serge Vaudenay, and the attack described by Hugo, are against
"authenticate-extend-encrypt" schemes one of which being the
"mac-pad-encrypt" used by TLS.

I was asking for security benefits of a EtA over a _real_ AtE scheme, and
I am not aware of any.

-Martin

From skyper@thc.org  Thu Nov 14 07:47:20 2013
Return-Path: <skyper@thc.org>
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 39B5411E814F for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 07:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.357
X-Spam-Level: *
X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 jBXcphrD0l9E for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 07:47:15 -0800 (PST)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64611E8141 for <tls@ietf.org>; Thu, 14 Nov 2013 07:47:13 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id u16so2818947iet.20 for <tls@ietf.org>; Thu, 14 Nov 2013 07:47:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k7coAMSSKnMnacYyS2DiFkMgouHuu9SUc8SJuHwAuaY=; b=WmHtAcXbKut9XXxn7KifDKC9nwuuupVNhRkXXAZfkgDNnIZPe0x6kjJp0L6S8VnEBE 9e8EiP8AuFiOIxzYVajK8GgZAqXBjW+9h+t9tvfMuTPNgsipZx5J8wdtNRn9UTIcul36 ynoQDb7MCNt4uaQAWna7oyfB/n3StgOEndtg4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k7coAMSSKnMnacYyS2DiFkMgouHuu9SUc8SJuHwAuaY=; b=YIRXTQ/Ud7ZvzTWDGTYforgEz46DLK+c4j8+ZY5+5u/8ZUZIPpk3SAoTRNYJ0ERz+p WwBs4yRxNroX4CocKEZyRiUNT+ipWk19iqFqtF6hyZfGjuw+Zxf7l9sOGd4iUqLmi+QD WFQvA5WHtGZFDaofOepZJD44AigL3aoyEtX+b2YUz0HvhsaRhGiIoFOD4tG5SANjYt1D vG+AJpy0Nt+0tDPwwIQ4rYtX0ksXbugy8h5Qu/ctVsQssmOAqjEx5tDRRL6VKKEs2QMU aUp8HXh1yAqG11ltgUmmMqKmKlIKN66dzbFXH5TJd3uefiTaQa0AVYjNJuF3JyfP+b8u /GMg==
X-Gm-Message-State: ALoCoQlDY4Mn58DxgsHBxHKrEEsUv4EFQkC05tAFnWoQxOLpl8UcbTyfjU11vPTZeaYP2o9ecqzS
MIME-Version: 1.0
X-Received: by 10.50.6.99 with SMTP id z3mr1696519igz.27.1384444027988; Thu, 14 Nov 2013 07:47:07 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Thu, 14 Nov 2013 07:47:07 -0800 (PST)
X-Originating-IP: [86.152.141.101]
In-Reply-To: <20131114150531.66A001AA90@ld9781.wdf.sap.corp>
References: <007d01cee0b9$ffbe8290$ff3b87b0$@org> <20131114150531.66A001AA90@ld9781.wdf.sap.corp>
Date: Thu, 14 Nov 2013 15:47:07 +0000
Message-ID: <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=e89a8f3b9c2380053c04eb24fe4c
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 15:47:20 -0000

--e89a8f3b9c2380053c04eb24fe4c
Content-Type: text/plain; charset=ISO-8859-1

Hi Martin,

1. EtA discards a malicious packet earlier than AtE. This means the packet
is processed by less programm code and the attacker has less chance to
trigger a vulnerability in the program code (We are talking buffer overflow
[etc!] here as well and not just crypto-vulns).

2.With AtE there is a correlation between the MAC and the plaintext. This
turns any known-plaintext attack into a ciphertext only attack and you
should not have a correlation even if this correlation can not be exploited
today by public cryptanalytic means.

EtA is the conservative choice.

regards,

ralf




On Thu, Nov 14, 2013 at 3:05 PM, Martin Rex <mrex@sap.com> wrote:

> Bryan C. Geraghty wrote:
> > Martin Rex wrote:
> >
> > > Ralf Skyper Kaiser wrote:
> > >>
> > >> Encrypt-then-mac has some other security benefits. (Among others that
> > >> the decrypt routine never has to process bogus/bad messages [e.g.
> > >> those where the MAC would fail in current encrypt-mac].).
> > >
> > > Which benefits are this?
> > >
> > > I am not aware of any security benefit for the real world from doing
> EtA
> > over AtE.
> >
> > Look up "padding oracle attack". Lucky13 is a fairly recent example of a
> > real-world attack against AtE.
>
> You're mistaken.
>
> The "padding oracle attacks" against CBC, both originally described
> by Serge Vaudenay, and the attack described by Hugo, are against
> "authenticate-extend-encrypt" schemes one of which being the
> "mac-pad-encrypt" used by TLS.
>
> I was asking for security benefits of a EtA over a _real_ AtE scheme, and
> I am not aware of any.
>
> -Martin
>

--e89a8f3b9c2380053c04eb24fe4c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Hi Martin,<br><br></div>1. EtA discard=
s a malicious packet earlier than AtE. This means the packet is processed b=
y less programm code and the attacker has less chance to trigger a vulnerab=
ility in the program code (We are talking buffer overflow [etc!] here as we=
ll and not just crypto-vulns).<br>
<br></div>2.With AtE there is a correlation between the MAC and the plainte=
xt. This turns any known-plaintext attack into a ciphertext only attack and=
 you should not have a correlation even if this correlation can not be expl=
oited today by public cryptanalytic means.<br>
<br></div>EtA is the conservative choice.<br><br></div>regards,<br><br>ralf=
<br><div><div><br><br></div></div></div><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">On Thu, Nov 14, 2013 at 3:05 PM, Martin Rex <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sa=
p.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">Brya=
n C. Geraghty wrote:<br>
&gt; Martin Rex wrote:<br>
&gt;<br>
&gt; &gt; Ralf Skyper Kaiser wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Encrypt-then-mac has some other security benefits. (Among oth=
ers that<br>
&gt; &gt;&gt; the decrypt routine never has to process bogus/bad messages [=
e.g.<br>
&gt; &gt;&gt; those where the MAC would fail in current encrypt-mac].).<br>
&gt; &gt;<br>
&gt; &gt; Which benefits are this?<br>
&gt; &gt;<br>
&gt; &gt; I am not aware of any security benefit for the real world from do=
ing EtA<br>
&gt; over AtE.<br>
&gt;<br>
&gt; Look up &quot;padding oracle attack&quot;. Lucky13 is a fairly recent =
example of a<br>
&gt; real-world attack against AtE.<br>
<br>
</div></div>You&#39;re mistaken.<br>
<br>
The &quot;padding oracle attacks&quot; against CBC, both originally describ=
ed<br>
by Serge Vaudenay, and the attack described by Hugo, are against<br>
&quot;authenticate-extend-encrypt&quot; schemes one of which being the<br>
&quot;mac-pad-encrypt&quot; used by TLS.<br>
<br>
I was asking for security benefits of a EtA over a _real_ AtE scheme, and<b=
r>
I am not aware of any.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span></blockquote></div><br></div>

--e89a8f3b9c2380053c04eb24fe4c--

From Adam.Montville@cisecurity.org  Thu Nov 14 07:49:09 2013
Return-Path: <Adam.Montville@cisecurity.org>
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 1088B21F9B9F for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 07:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level: 
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, UNPARSEABLE_RELAY=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 mY+CaWsN1H5u for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 07:48:49 -0800 (PST)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.205]) by ietfa.amsl.com (Postfix) with ESMTP id 17C3721F99E9 for <tls@ietf.org>; Thu, 14 Nov 2013 07:48:48 -0800 (PST)
Received: from [216.82.242.179:57449] by server-13.bemta-8.messagelabs.com id A7/AC-01034-0E0F4825; Thu, 14 Nov 2013 15:48:48 +0000
X-Env-Sender: Adam.Montville@cisecurity.org
X-Msg-Ref: server-2.tower-86.messagelabs.com!1384444127!43713915!1
X-Originating-IP: [69.195.43.86]
X-StarScan-Received: 
X-StarScan-Version: 6.9.13; banners=cisecurity.org,-,-
X-VirusChecked: Checked
Received: (qmail 32107 invoked from network); 14 Nov 2013 15:48:48 -0000
Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-2.tower-86.messagelabs.com with AES128-SHA encrypted SMTP; 14 Nov 2013 15:48:48 -0000
Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 14 Nov 2013 10:47:29 -0500
From: Adam Montville <Adam.Montville@cisecurity.org>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Ciphersuite Recommendations
Thread-Index: Ac7hUPHwoYCAtMzWSWiPMOHA4gZ+ig==
Date: Thu, 14 Nov 2013 15:47:34 +0000
Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.252.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 15:49:09 -0000

Does anyone on this list have a pointer or two to good, reasonable ciphers=
uite rankings? =20

. . .

From n.mavrogiannopoulos@gmail.com  Thu Nov 14 08:00:21 2013
Return-Path: <n.mavrogiannopoulos@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 2A1C011E8184 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 r2EiiFss7DMg for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:00:20 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 502BE11E8176 for <tls@ietf.org>; Thu, 14 Nov 2013 08:00:20 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id ev20so1740218lab.39 for <tls@ietf.org>; Thu, 14 Nov 2013 08:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gNQmlhOVhNMQquwTuYvtgq2IVzvAnbnd8dBwVTpG6rI=; b=ak+izzG/p8SoTgisq2Mk2PlYanWErF01oPd4UTL9TwxGUypdsan3HWgiUa4qh9Wg9s Eqnhhwcapokjt3+3WfzwLEK1i43lE2hJXZPPtfKGGAU1bqNfXdw9T3ZFvv6Z4IOp14rS HV5XiBgw0E24b28b50KMhcPbnm5ICyGlUu0HFLbuJLRPTG67LIbFCEoYfNH/j1aJDdO0 TBRPKCVab1b3I7wFixNGz4Tite/wdAaRQ9fr87xTbe/YFU5zHF3x1y0IY5fQGLlv1yz7 LOjR3Qm22w8TcJ452Z2O9Vc22tsnsuOGfInfClrgdntLSrNK65JMB61PmOyuipu3IClC B3PA==
MIME-Version: 1.0
X-Received: by 10.112.144.105 with SMTP id sl9mr1181069lbb.37.1384444818816; Thu, 14 Nov 2013 08:00:18 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Thu, 14 Nov 2013 08:00:18 -0800 (PST)
In-Reply-To: <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com>
References: <007d01cee0b9$ffbe8290$ff3b87b0$@org> <20131114150531.66A001AA90@ld9781.wdf.sap.corp> <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com>
Date: Thu, 14 Nov 2013 17:00:18 +0100
X-Google-Sender-Auth: fS2gN0LOBNFycbrwyg1StpzTkHk
Message-ID: <CAJU7za+N3KU1Mhfi3oXaAZd2kkCQOW3a59ZBrfQhdtKzVqA-6g@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 16:00:21 -0000

On Thu, Nov 14, 2013 at 4:47 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:

> 1. EtA discards a malicious packet earlier than AtE. This means the packet
> is processed by less programm code and the attacker has less chance to
> trigger a vulnerability in the program code (We are talking buffer overflow
> [etc!] here as well and not just crypto-vulns).

This is an often repeated argument. How many of these attacks are we
currently seeing in TLS that doesn't use EtA? None. The difference in
processing is really negligible to be used in a serious attack.

> 2.With AtE there is a correlation between the MAC and the plaintext. This
> turns any known-plaintext attack into a ciphertext only attack and you
> should not have a correlation even if this correlation can not be exploited
> today by public cryptanalytic means.

I don't understand your point. How would they work when the MAC is encrypted?

Both EtA and AtE have weak points, depending what you trust more, the
cipher or the MAC. With EtA you need to trust the MAC as any attacker
has access to the MAC and the actual authenticated data (which is the
ciphertext).

regards,
Nikos

From skyper@thc.org  Thu Nov 14 08:05:23 2013
Return-Path: <skyper@thc.org>
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 E5B6B21E80EE for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.357
X-Spam-Level: *
X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 8bi9dZYfrvbM for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:05:18 -0800 (PST)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A0DBE21E80EC for <tls@ietf.org>; Thu, 14 Nov 2013 08:05:18 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id to1so3060287ieb.3 for <tls@ietf.org>; Thu, 14 Nov 2013 08:05:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FRzyi3i1z+lzecZQHMzxXUpIXQ2HzN1P5HiMH4Xkp+c=; b=MpVmAsG1V3yi5CWoSwlMQhitQAhncVet9jxHmHSAZEzKeUZl/qBtyw9BCDOSqP3jtN m/H8pGbKthMaiFAzF/isf/ewtSqXvYR4mE837R6QwEGd44mYyrdtNWkWLtDF40inAMM2 p5CGomLh1PQugU42iCa8O8m6vZ7s08v10n6HE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FRzyi3i1z+lzecZQHMzxXUpIXQ2HzN1P5HiMH4Xkp+c=; b=UPOKSxseLIuw1QNcUHYNvkmyFuG7mq2NRmKqW2JcxstJFi75eV1EtlqyBrQsqe4CtP 7HcYH77d8PL2VoAHIzWvKVbzAYaJjacNz6qBbEFk+HPOZ2yXTsl9pj4wNZGF5WuZhYAH Whwz6QNdsK9WhCGZn4jJc0Eccy5UPrYFK1oQAWmPHHLWL+kEDBkOWzzJ++VRRXT6DY8p l8Q7SUC1WfvY21pmBPf0rFtJl7CO/K0xrUHSEw2yEFpTDYbjWuR3Lyeh6gCI2TZk5y5H byUe9sPg1HTEyEp7/5r61xp8zOTK4MeVHPLkFgWMXTIYakO8WZp/DrggLDOOvUhEDd3m 0E2Q==
X-Gm-Message-State: ALoCoQlxjjzmgvlaQ3ciEcAncpkjIy19PmHJqqdgaMewXvE0HD50Ig8Waq1nxjVLLVUoD9OG/fX/
MIME-Version: 1.0
X-Received: by 10.50.6.99 with SMTP id z3mr1765140igz.27.1384445117742; Thu, 14 Nov 2013 08:05:17 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Thu, 14 Nov 2013 08:05:17 -0800 (PST)
X-Originating-IP: [86.152.141.101]
In-Reply-To: <CAJU7za+N3KU1Mhfi3oXaAZd2kkCQOW3a59ZBrfQhdtKzVqA-6g@mail.gmail.com>
References: <007d01cee0b9$ffbe8290$ff3b87b0$@org> <20131114150531.66A001AA90@ld9781.wdf.sap.corp> <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com> <CAJU7za+N3KU1Mhfi3oXaAZd2kkCQOW3a59ZBrfQhdtKzVqA-6g@mail.gmail.com>
Date: Thu, 14 Nov 2013 16:05:17 +0000
Message-ID: <CA+BZK2oDFw7dQfrf-GqXRnb6aTtEGek4j5gbBxmow6C7Wj60XA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: multipart/alternative; boundary=e89a8f3b9c23744a6f04eb253ff2
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 16:05:23 -0000

--e89a8f3b9c23744a6f04eb253ff2
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 14, 2013 at 4:00 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org>wrote:

> On Thu, Nov 14, 2013 at 4:47 PM, Ralf Skyper Kaiser <skyper@thc.org>
> wrote:
>
> > 1. EtA discards a malicious packet earlier than AtE. This means the
> packet
> > is processed by less programm code and the attacker has less chance to
> > trigger a vulnerability in the program code (We are talking buffer
> overflow
> > [etc!] here as well and not just crypto-vulns).
>
> This is an often repeated argument. How many of these attacks are we
> currently seeing in TLS that doesn't use EtA? None. The difference in
> processing is really negligible to be used in a serious attack.
>
> > 2.With AtE there is a correlation between the MAC and the plaintext. This
> > turns any known-plaintext attack into a ciphertext only attack and you
> > should not have a correlation even if this correlation can not be
> exploited
> > today by public cryptanalytic means.
>
> I don't understand your point. How would they work when the MAC is
> encrypted?
>
> Both EtA and AtE have weak points, depending what you trust more, the
> cipher or the MAC. With EtA you need to trust the MAC as any attacker
> has access to the MAC and the actual authenticated data (which is the
> ciphertext).
>
>
Program code:
With EtA you need to trust the MAC. With AtE you need to trust the cipher
_and_ the MAC.

Correlation with plaintext:
I do not understand your argument. With EtA there just is no correlation.
That's a good thing. Only with AtE there is (that's a bad thing).

regards,

ralf

regards,
> Nikos
>

--e89a8f3b9c23744a6f04eb253ff2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Nov 14, 2013 at 4:00 PM, Nikos Mavrogiannopoulos <span dir=3D"ltr">&lt;=
<a href=3D"mailto:nmav@gnutls.org" target=3D"_blank">nmav@gnutls.org</a>&gt=
;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Nov 14, 2013 at 4:=
47 PM, Ralf Skyper Kaiser &lt;<a href=3D"mailto:skyper@thc.org">skyper@thc.=
org</a>&gt; wrote:<br>

<br>
&gt; 1. EtA discards a malicious packet earlier than AtE. This means the pa=
cket<br>
&gt; is processed by less programm code and the attacker has less chance to=
<br>
&gt; trigger a vulnerability in the program code (We are talking buffer ove=
rflow<br>
&gt; [etc!] here as well and not just crypto-vulns).<br>
<br>
</div>This is an often repeated argument. How many of these attacks are we<=
br>
currently seeing in TLS that doesn&#39;t use EtA? None. The difference in<b=
r>
processing is really negligible to be used in a serious attack.<br>
<div class=3D"im"><br>
&gt; 2.With AtE there is a correlation between the MAC and the plaintext. T=
his<br>
&gt; turns any known-plaintext attack into a ciphertext only attack and you=
<br>
&gt; should not have a correlation even if this correlation can not be expl=
oited<br>
&gt; today by public cryptanalytic means.<br>
<br>
</div>I don&#39;t understand your point. How would they work when the MAC i=
s encrypted?<br>
<br>
Both EtA and AtE have weak points, depending what you trust more, the<br>
cipher or the MAC. With EtA you need to trust the MAC as any attacker<br>
has access to the MAC and the actual authenticated data (which is the<br>
ciphertext).<br>
<br></blockquote><div><br></div><div>Program code:<br></div><div>With EtA y=
ou need to trust the MAC. With AtE you need to trust the cipher _and_ the M=
AC. <br><br></div><div>Correlation with plaintext:<br></div><div>I do not u=
nderstand your argument. With EtA there just is no correlation. That&#39;s =
a good thing. Only with AtE there is (that&#39;s a bad thing).<br>
<br>regards,<br><br>ralf<br></div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
regards,<br>
Nikos<br>
</blockquote></div><br></div></div>

--e89a8f3b9c23744a6f04eb253ff2--

From mrex@sap.com  Thu Nov 14 08:08:41 2013
Return-Path: <mrex@sap.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 18CF721E80C7 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:08:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.184
X-Spam-Level: 
X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 vi24pnj2lpiO for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:08:15 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6521E8098 for <tls@ietf.org>; Thu, 14 Nov 2013 08:07:51 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAEG7fcP010067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 17:07:41 +0100 (MET)
In-Reply-To: <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Thu, 14 Nov 2013 17:07:41 +0100 (CET)
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: <20131114160741.C949D1AA90@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 14 Nov 2013 16:08:42 -0000

Ralf Skyper Kaiser wrote:
> 
> 1. EtA discards a malicious packet earlier than AtE. This means the packet
> is processed by less programm code and the attacker has less chance to
> trigger a vulnerability in the program code (We are talking buffer overflow
> [etc!] here as well and not just crypto-vulns).

This is completely irrelevant in the real world and for TLS specifically.
(it may be slightly different for DTLS).


> 
> 2.With AtE there is a correlation between the MAC and the plaintext. This
> turns any known-plaintext attack into a ciphertext only attack and you
> should not have a correlation even if this correlation can not be exploited
> today by public cryptanalytic means.

This is just wrong.

With AtE, the MAC is encrypted as well, and in the case of TLS, it is
not a simple hash on the plaintext, but an HMAC with a secret integrity
protection key.  There is nothing you can learn from an encrypted HMAC.

For EtA this is different.  You have the MAC in plain, you have all
the data that is MACed (the ciphertext) in plain, the only remaining
unknown is the key for the HMAC.  If there is a weakness in the
MAC scheme, this is where it could be attacked, if at all.


> 
> EtA is the conservative choice.

Nope, EtA is taking chances.

-Martin

From mrex@sap.com  Thu Nov 14 08:21:54 2013
Return-Path: <mrex@sap.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 4F2E321E8056 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.186
X-Spam-Level: 
X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 TrCWqWPJyqVM for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:21:49 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9930D11E80E3 for <tls@ietf.org>; Thu, 14 Nov 2013 08:21:49 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAEGLhMD027215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 17:21:43 +0100 (MET)
In-Reply-To: <CA+BZK2oDFw7dQfrf-GqXRnb6aTtEGek4j5gbBxmow6C7Wj60XA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Thu, 14 Nov 2013 17:21:43 +0100 (CET)
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: <20131114162143.4719D1AA90@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 14 Nov 2013 16:21:54 -0000

Ralf Skyper Kaiser wrote:
>
> With EtA you need to trust the MAC. With AtE you need to trust the cipher
> _and_ the MAC.

I believe you're confused.

The MAC provides integrity protection, the Encryption provides
confidentiality.  The quality of the MAC has exactly Zero impact
on the confidentiality provided by the Encryption.

For EtA, the characteristics&quality of the Cipher do not affect
(and therefore can not improve) the quality of the MAC scheme
at all.

For AtE, the characteristics&quality of the Cipher additionally
strengthen the quality of the MAC scheme, so weaknesses in the MAC
scheme do not immediately translate into a vulnerability.

Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
that does not have cryptographic hash properties (2nd paragraph Page 10):

  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

  GHASH is a keyed hash function but not, on its own, a cryptographic
  hash function. This Recommendation only approves GHASH for use within
  the context of GCM.

The use of GHASH without cryptographic protection would not be safe.


-Martin

From skyper@thc.org  Thu Nov 14 08:22:03 2013
Return-Path: <skyper@thc.org>
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 82CCB21E80E3 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.357
X-Spam-Level: *
X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
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 k8zfEFKWXHWS for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:21:59 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id CF84521E80C7 for <tls@ietf.org>; Thu, 14 Nov 2013 08:21:58 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id x13so2911407ief.21 for <tls@ietf.org>; Thu, 14 Nov 2013 08:21:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fax1PPm2Fusljivw4x8CUP4B09w5GnZBwpjWxip7Pmw=; b=blMn+PCsLh22bFLJ0J1U4H7WOZjEBB5zbqWCxd5FmLR3VZTSnRCHOWfKAyDo5P7sYB XjxZnjJpk9TW3FimCp1u+i2Idx0ccokC4PjCg2lzy+GI7WOmCmzi4bxSQKLKvgTYbB9h LWLnr1nhUXjUNYbzR+TE/Cxz1HPoSvSH4LLlY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fax1PPm2Fusljivw4x8CUP4B09w5GnZBwpjWxip7Pmw=; b=NTndRN5JuCLsLlt/VX/AQZolcp8Cg6YwA5ctK5VEA3CTQdyJ34p15MNMM55AqWEtxI f72DCTka4y1OdrGWnwEz06M06YZTU04YDZoiZ2WXptJ0/f2nSjdqcm8oxqYsVu0hDe70 dvUfz38XRbZx0SKevkompxft2wzW3mS2rov35EjDYjgDwAl3pT7sSbW3oitTgZFtM4RC 6ChcEOpPHscCO7eCMrjyAmv5sQT2mPwq2cpdIyDwzGg35Pw+ssCCut9ZCyk+aTxmaaLr CHWhW6qNgmH1sX/P4Ki1DsR6FNlDz4yoKNXoLULJyCtWNXbZQ6z77tm5UV9AtHk0FwY5 j8Qg==
X-Gm-Message-State: ALoCoQl0MEe4CcrmLnL/k8lZRDZ9M25r/W5X683t6AEkoGfV1dJgz3TVaGbLTqAATl/GB2m8OjZ6
MIME-Version: 1.0
X-Received: by 10.50.6.99 with SMTP id z3mr1829745igz.27.1384446118227; Thu, 14 Nov 2013 08:21:58 -0800 (PST)
Received: by 10.64.108.163 with HTTP; Thu, 14 Nov 2013 08:21:58 -0800 (PST)
X-Originating-IP: [86.152.141.101]
In-Reply-To: <20131114160741.C949D1AA90@ld9781.wdf.sap.corp>
References: <CA+BZK2pEVQY_MCU7x4ZW+UB8GDOz83sTZrmbyFdpzhrgz_t4PA@mail.gmail.com> <20131114160741.C949D1AA90@ld9781.wdf.sap.corp>
Date: Thu, 14 Nov 2013 16:21:58 +0000
Message-ID: <CA+BZK2podkAnXBN-od=tJo4_nXom4oRFdznWkrgzwmuvrpoWiA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary=e89a8f3b9c2316899904eb257bd3
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 16:22:03 -0000

--e89a8f3b9c2316899904eb257bd3
Content-Type: text/plain; charset=ISO-8859-1

Hi,

yes, your point on 2. is valid and I agree with it. AtE gives less option
to attack HMAC.

I'm a bit more conservative on 1. OpenSSH used to have the same 'we do not
care, not a lot of code is executed before auth anyway' and they learned
the hard way (pre-auth remote overflows because to much code was executed
before auth that could have been executed post-auth).

Writing vulnerability free source is hard. OpenBSD tried hard and failed
(2002).

Looks like we have to balance between trusting HMAC vs. trusting that the
decrypt-code is vulnerability-free.

regards,

ralf


On Thu, Nov 14, 2013 at 4:07 PM, Martin Rex <mrex@sap.com> wrote:

> Ralf Skyper Kaiser wrote:
> >
> > 1. EtA discards a malicious packet earlier than AtE. This means the
> packet
> > is processed by less programm code and the attacker has less chance to
> > trigger a vulnerability in the program code (We are talking buffer
> overflow
> > [etc!] here as well and not just crypto-vulns).
>
> This is completely irrelevant in the real world and for TLS specifically.
> (it may be slightly different for DTLS).
>
>
> >
> > 2.With AtE there is a correlation between the MAC and the plaintext. This
> > turns any known-plaintext attack into a ciphertext only attack and you
> > should not have a correlation even if this correlation can not be
> exploited
> > today by public cryptanalytic means.
>
> This is just wrong.
>
> With AtE, the MAC is encrypted as well, and in the case of TLS, it is
> not a simple hash on the plaintext, but an HMAC with a secret integrity
> protection key.  There is nothing you can learn from an encrypted HMAC.
>
> For EtA this is different.  You have the MAC in plain, you have all
> the data that is MACed (the ciphertext) in plain, the only remaining
> unknown is the key for the HMAC.  If there is a weakness in the
> MAC scheme, this is where it could be attacked, if at all.
>
>
> >
> > EtA is the conservative choice.
>
> Nope, EtA is taking chances.
>
> -Martin
>

--e89a8f3b9c2316899904eb257bd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Hi,<br><br></div><div class=3D"=
gmail_extra">yes, your point on 2. is valid and I agree with it. AtE gives =
less option to attack HMAC.<br><br></div><div class=3D"gmail_extra">I&#39;m=
 a bit more conservative on 1. OpenSSH used to have the same &#39;we do not=
 care, not a lot of code is executed before auth anyway&#39; and they learn=
ed the hard way (pre-auth remote overflows because to much code was execute=
d before auth that could have been executed post-auth).<br>
<br></div><div class=3D"gmail_extra">Writing vulnerability free source is h=
ard. OpenBSD tried hard and failed (2002).<br></div><div class=3D"gmail_ext=
ra"><br></div><div class=3D"gmail_extra">Looks like we have to balance betw=
een trusting HMAC vs. trusting that the decrypt-code is vulnerability-free.=
<br>
</div><div class=3D"gmail_extra"><br>regards,<br><br>ralf<br><br></div><div=
 class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">On Thu, Nov 14, 2013 at 4:07 PM, Martin Rex <span dir=3D"ltr">&=
lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">Ralf Skyper Kaiser wrote:<=
br>
&gt;<br>
&gt; 1. EtA discards a malicious packet earlier than AtE. This means the pa=
cket<br>
&gt; is processed by less programm code and the attacker has less chance to=
<br>
&gt; trigger a vulnerability in the program code (We are talking buffer ove=
rflow<br>
&gt; [etc!] here as well and not just crypto-vulns).<br>
<br>
</div>This is completely irrelevant in the real world and for TLS specifica=
lly.<br>
(it may be slightly different for DTLS).<br>
<div class=3D"im"><br>
<br>
&gt;<br>
&gt; 2.With AtE there is a correlation between the MAC and the plaintext. T=
his<br>
&gt; turns any known-plaintext attack into a ciphertext only attack and you=
<br>
&gt; should not have a correlation even if this correlation can not be expl=
oited<br>
&gt; today by public cryptanalytic means.<br>
<br>
</div>This is just wrong.<br>
<br>
With AtE, the MAC is encrypted as well, and in the case of TLS, it is<br>
not a simple hash on the plaintext, but an HMAC with a secret integrity<br>
protection key. =A0There is nothing you can learn from an encrypted HMAC.<b=
r>
<br>
For EtA this is different. =A0You have the MAC in plain, you have all<br>
the data that is MACed (the ciphertext) in plain, the only remaining<br>
unknown is the key for the HMAC. =A0If there is a weakness in the<br>
MAC scheme, this is where it could be attacked, if at all.<br>
<div class=3D"im"><br>
<br>
&gt;<br>
&gt; EtA is the conservative choice.<br>
<br>
</div>Nope, EtA is taking chances.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span></blockquote></div><br></div></div>

--e89a8f3b9c2316899904eb257bd3--

From tom@ritter.vg  Thu Nov 14 10:57:44 2013
Return-Path: <tom@ritter.vg>
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 AFBAF11E8163 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 10:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 cw2F8zSX89iL for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 10:57:43 -0800 (PST)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D178E11E815C for <tls@ietf.org>; Thu, 14 Nov 2013 10:57:43 -0800 (PST)
Received: by mail-pa0-f46.google.com with SMTP id rd3so2454688pab.19 for <tls@ietf.org>; Thu, 14 Nov 2013 10:57:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e0PfKVNI0W5A7BsLBYQaiFg2kW73qdbm+3MEdBuOVrY=; b=y8cyJt4reRHB4LJLgphtghNfmf4/D24XaomDkjOUKvyuACYKqjHWSctntBIi1TJDiD DG1BiZKAszqIDfzhv/dQwkoBtCwcCMTTfJLStjqkmMdOWngZ2ja11XPoCOBBi6HLgE+C SLS/jXlW/dzJB91yE5K672lwDULasqlFmLztY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=e0PfKVNI0W5A7BsLBYQaiFg2kW73qdbm+3MEdBuOVrY=; b=mmwSxCMiMeiDt1kZvPDNdiq8j9W3WfvENDcz9RwKAQ3Jggq0HEh7nbTfoXueOXj4lI bBXseLxAm2MVC7CWOPmE/MKbcDJyRyHcNKqCAPM8H6hK7O8/UiOe1Hsj7dGQxXlkstSZ kU2TfC1l3ctXCYeZYsw+Qheyt2TewChpCpXJnAIcJAaR3Sn7mWTvK/980ioV1F1zXCiZ rr3Ff01QfGEOCvJn2q1Ma/CKimdVlAKO8IEz+tyUCPj21RKkps745wCgDK9K4CO7dNG9 voSWFrvISaGaE/sP+Bq4o0IMOvjawdxCCaIGUidk0yUyv+l5cUApxZE/vy6CAZRrhw5W 3vLg==
X-Gm-Message-State: ALoCoQl+u4kf4Oj9/1tcV5gr1LvXlFob4KPOoMtBNbUil9jZFeVWSgY9PIdrAWrDw0DJ3kBFEtXS
MIME-Version: 1.0
X-Received: by 10.66.178.143 with SMTP id cy15mr2873446pac.105.1384455463620;  Thu, 14 Nov 2013 10:57:43 -0800 (PST)
Received: by 10.68.169.193 with HTTP; Thu, 14 Nov 2013 10:57:43 -0800 (PST)
Received: by 10.68.169.193 with HTTP; Thu, 14 Nov 2013 10:57:43 -0800 (PST)
In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local>
Date: Thu, 14 Nov 2013 13:57:43 -0500
Message-ID: <CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
To: Adam Montville <Adam.Montville@cisecurity.org>
Content-Type: multipart/alternative; boundary=047d7bdc93261dea9e04eb27a82c
Cc: tls@ietf.org
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 18:57:44 -0000

--047d7bdc93261dea9e04eb27a82c
Content-Type: text/plain; charset=ISO-8859-1

Is something like this what you're looking for?
https://wiki.mozilla.org/Security/Server_Side_TLS
On Nov 14, 2013 10:49 AM, "Adam Montville" <Adam.Montville@cisecurity.org>
wrote:

> Does anyone on this list have a pointer or two to good, reasonable
> ciphersuite rankings?
>
> . . .
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7bdc93261dea9e04eb27a82c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Is something like this what you&#39;re looking for?<br>
<a href=3D"https://wiki.mozilla.org/Security/Server_Side_TLS">https://wiki.=
mozilla.org/Security/Server_Side_TLS</a></p>
<div class=3D"gmail_quote">On Nov 14, 2013 10:49 AM, &quot;Adam Montville&q=
uot; &lt;<a href=3D"mailto:Adam.Montville@cisecurity.org">Adam.Montville@ci=
security.org</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
Does anyone on this list have a pointer or two to good, reasonable ciphersu=
ite rankings?<br>
<br>
. . .<br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</blockquote></div>

--047d7bdc93261dea9e04eb27a82c--

From ietf-ietf-tls@m.gmane.org  Thu Nov 14 12:28:53 2013
Return-Path: <ietf-ietf-tls@m.gmane.org>
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 CDD6421E80F1 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 vr27EEfmnNbB for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:28:48 -0800 (PST)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 7D03E21E811B for <tls@ietf.org>; Thu, 14 Nov 2013 12:28:43 -0800 (PST)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <ietf-ietf-tls@m.gmane.org>) id 1Vh3Wr-0001Tc-7l for tls@ietf.org; Thu, 14 Nov 2013 21:28:41 +0100
Received: from c-24-17-202-252.hsd1.wa.comcast.net ([24.17.202.252]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Thu, 14 Nov 2013 21:28:41 +0100
Received: from eternaleye by c-24-17-202-252.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Thu, 14 Nov 2013 21:28:41 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed <eternaleye@gmail.com>
Date: Thu, 14 Nov 2013 12:28:29 -0800
Lines: 44
Message-ID: <l63bp3$1op$1@ger.gmane.org>
References: <CA+BZK2oDFw7dQfrf-GqXRnb6aTtEGek4j5gbBxmow6C7Wj60XA@mail.gmail.com> <20131114162143.4719D1AA90@ld9781.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-24-17-202-252.hsd1.wa.comcast.net
User-Agent: KNode/4.11.1
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 20:28:54 -0000

Martin Rex wrote:

> Ralf Skyper Kaiser wrote:
>>
>> With EtA you need to trust the MAC. With AtE you need to trust the cipher
>> _and_ the MAC.
> 
> I believe you're confused.
> 
> The MAC provides integrity protection, the Encryption provides
> confidentiality.  The quality of the MAC has exactly Zero impact
> on the confidentiality provided by the Encryption.
> 
> For EtA, the characteristics&quality of the Cipher do not affect
> (and therefore can not improve) the quality of the MAC scheme
> at all.
> 
> For AtE, the characteristics&quality of the Cipher additionally
> strengthen the quality of the MAC scheme, so weaknesses in the MAC
> scheme do not immediately translate into a vulnerability.
> 
> Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
> that does not have cryptographic hash properties (2nd paragraph Page 10):
> 
>   http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
> 
>   GHASH is a keyed hash function but not, on its own, a cryptographic
>   hash function. This Recommendation only approves GHASH for use within
>   the context of GCM.
> 
> The use of GHASH without cryptographic protection would not be safe.
> 
> 
> -Martin

I think what Ralf meant was "the *implementation* of the $foo" - there _is_ 
a reduction of attack surface by ensuring that only the MAC could be exposed 
to forged content; however I would also agree that if your TLS 
implementation is vulnerable to buffer overflows in the cipher you have 
bigger problems. Like that you used such a thing in the first place.

OTOH, there may be an argument regarding performance and denial-of-service - 
by using EtA, forged messages can only force the target to spend cycles on 
the MAC, while AtE would permit a greater load to be imposed.


From Adam.Montville@cisecurity.org  Thu Nov 14 12:52:57 2013
Return-Path: <Adam.Montville@cisecurity.org>
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 9BB7F11E80FA for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.581
X-Spam-Level: 
X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 uGGIsNn6F1fi for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:52:53 -0800 (PST)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6411E8140 for <tls@ietf.org>; Thu, 14 Nov 2013 12:52:50 -0800 (PST)
Received: from [216.82.250.179:63254] by server-1.bemta-12.messagelabs.com id B8/BC-11895-FF735825; Thu, 14 Nov 2013 20:52:15 +0000
X-Env-Sender: Adam.Montville@cisecurity.org
X-Msg-Ref: server-14.tower-210.messagelabs.com!1384462333!8804613!2
X-Originating-IP: [69.195.43.86]
X-StarScan-Received: 
X-StarScan-Version: 6.9.13; banners=cisecurity.org,-,-
X-VirusChecked: Checked
Received: (qmail 10809 invoked from network); 14 Nov 2013 20:52:15 -0000
Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-14.tower-210.messagelabs.com with AES128-SHA encrypted SMTP; 14 Nov 2013 20:52:15 -0000
Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 14 Nov 2013 15:50:55 -0500
From: Adam Montville <Adam.Montville@cisecurity.org>
To: Tom Ritter <tom@ritter.vg>
Thread-Topic: [TLS] Ciphersuite Recommendations
Thread-Index: Ac7hUPHwoYCAtMzWSWiPMOHA4gZ+igARFzuAAAaC0bA=
Date: Thu, 14 Nov 2013 20:50:58 +0000
Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local> <CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com>
In-Reply-To: <CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.252.38]
Content-Type: multipart/alternative; boundary="_000_05BCCEB107AF88469B9F99783D47C1D6065CE3D2CISEXCHANGE1msi_"
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 20:52:57 -0000

--_000_05BCCEB107AF88469B9F99783D47C1D6065CE3D2CISEXCHANGE1msi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, that looks about right.

I was surprised, actually, that there was no IETF guidance available.

Anyone on this list think it's a good idea to provide some?  I do.



From: Tom Ritter [mailto:tom@ritter.vg]
Sent: Thursday, November 14, 2013 12:57 PM
To: Adam Montville
Cc: tls@ietf.org
Subject: Re: [TLS] Ciphersuite Recommendations


Is something like this what you're looking for?
https://wiki.mozilla.org/Security/Server_Side_TLS
On Nov 14, 2013 10:49 AM, "Adam Montville" <Adam.Montville@cisecurity.org<=
mailto:Adam.Montville@cisecurity.org>> wrote:
Does anyone on this list have a pointer or two to good, reasonable ciphers=
uite rankings?

. . .
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

...

. . .
--_000_05BCCEB107AF88469B9F99783D47C1D6065CE3D2CISEXCHANGE1msi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-mic=
rosoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word=
" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"ht=
tp://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii=
">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
=09{font-family:"Cambria Math";
=09panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
=09{font-family:Calibri;
=09panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
=09{margin:0in;
=09margin-bottom:.0001pt;
=09font-size:12.0pt;
=09font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
=09{mso-style-priority:99;
=09color:blue;
=09text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
=09{mso-style-priority:99;
=09color:purple;
=09text-decoration:underline;}
p
=09{mso-style-priority:99;
=09mso-margin-top-alt:auto;
=09margin-right:0in;
=09mso-margin-bottom-alt:auto;
=09margin-left:0in;
=09font-size:12.0pt;
=09font-family:"Times New Roman","serif";}
span.EmailStyle18
=09{mso-style-type:personal-reply;
=09font-family:"Calibri","sans-serif";
=09color:#1F497D;}
.MsoChpDefault
=09{mso-style-type:export-only;
=09font-family:"Calibri","sans-serif";}
@page WordSection1
=09{size:8.5in 11.0in;
=09margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
=09{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Yes, that looks about r=
ight.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">I was surprised, actual=
ly, that there was no IETF guidance available.&nbsp;
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Anyone on this list thi=
nk it&#8217;s a good idea to provide some?&nbsp; I do.<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span=
></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in=
 4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in=
 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quo=
t;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"fon=
t-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> Tom=
 Ritter [mailto:tom@ritter.vg]
<br>
<b>Sent:</b> Thursday, November 14, 2013 12:57 PM<br>
<b>To:</b> Adam Montville<br>
<b>Cc:</b> tls@ietf.org<br>
<b>Subject:</b> Re: [TLS] Ciphersuite Recommendations<o:p></o:p></span></p=
>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p>Is something like this what you're looking for?<br>
<a href=3D"https://wiki.mozilla.org/Security/Server_Side_TLS">https://wiki=
.mozilla.org/Security/Server_Side_TLS</a><o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On Nov 14, 2013 10:49 AM, &quot;Adam Montville&quot=
; &lt;<a href=3D"mailto:Adam.Montville@cisecurity.org">Adam.Montville@cise=
curity.org</a>&gt; wrote:<o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0=
in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class=3D"MsoNormal">Does anyone on this list have a pointer or two to g=
ood, reasonable ciphersuite rankings?<br>
<br>
. . .<br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/tls</a><o:p></o:p></p>
</blockquote>
</div>
<p class=3D"MsoNormal"><br>
...<o:p></o:p></p>
</div>
</div>
<br clear=3D"both">
. . .<BR>
</body>
</html>

--_000_05BCCEB107AF88469B9F99783D47C1D6065CE3D2CISEXCHANGE1msi_--

From stpeter@stpeter.im  Thu Nov 14 12:54:49 2013
Return-Path: <stpeter@stpeter.im>
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 689E911E810D for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.119
X-Spam-Level: 
X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100]
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 eODxf0R-MqOR for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:54:45 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4D25411E80FA for <tls@ietf.org>; Thu, 14 Nov 2013 12:54:45 -0800 (PST)
Received: from sjc-vpn3-631.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C9074010C; Thu, 14 Nov 2013 13:54:44 -0700 (MST)
Message-ID: <52853893.4020800@stpeter.im>
Date: Thu, 14 Nov 2013 13:54:43 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Adam Montville <Adam.Montville@cisecurity.org>, Tom Ritter <tom@ritter.vg>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local>	<CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com> <05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local>
In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 20:54:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/14/13 1:50 PM, Adam Montville wrote:
> Yes, that looks about right.
> 
> I was surprised, actually, that there was no IETF guidance
> available.
> 
> Anyone on this list think it?s a good idea to provide some?  I do.

Isn't that what
https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/ is doing, in part?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIbBAEBAgAGBQJShTiTAAoJEOoGpJErxa2pcEAP+IiZlt/5VWNeirM5DFiK74gm
MB24f0b65yctFqI5p3V0be2QaBtKmGAa7MZ7UNi8tz2N+vlt/t4EO/CeAVg3FokU
HzvErOflZrhP4KC7P8hoxthtXf95WPazsANt+qcfww5I+tVBsoaE3VSiokTXsAU8
ZowY5d9ZIAaNcggFOkw0NAVX7e1Fxrhac4fuvAvFJRyEI2RkeL68fPVueZ4Vc9c1
zrj1hVHAu5foAtaPkLRM3HIcsjaxNEzYKIs9mDyWXpK/RvW0JEDo4iA+XjGRsgxu
zlnmKdawMHP6ljPYWVmi+qmccuAWJ3GDigQQ/NG0umUkEVAys9RAnJGhfPpRFYri
i9KnIDcMe3RvXnmJkCuG3f9j9qBE19m6ucI+/gBuWGhBHNkzvq7HWNReWPW7szn+
I4JPwSOUnKw1K0xMm8+wH6KEmZLEb1ktrWthMJ3iXQTqHHXeCdbTcWkb46+TNiWA
VCWa9hPfj2edrYSzhP3x6JNVjx4i7vSz/XcBy6FpFMBNkBlVbDldyCoEms1Kn9F5
FF/9/fBdGLTuy2Bda7ORMRIsDpxZKfFx5ATBT4kmomwcm3Km0eSJEsC3V2VYmG8/
gxXTWYQf7OwrGGp03uK+MgMROHtouZ8yHVlKNmhmwfZwfvIgP6HhUlqdaFj4H438
ew5B6P3xOd5fBdzlHvI=
=q8GT
-----END PGP SIGNATURE-----

From yaronf.ietf@gmail.com  Thu Nov 14 12:57:06 2013
Return-Path: <yaronf.ietf@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 B48CA21F9AD5 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100]
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 wMMMMnGkOniM for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:57:04 -0800 (PST)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2F21F9B85 for <tls@ietf.org>; Thu, 14 Nov 2013 12:57:01 -0800 (PST)
Received: by mail-bk0-f50.google.com with SMTP id v16so1296084bkz.23 for <tls@ietf.org>; Thu, 14 Nov 2013 12:57:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gx+/+/4aCCjZgcF68Mrsr9enAiJIsplIjf+Su2WgrT4=; b=gmh5LBTOHGrk/20HsVNj8AyKYazYpmKRC5pqfIojwsqX0hhc0i5yr3z7WE0NmIwrxB Km1WW1qzifoIL5usbBey57/GzZblu2fW2p9H901hrrqC1RBrxiM4i/DvZbqcs4PW1OT5 MZn6JekfzpXdhAQ6fTO5rWmnuA2EH48IJj0IcKf2SOUiikO00W7QFjMxiVRn7v4GlaLn I3GoiD57eZClcsAYQvoy92dW71QDA5DUAxcXuHLm8IQmcz1xiR078rkuyv3aKeJ6XmZ4 ci4ITS21p7nzofHEbb2WW4E9clSu8oJMHcT37cU2LNZ6NDMLR/V1Ydvbgqw7mCv5J0nC vglQ==
X-Received: by 10.204.100.193 with SMTP id z1mr749759bkn.53.1384462621054; Thu, 14 Nov 2013 12:57:01 -0800 (PST)
Received: from [10.0.0.9] (bzq-79-182-173-156.red.bezeqint.net. [79.182.173.156]) by mx.google.com with ESMTPSA id on10sm4787022bkb.13.2013.11.14.12.56.59 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 12:57:00 -0800 (PST)
Message-ID: <5285391B.8030707@gmail.com>
Date: Thu, 14 Nov 2013 22:56:59 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>,  Adam Montville <Adam.Montville@cisecurity.org>, Tom Ritter <tom@ritter.vg>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local>	<CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com>	<05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local> <52853893.4020800@stpeter.im>
In-Reply-To: <52853893.4020800@stpeter.im>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 20:57:06 -0000

Yes, this is our intention.

Thanks,
	Yaron

On 11/14/2013 10:54 PM, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/14/13 1:50 PM, Adam Montville wrote:
>> Yes, that looks about right.
>>
>> I was surprised, actually, that there was no IETF guidance
>> available.
>>
>> Anyone on this list think it?s a good idea to provide some?  I do.
>
> Isn't that what
> https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/ is doing, in part?
>
> Peter
>

From Adam.Montville@cisecurity.org  Thu Nov 14 12:57:23 2013
Return-Path: <Adam.Montville@cisecurity.org>
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 CCE1721F9B9F for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:57:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.282
X-Spam-Level: 
X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, UNPARSEABLE_RELAY=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 ijIOrTuSwjeK for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:57:19 -0800 (PST)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.7]) by ietfa.amsl.com (Postfix) with ESMTP id BCB3C21F9AD5 for <tls@ietf.org>; Thu, 14 Nov 2013 12:57:19 -0800 (PST)
Received: from [216.82.250.19:4420] by server-7.bemta-12.messagelabs.com id 28/A7-06248-F2935825; Thu, 14 Nov 2013 20:57:19 +0000
X-Env-Sender: Adam.Montville@cisecurity.org
X-Msg-Ref: server-14.tower-87.messagelabs.com!1384462638!13021100!2
X-Originating-IP: [69.195.43.86]
X-StarScan-Received: 
X-StarScan-Version: 6.9.13; banners=cisecurity.org,-,-
X-VirusChecked: Checked
Received: (qmail 19836 invoked from network); 14 Nov 2013 20:57:19 -0000
Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-14.tower-87.messagelabs.com with AES128-SHA encrypted SMTP; 14 Nov 2013 20:57:19 -0000
Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 14 Nov 2013 15:55:59 -0500
From: Adam Montville <Adam.Montville@cisecurity.org>
To: Peter Saint-Andre <stpeter@stpeter.im>, Tom Ritter <tom@ritter.vg>
Thread-Topic: [TLS] Ciphersuite Recommendations
Thread-Index: Ac7hUPHwoYCAtMzWSWiPMOHA4gZ+igARFzuAAAaC0bD//+yZgIAAU6Xw
Date: Thu, 14 Nov 2013 20:56:03 +0000
Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065CE3F4@CISEXCHANGE1.msisac.org.local>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local> <CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com> <05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local> <52853893.4020800@stpeter.im>
In-Reply-To: <52853893.4020800@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.252.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 20:57:23 -0000

> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> Sent: Thursday, November 14, 2013 2:54 PM
> To: Adam Montville; Tom Ritter
> Cc: tls@ietf.org
> Subject: Re: [TLS] Ciphersuite Recommendations
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> On 11/14/13 1:50 PM, Adam Montville wrote:
> > Yes, that looks about right.
> >
> > I was surprised, actually, that there was no IETF guidance available.
> >
> > Anyone on this list think it?s a good idea to provide some?  I do.
>=20
> Isn't that what
> https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/ is doing, in par=
t?

It would appear so...thanks for pointing that out.  I communicated with a =
couple of others from this list who were not, apparently, aware of this wo=
rk.

>=20
> Peter
>=20
> - --
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>=20
> iQIbBAEBAgAGBQJShTiTAAoJEOoGpJErxa2pcEAP+IiZlt/5VWNeirM5DFiK74gm
> MB24f0b65yctFqI5p3V0be2QaBtKmGAa7MZ7UNi8tz2N+vlt/t4EO/CeAVg3Fok
> U
> HzvErOflZrhP4KC7P8hoxthtXf95WPazsANt+qcfww5I+tVBsoaE3VSiokTXsAU8
> ZowY5d9ZIAaNcggFOkw0NAVX7e1Fxrhac4fuvAvFJRyEI2RkeL68fPVueZ4Vc9c1
> zrj1hVHAu5foAtaPkLRM3HIcsjaxNEzYKIs9mDyWXpK/RvW0JEDo4iA+XjGRsgx
> u
> zlnmKdawMHP6ljPYWVmi+qmccuAWJ3GDigQQ/NG0umUkEVAys9RAnJGhfP
> pRFYri
> i9KnIDcMe3RvXnmJkCuG3f9j9qBE19m6ucI+/gBuWGhBHNkzvq7HWNReWPW
> 7szn+
> I4JPwSOUnKw1K0xMm8+wH6KEmZLEb1ktrWthMJ3iXQTqHHXeCdbTcWkb46
> +TNiWA
> VCWa9hPfj2edrYSzhP3x6JNVjx4i7vSz/XcBy6FpFMBNkBlVbDldyCoEms1Kn9F5
> FF/9/fBdGLTuy2Bda7ORMRIsDpxZKfFx5ATBT4kmomwcm3Km0eSJEsC3V2VY
> mG8/
> gxXTWYQf7OwrGGp03uK+MgMROHtouZ8yHVlKNmhmwfZwfvIgP6HhUlqdaF
> j4H438
> ew5B6P3xOd5fBdzlHvI=3D
> =3Dq8GT
> -----END PGP SIGNATURE-----
>=20
> ...

. . .

From Adam.Montville@cisecurity.org  Thu Nov 14 12:58:32 2013
Return-Path: <Adam.Montville@cisecurity.org>
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 2A07B21E80FE for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level: 
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, UNPARSEABLE_RELAY=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 6OUr-hK+8sy0 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 12:58:27 -0800 (PST)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.197]) by ietfa.amsl.com (Postfix) with ESMTP id 4756B21E80A8 for <tls@ietf.org>; Thu, 14 Nov 2013 12:58:27 -0800 (PST)
Received: from [216.82.241.211:24689] by server-5.bemta-8.messagelabs.com id 9F/31-00756-27935825; Thu, 14 Nov 2013 20:58:26 +0000
X-Env-Sender: Adam.Montville@cisecurity.org
X-Msg-Ref: server-16.tower-85.messagelabs.com!1384462706!24697188!2
X-Originating-IP: [69.195.43.86]
X-StarScan-Received: 
X-StarScan-Version: 6.9.13; banners=cisecurity.org,-,-
X-VirusChecked: Checked
Received: (qmail 18693 invoked from network); 14 Nov 2013 20:58:26 -0000
Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-16.tower-85.messagelabs.com with AES128-SHA encrypted SMTP; 14 Nov 2013 20:58:26 -0000
Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 14 Nov 2013 15:57:07 -0500
From: Adam Montville <Adam.Montville@cisecurity.org>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Peter Saint-Andre <stpeter@stpeter.im>, Tom Ritter <tom@ritter.vg>
Thread-Topic: [TLS] Ciphersuite Recommendations
Thread-Index: Ac7hUPHwoYCAtMzWSWiPMOHA4gZ+igARFzuAAAaC0bD//+yZgIAAAKOAgABTspA=
Date: Thu, 14 Nov 2013 20:57:11 +0000
Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065CE405@CISEXCHANGE1.msisac.org.local>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local> <CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com> <05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local> <52853893.4020800@stpeter.im> <5285391B.8030707@gmail.com>
In-Reply-To: <5285391B.8030707@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.252.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 20:58:32 -0000

> -----Original Message-----
> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> Sent: Thursday, November 14, 2013 2:56 PM
> To: Peter Saint-Andre; Adam Montville; Tom Ritter
> Cc: tls@ietf.org
> Subject: Re: [TLS] Ciphersuite Recommendations
>=20
> Yes, this is our intention.

For what it might be worth, I'll ask some of my constituents to review the=
 draft and provide usability feedback.  These are operator/administrators =
who would be asked to configure their systems in a secure manner.

>=20
> Thanks,
> =09Yaron
>=20
> On 11/14/2013 10:54 PM, Peter Saint-Andre wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 11/14/13 1:50 PM, Adam Montville wrote:
> >> Yes, that looks about right.
> >>
> >> I was surprised, actually, that there was no IETF guidance available.=

> >>
> >> Anyone on this list think it?s a good idea to provide some?  I do.
> >
> > Isn't that what
> > https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/ is doing, in p=
art?
> >
> > Peter
> >
>=20
> ...

. . .

From yaronf.ietf@gmail.com  Thu Nov 14 13:00:21 2013
Return-Path: <yaronf.ietf@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 6601411E8135 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 13:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100]
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 uQ52xb3Q5vBv for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 13:00:21 -0800 (PST)
Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AC58C11E810D for <tls@ietf.org>; Thu, 14 Nov 2013 13:00:20 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id d7so1310999bkh.17 for <tls@ietf.org>; Thu, 14 Nov 2013 13:00:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fbIK8ddPAP3oxM7lmD6aP1hOKeKLK/ctbruuBzvFPEA=; b=j7fiCVHpd/rl73Smdqrfm5IFsAUBcP7onspQxzqcNLcBdvFmfVFKsoqxrW7Cn3L0di 1uY6cDZChDgacLA2yLZLYRgnycBuzNsuOS8PP57esp4ulKLfr4R9GWe798dBDnGyIXLq 16Q9yt53R+93jo+yNYbqdZXprSCWsF/koGc+raTigLewYBNs1bCZ7xOGuAQOoQFLwjOH neH3KMToTAZnV6ONPb7AVU66rslzkiy0iZkglCjs/xH1AeP7ZERxbO+Dshk5n1wUtJUf cLBFgnBHehQY9wEZRChVfgJtOJzNGQ2vE/EQaQVI/2dE7+xQdadvdeMHPRo9QIjkwZef 6Q2g==
X-Received: by 10.205.33.197 with SMTP id sp5mr740089bkb.87.1384462817995; Thu, 14 Nov 2013 13:00:17 -0800 (PST)
Received: from [10.0.0.9] (bzq-79-182-173-156.red.bezeqint.net. [79.182.173.156]) by mx.google.com with ESMTPSA id on10sm4794928bkb.13.2013.11.14.13.00.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 13:00:17 -0800 (PST)
Message-ID: <528539E0.7050702@gmail.com>
Date: Thu, 14 Nov 2013 23:00:16 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Adam Montville <Adam.Montville@cisecurity.org>,  Peter Saint-Andre <stpeter@stpeter.im>, Tom Ritter <tom@ritter.vg>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local>	<CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com>	<05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local> <52853893.4020800@stpeter.im> <5285391B.8030707@gmail.com> <05BCCEB107AF88469B9F99783D47C1D6065CE405@CISEXCHANGE1.msisac.org.local>
In-Reply-To: <05BCCEB107AF88469B9F99783D47C1D6065CE405@CISEXCHANGE1.msisac.org.local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 21:00:21 -0000

I'd certainly appreciate such a review.

The document was presented at the recent meeting of the TLS working 
group, slides are here: 
https://tools.ietf.org/agenda/88/slides/slides-88-tls-0.pdf

Thanks,
	Yaron

On 11/14/2013 10:57 PM, Adam Montville wrote:
>
>
>> -----Original Message-----
>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
>> Sent: Thursday, November 14, 2013 2:56 PM
>> To: Peter Saint-Andre; Adam Montville; Tom Ritter
>> Cc: tls@ietf.org
>> Subject: Re: [TLS] Ciphersuite Recommendations
>>
>> Yes, this is our intention.
>
> For what it might be worth, I'll ask some of my constituents to review the draft and provide usability feedback.  These are operator/administrators who would be asked to configure their systems in a secure manner.
>
>>
>> Thanks,
>>        Yaron
>>
>> On 11/14/2013 10:54 PM, Peter Saint-Andre wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 11/14/13 1:50 PM, Adam Montville wrote:
>>>> Yes, that looks about right.
>>>>
>>>> I was surprised, actually, that there was no IETF guidance available.
>>>>
>>>> Anyone on this list think it?s a good idea to provide some?  I do.
>>>
>>> Isn't that what
>>> https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/ is doing, in part?
>>>
>>> Peter
>>>
>>
>> ...
> This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
>
> . . .
>

From maray@microsoft.com  Thu Nov 14 13:00:38 2013
Return-Path: <maray@microsoft.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 2343911E8162 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 13:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Is2paLao5Bun for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 13:00:32 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4562011E80FA for <tls@ietf.org>; Thu, 14 Nov 2013 13:00:28 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 21:00:25 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 21:00:25 +0000
From: Marsh Ray <maray@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTg==
Date: Thu, 14 Nov 2013 21:00:25 +0000
Message-ID: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ee31::2]
x-forefront-prvs: 0030839EEE
x-forefront-antispam-report: SFV:NSPM; SFS:(52604005)(199002)(189002)(81342001)(2656002)(51856001)(87936001)(33646001)(87266001)(81542001)(74706001)(59766001)(74876001)(19580395003)(83322001)(54356001)(80976001)(53806001)(77982001)(19609705001)(15202345003)(85306002)(15975445006)(65816001)(76482001)(49866001)(63696002)(80022001)(83072001)(47446002)(79102001)(16236675002)(19300405004)(56776001)(74366001)(81816001)(31966008)(74502001)(4396001)(81686001)(47976001)(47736001)(74662001)(76176001)(69226001)(50986001)(54316002)(46102001)(77096001)(56816003)(76796001)(76786001)(76576001)(74316001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_c8943847aecd44c29540bd198794746bBY2PR03MB074namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Thu, 14 Nov 2013 21:00:38 -0000

--_000_c8943847aecd44c29540bd198794746bBY2PR03MB074namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Our knowledge of generic hashing constructions has evolved:

A.      Standard constructions

B.      Length extension attacks

C.      Joux multicollisions/"2nd preimages for less work"

D.      Chosen-Target Forced-Prefix (Nostradamus, RapidSSL, Flame)

E.       Sponge constructions

Attacks against specific hashes (MD4, MD5, SHA-0, SHA-1, SHA-2) tend to unf=
old in sequence:

1.       Reduced round collisions demonstrated (depends on reduction)

2.       Absurdly impractical multicollision and/or collision weakness theo=
rized

3.       Plausible multicollision and/or collision weakness theorized

4.       Full collision demonstrated

5.       CTFP demonstrated

6.       2nd preimage theorized

7.       2nd preimage attack demonstrated

8.       Primary preimage attacks demonstrated

The last I heard:
MD4 is at stage 6
MD5 is at stage 5
SHA-0 was withdrawn at stage 3 or 4
SHA-1 is at stage 3
SHA-2 is at stage 2

Now let's talk about HMAC.

HMAC uses a double invocation of the full hash function each of which is in=
itialized with a secret key. There's some pretty well respected proven prop=
erties on the security of HMAC. For example, assuming the key is actually s=
ecret from the attacker, you generally don't need to worry about collision =
attacks. The resulting MAC value or tag can be truncated and yet it still r=
etains min(secret key bits, tag bits) security.

In TLS, the secret key is generated by the TLS PRF. The TLS PRF is one of t=
he most conservative parts of the design of TLS. It itself uses HMAC recurs=
ively. IIRC, to produce one block of PRF output takes something like 4 invo=
cations of the underlying hash's block function. It functions much like a s=
low, conservative block cipher with 512+160 bits of key and secret plaintex=
t input (512+1024 for SHA-2-384 and -512).

So the concern (C) has been raised that an attacker who may know some plain=
text, and sees one or more samples of ciphertext, and the non-truncated MAC=
 tag around this ciphertext, may then be able to "reach back through" the H=
MAC to obtain the MAC key. This would enable him to forge ciphertext, which=
 would enable him to and flip various bits decrypted plaintext bits. (Of co=
urse the current design allows anyone to do this today it's just that the l=
ater MAC will detect it so it becomes a game of oracle testing).

Additionally, the concern (D) is raised that an attacker who completely suc=
ceeds with (C) may then be able to "reach back through" several additional =
layers of HMAC in the TLS PRF in order to derive one or both of the cipher =
keys allowing full decryption of the protocol stream.

To be clear, I say "reach back through" because I don't think there is actu=
ally a name for this attack model. Even if we were just talking about a has=
h function instead of HMAC, this is an attack capability *beyond* primary p=
reimage. Primary preimage is "given h(M), find M' such that h(M') =3D h(M)"=
, whereas this attack is: "given h(M), find M"!

In other words, the attacker doesn't get to control the message input. Such=
 a feat has never been openly proposed in the literature (that I've seen on=
 hash functions), not even theorized, not even for MD4.

But again, our scenario (C) is not the use of plain hash functions. We're t=
alking about attacking the use of HMAC<Hfn>(k, msg) to recover the secret k=
ey bits of input. This is yet another step removed from "unthinkable".

In the case where that the secret key length is the same as the MAC length,=
 there's even about a coin toss chance there will be two or more keys that =
yield the target hash MAC. When the MAC is truncated, there are exponential=
ly more.

But again, for the concern (D), we're talking about accomplishing (C) and t=
hen continuing on to attack the TLS PRF through several cascaded HMAC<Hfn>(=
k, msg) to recover the secret key bits of input. This is yet another step r=
emoved from "unthinkable".

My conclusion is that for any reasonable choice of hash function, the TLS P=
RF is noninvertible. To put this another way, if this feat were demonstrate=
d even using the horribly broken MD5 it would be earth-shattering in its cr=
ypto impact. It is secure forever, unless there are seriously fundamental a=
dvances in complexity-theoretic cryptanalysis. And if that day comes, *it w=
ill be your fast ciphers that you'll worry about*. The TLS PRF is by far th=
e slowest, most conservatively designed stream cipher in common use.

I would never say something is "impossible" in cryptanalysis. We should alw=
ays be vigilant and paranoid. But the key to being *constructively paranoid=
* is to worry about the *right* thing. The security of HMAC<modern hash>(se=
cret k, message) is *not* the right to worry about.

The thing to worry about is block cipher modes' propensity to turn into pla=
intext oracles. This has been demonstrated as a practical attack on over an=
d over again.

*** RECOMMENDATIONS ***

* Put TLS PRF and HMAC security way, way down if not last on the list of th=
ings likely to negatively affect security.

For all future TLS cipher suites and TLS 1.3 in general is:

* Use encrypt-then-HMAC. Seriously. Yes really. No other choice is defensib=
le in this age. If you think "oh but GCM" look more closely into its design=
.

* Use the NIST-specified truncation SHA-2-512/256 for the HMAC hash functio=
n.
* Don't truncate the TLS record MAC in an attempt to protect the master sec=
ret (as in the Finished message). Even if such an attack were practical, th=
e attacker sees many samples of the MAC any way.

* Do truncate the TLS record MAC to 128 bits because anything more is an in=
defensible waste of bandwidth.

* Don't panic.

Thanks for reading this far. I'm fallible. TIA for details, factual correct=
ions, and flames. These are my own personal opinions and not necessarily th=
ose of my employer.


-          Marsh


--_000_c8943847aecd44c29540bd198794746bBY2PR03MB074namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.hoenzb
	{mso-style-name:hoenzb;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:99381235;
	mso-list-type:hybrid;
	mso-list-template-ids:395339308 67698709 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-number-format:alpha-upper;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l1
	{mso-list-id:732460728;
	mso-list-type:hybrid;
	mso-list-template-ids:1079123816 235600390 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l1:level1
	{mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l1:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l1:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l1:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l2
	{mso-list-id:1651203388;
	mso-list-type:hybrid;
	mso-list-template-ids:925159714 -1289033312 67698691 67698693 67698689 676=
98691 67698693 67698689 67698691 67698693;}
@list l2:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l2:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l2:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l2:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l2:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l2:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l2:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l2:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l2:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l3
	{mso-list-id:1861967860;
	mso-list-type:hybrid;
	mso-list-template-ids:436499666 1395396848 67698691 67698693 67698689 6769=
8691 67698693 67698689 67698691 67698693;}
@list l3:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l3:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l3:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l3:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l3:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l3:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l3:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l3:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l3:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l4
	{mso-list-id:1910144269;
	mso-list-type:hybrid;
	mso-list-template-ids:-1005419320 67698703 67698713 67698715 67698703 6769=
8713 67698715 67698703 67698713 67698715;}
@list l4:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l4:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l4:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l4:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Our knowledge of generic =
hashing constructions has evolved:<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">A.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Standard construc=
tions<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">B.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Length extension =
attacks<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">C.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Joux multicollisi=
ons/&#8221;2<sup>nd</sup> preimages for less work&#8221;<o:p></o:p></span><=
/p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">D.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Chosen-Target For=
ced-Prefix (Nostradamus, RapidSSL, Flame)<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo2"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">E.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Sponge constructi=
ons<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Attacks against specific =
hashes (MD4, MD5, SHA-0, SHA-1, SHA-2) tend to unfold in sequence:<o:p></o:=
p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">1.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Reduced round col=
lisions demonstrated (depends on reduction)<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">2.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Absurdly impracti=
cal multicollision and/or collision weakness theorized<o:p></o:p></span></p=
>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">3.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Plausible multico=
llision and/or collision weakness theorized<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">4.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Full collision de=
monstrated<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">5.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">CTFP demonstrated=
<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">6.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">2<sup>nd</sup> pr=
eimage theorized<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">7.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">2<sup>nd</sup> pr=
eimage attack demonstrated<o:p></o:p></span></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l4 level=
1 lfo1"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">8.<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Primary preimage =
attacks demonstrated<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The last I heard:<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">MD4 is at stage 6<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">MD5 is at stage 5<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">SHA-0 was withdrawn at st=
age 3 or 4<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">SHA-1 is at stage 3<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">SHA-2 is at stage 2<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Now let&#8217;s talk abou=
t HMAC.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">HMAC uses a double invoca=
tion of the full hash function each of which is initialized with a secret k=
ey. There&#8217;s some pretty well respected proven properties
 on the security of HMAC. For example, assuming the key is actually secret =
from the attacker, you generally don&#8217;t need to worry about collision =
attacks. The resulting MAC value or tag can be truncated and yet it still r=
etains min(secret key bits, tag bits)
 security.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In TLS, the secret key is=
 generated by the TLS PRF. The TLS PRF is one of the most conservative part=
s of the design of TLS. It itself uses HMAC recursively.
 IIRC, to produce one block of PRF output takes something like 4 invocation=
s of the underlying hash&#8217;s block function. It functions much like a s=
low, conservative block cipher with 512&#43;160 bits of key and secret plai=
ntext input (512&#43;1024 for SHA-2-384 and -512).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">So the concern (C) has be=
en raised that an attacker who may know some plaintext, and sees one or mor=
e samples of ciphertext, and the non-truncated MAC tag around
 this ciphertext, may then be able to &#8220;reach back through&#8221; the =
HMAC to obtain the MAC key. This would enable him to forge ciphertext, whic=
h would enable him to and flip various bits decrypted plaintext bits. (Of c=
ourse the current design allows anyone to do
 this today it&#8217;s just that the later MAC will detect it so it becomes=
 a game of oracle testing).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Additionally, the concern=
 (D) is raised that an attacker who completely succeeds with (C) may then b=
e able to &#8220;reach back through&#8221; several additional layers
 of HMAC in the TLS PRF in order to derive one or both of the cipher keys a=
llowing full decryption of the protocol stream.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">To be clear, I say &#8220=
;reach back through&#8221; because I don&#8217;t think there is actually a =
name for this attack model. Even if we were just talking about a hash funct=
ion
 instead of HMAC, this is an attack capability *<b>beyond</b>* primary prei=
mage. Primary preimage is &#8220;given h(M), find M&#8217; such that h(M&#8=
217;) =3D h(M)&#8221;, whereas this attack is: &#8220;given h(M), find M&#8=
221;!<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In other words, the attac=
ker doesn&#8217;t get to control the message input. Such a feat has never b=
een openly proposed in the literature (that I&#8217;ve seen on hash
 functions), not even theorized, not even for MD4.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">But again, our scenario (=
C) is not the use of plain hash functions. We&#8217;re talking about attack=
ing the use of HMAC&lt;Hfn&gt;(k, msg) to recover the secret key bits
 of input. This is yet another step removed from &#8220;unthinkable&#8221;.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">In the case where that th=
e secret key length is the same as the MAC length, there&#8217;s even about=
 a coin toss chance there will be two or more keys that yield
 the target hash MAC. When the MAC is truncated, there are exponentially mo=
re.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">But again, for the concer=
n (D), we&#8217;re talking about accomplishing (C) and then continuing on t=
o attack the TLS PRF through several cascaded HMAC&lt;Hfn&gt;(k, msg)
 to recover the secret key bits of input. This is yet another step removed =
from &#8220;unthinkable&#8221;.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">My conclusion is that for=
 any reasonable choice of hash function, the TLS PRF is noninvertible. To p=
ut this another way, if this feat were demonstrated even
 using the horribly broken MD5 it would be earth-shattering in its crypto i=
mpact. It is secure forever, unless there are seriously fundamental advance=
s in complexity-theoretic cryptanalysis. And if that day comes, *<b>it will=
 be your fast ciphers that you&#8217;ll
 worry about</b>*. The TLS PRF is by far the slowest, most conservatively d=
esigned stream cipher in common use.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I would never say somethi=
ng is &#8220;impossible&#8221; in cryptanalysis. We should always be vigila=
nt and paranoid. But the key to being *<b>constructively paranoid</b>*
 is to worry about the *<b>right</b>* thing. The security of HMAC&lt;modern=
 hash&gt;(secret k, message) is *<b>not</b>* the right to worry about.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">The thing to worry about =
is block cipher modes&#8217; propensity to turn into plaintext oracles. Thi=
s has been demonstrated as a practical attack on over and over
 again.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">***
<b>RECOMMENDATIONS </b>***<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">* Put TLS PRF and HMAC se=
curity way, way down if not last on the list of things likely to negatively=
 affect security.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">For all future TLS cipher=
 suites and TLS 1.3 in general is:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">* Use encrypt-then-HMAC. =
Seriously. Yes really. No other choice is defensible in this age. If you th=
ink &#8220;oh but GCM&#8221; look more closely into its design.<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">* Use the NIST-specified =
truncation SHA-2-512/256 for the HMAC hash function.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">* Don&#8217;t truncate th=
e TLS record MAC in an attempt to protect the master secret (as in the Fini=
shed message). Even if such an attack were practical, the attacker
 sees many samples of the MAC any way.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">* Do truncate the TLS rec=
ord MAC to 128 bits because anything more is an indefensible waste of bandw=
idth.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">* Don&#8217;t panic.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks for reading this f=
ar. I&#8217;m fallible. TIA for details, factual corrections, and flames. T=
hese are my own personal opinions and not necessarily those of
 my employer.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l1 level=
1 lfo3"><![if !supportLists]><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span style=3D"mso-=
list:Ignore">-<span style=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style=3D"font-size:11.0pt;font-family:=
&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Marsh<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
</div>
</body>
</html>

--_000_c8943847aecd44c29540bd198794746bBY2PR03MB074namprd03pro_--

From Adam.Montville@cisecurity.org  Thu Nov 14 14:09:04 2013
Return-Path: <Adam.Montville@cisecurity.org>
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 C5B4011E8107 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 14:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.77
X-Spam-Level: 
X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.228,  BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 J5McGQahJVt2 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 14:09:00 -0800 (PST)
Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6021F9A97 for <tls@ietf.org>; Thu, 14 Nov 2013 14:08:59 -0800 (PST)
Received: from [216.82.253.227:17187] by server-13.bemta-7.messagelabs.com id 47/25-04975-AF945825; Thu, 14 Nov 2013 22:08:58 +0000
X-Env-Sender: Adam.Montville@cisecurity.org
X-Msg-Ref: server-15.tower-170.messagelabs.com!1384466937!18489766!2
X-Originating-IP: [69.195.43.86]
X-StarScan-Received: 
X-StarScan-Version: 6.9.13; banners=cisecurity.org,-,-
X-VirusChecked: Checked
Received: (qmail 6020 invoked from network); 14 Nov 2013 22:08:58 -0000
Received: from mail.msisac.org (HELO mail.msisac.org) (69.195.43.86) by server-15.tower-170.messagelabs.com with AES128-SHA encrypted SMTP; 14 Nov 2013 22:08:58 -0000
Received: from CISEXCHANGE1.msisac.org.local ([fe80::4f0:b68d:e779:38c3]) by CISEXCHANGE2.msisac.org.local ([::1]) with mapi id 14.02.0347.000; Thu, 14 Nov 2013 17:07:38 -0500
From: Adam Montville <Adam.Montville@cisecurity.org>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Peter Saint-Andre <stpeter@stpeter.im>, Tom Ritter <tom@ritter.vg>
Thread-Topic: [TLS] Ciphersuite Recommendations
Thread-Index: Ac7hUPHwoYCAtMzWSWiPMOHA4gZ+igARFzuAAAaC0bD//+yZgIAAAKOAgABTspD//604AIAAQLKw
Date: Thu, 14 Nov 2013 22:07:43 +0000
Message-ID: <05BCCEB107AF88469B9F99783D47C1D6065CEDC7@CISEXCHANGE1.msisac.org.local>
References: <05BCCEB107AF88469B9F99783D47C1D6065CDEC3@CISEXCHANGE1.msisac.org.local> <CA+cU71nfMXw+-SwkkqGYut8qxXKNeWnWNRbCSFrKD=5+=E1avw@mail.gmail.com> <05BCCEB107AF88469B9F99783D47C1D6065CE3D2@CISEXCHANGE1.msisac.org.local> <52853893.4020800@stpeter.im> <5285391B.8030707@gmail.com> <05BCCEB107AF88469B9F99783D47C1D6065CE405@CISEXCHANGE1.msisac.org.local> <528539E0.7050702@gmail.com>
In-Reply-To: <528539E0.7050702@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.252.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Ciphersuite Recommendations
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: Thu, 14 Nov 2013 22:09:04 -0000

I'll see what kind of response I can get...

> -----Original Message-----
> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> Sent: Thursday, November 14, 2013 2:59 PM
> To: Adam Montville; Peter Saint-Andre; Tom Ritter
> Cc: tls@ietf.org
> Subject: Re: [TLS] Ciphersuite Recommendations
>=20
> I'd certainly appreciate such a review.
>=20
> The document was presented at the recent meeting of the TLS working
> group, slides are here:
> https://tools.ietf.org/agenda/88/slides/slides-88-tls-0.pdf
>=20
> Thanks,
> =09Yaron
>=20
> On 11/14/2013 10:57 PM, Adam Montville wrote:
> >
> >
> >> -----Original Message-----
> >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
> >> Sent: Thursday, November 14, 2013 2:56 PM
> >> To: Peter Saint-Andre; Adam Montville; Tom Ritter
> >> Cc: tls@ietf.org
> >> Subject: Re: [TLS] Ciphersuite Recommendations
> >>
> >> Yes, this is our intention.
> >
> > For what it might be worth, I'll ask some of my constituents to review=
 the
> draft and provide usability feedback.  These are operator/administrators=
 who
> would be asked to configure their systems in a secure manner.
> >
> >>
> >> Thanks,
> >>        Yaron
> >>
> >> On 11/14/2013 10:54 PM, Peter Saint-Andre wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> On 11/14/13 1:50 PM, Adam Montville wrote:
> >>>> Yes, that looks about right.
> >>>>
> >>>> I was surprised, actually, that there was no IETF guidance availabl=
e.
> >>>>
> >>>> Anyone on this list think it?s a good idea to provide some?  I do.
> >>>
> >>> Isn't that what
> >>> https://datatracker.ietf.org/doc/draft-sheffer-tls-bcp/ is doing, in=
 part?
> >>>
> >>> Peter
> >>>
> >>
> >> ...
> > This message and attachments may contain confidential information. If =
it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments i=
s
> strictly prohibited. Please notify the sender immediately and permanentl=
y
> delete the message and any attachments.
> >
> > . . .
> >
>=20
> ...

. . .

From Kenny.Paterson@rhul.ac.uk  Thu Nov 14 15:07:24 2013
Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 97A4221E80F1 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, J_BACKHAIR_44=1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_46=0.6]
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 5JVQDzg4P-Dq for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:07:18 -0800 (PST)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3D36121E809F for <tls@ietf.org>; Thu, 14 Nov 2013 15:07:16 -0800 (PST)
Received: from mail181-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE006.bigfish.com (10.174.14.69) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 23:07:11 +0000
Received: from mail181-db9 (localhost [127.0.0.1])	by mail181-db9-R.bigfish.com (Postfix) with ESMTP id 34F511C0271	for <tls@ietf.org>; Thu, 14 Nov 2013 23:07:11 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT001.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: PS-4(zzbb2dI98dI148cI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hz97hz1de098h8275bh1de097hz2dh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(52604005)(51704005)(479174003)(199002)(189002)(83072001)(4396001)(46102001)(74876001)(49866001)(47976001)(50986001)(51856001)(54316002)(47736001)(83506001)(76176001)(85306002)(79102001)(1511001)(53806001)(76482001)(81816001)(76796001)(87936001)(59766001)(77982001)(74706001)(69226001)(76786001)(2656002)(87266001)(31966008)(74662001)(54356001)(74482001)(47446002)(74502001)(77096001)(56776001)(56816003)(74366001)(66066001)(65816001)(80976001)(80022001)(81686001)(81342001)(63696002)(81542001)(83322001)(19580405001)(36756003)(19580395003); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277; H:AMXPR03MB277.eurprd03.prod.outlook.com; CLIP:80.42.233.244; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail181-db9 (localhost.localdomain [127.0.0.1]) by mail181-db9 (MessageSwitch) id 1384470428869583_16196; Thu, 14 Nov 2013 23:07:08 +0000 (UTC)
Received: from DB9EHSMHS032.bigfish.com (unknown [10.174.16.251])	by mail181-db9.bigfish.com (Postfix) with ESMTP id CF6ED1E0168; Thu, 14 Nov 2013 23:07:08 +0000 (UTC)
Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by DB9EHSMHS032.bigfish.com (10.174.14.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 23:07:05 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AM2PRD0311HT001.eurprd03.prod.outlook.com (10.255.162.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 23:07:05 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 23:07:04 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.247]) by AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.247]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 23:07:04 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Marsh Ray <maray@microsoft.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAEmDYA
Date: Thu, 14 Nov 2013 23:07:04 +0000
Message-ID: <CEAB0756.EFCA%kenny.paterson@rhul.ac.uk>
In-Reply-To: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.233.244]
x-forefront-prvs: 0030839EEE
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3ECE551523C08A40816B5512649AEE04@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Thu, 14 Nov 2013 23:07:24 -0000

+1 to almost everything in this post.

Let's now move on to discussing the substantive issues, keeping in the
forefront of our minds Marsh's wonderful phrasing:

"We should always be vigilant and paranoid. But the key to being
*constructively paranoid* is to worry about the *right* thing."

Kenny



On 14/11/2013 21:00, "Marsh Ray" <maray@microsoft.com> wrote:

>=20
>Our knowledge of generic hashing constructions has evolved:
>A.    =20
>Standard constructions
>B.    =20
>Length extension attacks
>C.    =20
>Joux multicollisions/=B22nd preimages for less work=B2
>D.    =20
>Chosen-Target Forced-Prefix (Nostradamus, RapidSSL, Flame)
>E.     =20
>Sponge constructions
>=20
>Attacks against specific hashes (MD4, MD5, SHA-0, SHA-1, SHA-2) tend to
>unfold in sequence:
>1.     =20
>Reduced round collisions demonstrated (depends on reduction)
>2.     =20
>Absurdly impractical multicollision and/or collision weakness theorized
>3.     =20
>Plausible multicollision and/or collision weakness theorized
>4.     =20
>Full collision demonstrated
>5.     =20
>CTFP demonstrated
>6.     =20
>2nd preimage theorized
>7.     =20
>2nd preimage attack demonstrated
>8.     =20
>Primary preimage attacks demonstrated
>=20
>The last I heard:
>MD4 is at stage 6
>MD5 is at stage 5
>SHA-0 was withdrawn at stage 3 or 4
>SHA-1 is at stage 3
>SHA-2 is at stage 2
>=20
>Now let=B9s talk about HMAC.
>=20
>HMAC uses a double invocation of the full hash function each of which is
>initialized with a secret key. There=B9s some pretty well respected proven
>properties
> on the security of HMAC. For example, assuming the key is actually
>secret from the attacker, you generally don=B9t need to worry about
>collision attacks. The resulting MAC value or tag can be truncated and
>yet it still retains min(secret key bits, tag bits)
> security.
>=20
>In TLS, the secret key is generated by the TLS PRF. The TLS PRF is one of
>the most conservative parts of the design of TLS. It itself uses HMAC
>recursively.
> IIRC, to produce one block of PRF output takes something like 4
>invocations of the underlying hash=B9s block function. It functions much
>like a slow, conservative block cipher with 512+160 bits of key and
>secret plaintext input (512+1024 for SHA-2-384 and -512).
>=20
>So the concern (C) has been raised that an attacker who may know some
>plaintext, and sees one or more samples of ciphertext, and the
>non-truncated MAC tag around
> this ciphertext, may then be able to =B3reach back through=B2 the HMAC to
>obtain the MAC key. This would enable him to forge ciphertext, which
>would enable him to and flip various bits decrypted plaintext bits. (Of
>course the current design allows anyone to do
> this today it=B9s just that the later MAC will detect it so it becomes a
>game of oracle testing).
>=20
>Additionally, the concern (D) is raised that an attacker who completely
>succeeds with (C) may then be able to =B3reach back through=B2 several
>additional layers
> of HMAC in the TLS PRF in order to derive one or both of the cipher keys
>allowing full decryption of the protocol stream.
>=20
>To be clear, I say =B3reach back through=B2 because I don=B9t think there =
is
>actually a name for this attack model. Even if we were just talking about
>a hash function
> instead of HMAC, this is an attack capability *beyond* primary preimage.
>Primary preimage is =B3given h(M), find M=B9 such that h(M=B9) =3D h(M)=B2=
, whereas
>this attack is: =B3given h(M), find M=B2!
>=20
>In other words, the attacker doesn=B9t get to control the message input.
>Such a feat has never been openly proposed in the literature (that I=B9ve
>seen on hash
> functions), not even theorized, not even for MD4.
>=20
>But again, our scenario (C) is not the use of plain hash functions. We=B9r=
e
>talking about attacking the use of HMAC<Hfn>(k, msg) to recover the
>secret key bits
> of input. This is yet another step removed from =B3unthinkable=B2.
>=20
>In the case where that the secret key length is the same as the MAC
>length, there=B9s even about a coin toss chance there will be two or more
>keys that yield
> the target hash MAC. When the MAC is truncated, there are exponentially
>more.
>=20
>But again, for the concern (D), we=B9re talking about accomplishing (C) an=
d
>then continuing on to attack the TLS PRF through several cascaded
>HMAC<Hfn>(k, msg)
> to recover the secret key bits of input. This is yet another step
>removed from =B3unthinkable=B2.
>=20
>My conclusion is that for any reasonable choice of hash function, the TLS
>PRF is noninvertible. To put this another way, if this feat were
>demonstrated even
> using the horribly broken MD5 it would be earth-shattering in its crypto
>impact. It is secure forever, unless there are seriously fundamental
>advances in complexity-theoretic cryptanalysis. And if that day comes,
>*it will be your fast ciphers that you=B9ll
> worry about*. The TLS PRF is by far the slowest, most conservatively
>designed stream cipher in common use.
>
>=20
>I would never say something is =B3impossible=B2 in cryptanalysis. We shoul=
d
>always be vigilant and paranoid. But the key to being *constructively
>paranoid*
> is to worry about the *right* thing. The security of HMAC<modern
>hash>(secret k, message) is *not* the right to worry about.
>=20
>The thing to worry about is block cipher modes=B9 propensity to turn into
>plaintext oracles. This has been demonstrated as a practical attack on
>over and over
> again.
>=20
>***
>RECOMMENDATIONS ***
>=20
>* Put TLS PRF and HMAC security way, way down if not last on the list of
>things likely to negatively affect security.
>=20
>For all future TLS cipher suites and TLS 1.3 in general is:
>=20
>* Use encrypt-then-HMAC. Seriously. Yes really. No other choice is
>defensible in this age. If you think =B3oh but GCM=B2 look more closely in=
to
>its design.
>=20
>* Use the NIST-specified truncation SHA-2-512/256 for the HMAC hash
>function.
>
>* Don=B9t truncate the TLS record MAC in an attempt to protect the master
>secret (as in the Finished message). Even if such an attack were
>practical, the attacker
> sees many samples of the MAC any way.
>=20
>* Do truncate the TLS record MAC to 128 bits because anything more is an
>indefensible waste of bandwidth.
>=20
>* Don=B9t panic.
>=20
>Thanks for reading this far. I=B9m fallible. TIA for details, factual
>corrections, and flames. These are my own personal opinions and not
>necessarily those of
> my employer.
>=20
>-        =20
>Marsh
>=20
>



From prvs=40306ac450=uri@ll.mit.edu  Thu Nov 14 15:18:30 2013
Return-Path: <prvs=40306ac450=uri@ll.mit.edu>
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 D1C9B11E8123 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:18:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.773
X-Spam-Level: 
X-Spam-Status: No, score=-4.773 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, J_BACKHAIR_44=1, J_CHICKENPOX_36=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=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 EYEG0UcQ1sCw for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:18:26 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0E91511E8112 for <tls@ietf.org>; Thu, 14 Nov 2013 15:18:25 -0800 (PST)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id rAENIOJv018235 for <tls@ietf.org>; Thu, 14 Nov 2013 18:18:24 -0500
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'tls@ietf.org'" <tls@ietf.org>
Date: Thu, 14 Nov 2013 18:18:23 -0500
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAEmDYAAABmbic=
In-Reply-To: <CEAB0756.EFCA%kenny.paterson@rhul.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-14_07:2013-11-13, 2013-11-14, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311140176
Message-Id: <20131114231826.0E91511E8112@ietfa.amsl.com>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Thu, 14 Nov 2013 23:18:31 -0000

+1

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: <uri@ll.mit.edu>
Lexington, MA  02420-9185      =20

Web:  http://www.ll.mit.edu/CST/

=20

MIT LL Root CA:=20

 <https://www.ll.mit.edu/labcertificateauthority.html>


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk]
Sent: Thursday, November 14, 2013 06:07 PM=0A=
To: Marsh Ray <maray@microsoft.com>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's wh=
y:

+1 to almost everything in this post.

Let's now move on to discussing the substantive issues, keeping in the
forefront of our minds Marsh's wonderful phrasing:

"We should always be vigilant and paranoid. But the key to being
*constructively paranoid* is to worry about the *right* thing."

Kenny



On 14/11/2013 21:00, "Marsh Ray" <maray@microsoft.com> wrote:

>=20
>Our knowledge of generic hashing constructions has evolved:
>A.    =20
>Standard constructions
>B.    =20
>Length extension attacks
>C.    =20
>Joux multicollisions/=B22nd preimages for less work=B2
>D.    =20
>Chosen-Target Forced-Prefix (Nostradamus, RapidSSL, Flame)
>E.     =20
>Sponge constructions
>=20
>Attacks against specific hashes (MD4, MD5, SHA-0, SHA-1, SHA-2) tend to
>unfold in sequence:
>1.     =20
>Reduced round collisions demonstrated (depends on reduction)
>2.     =20
>Absurdly impractical multicollision and/or collision weakness theorized
>3.     =20
>Plausible multicollision and/or collision weakness theorized
>4.     =20
>Full collision demonstrated
>5.     =20
>CTFP demonstrated
>6.     =20
>2nd preimage theorized
>7.     =20
>2nd preimage attack demonstrated
>8.     =20
>Primary preimage attacks demonstrated
>=20
>The last I heard:
>MD4 is at stage 6
>MD5 is at stage 5
>SHA-0 was withdrawn at stage 3 or 4
>SHA-1 is at stage 3
>SHA-2 is at stage 2
>=20
>Now let=B9s talk about HMAC.
>=20
>HMAC uses a double invocation of the full hash function each of which is
>initialized with a secret key. There=B9s some pretty well respected proven
>properties
> on the security of HMAC. For example, assuming the key is actually
>secret from the attacker, you generally don=B9t need to worry about
>collision attacks. The resulting MAC value or tag can be truncated and
>yet it still retains min(secret key bits, tag bits)
> security.
>=20
>In TLS, the secret key is generated by the TLS PRF. The TLS PRF is one of
>the most conservative parts of the design of TLS. It itself uses HMAC
>recursively.
> IIRC, to produce one block of PRF output takes something like 4
>invocations of the underlying hash=B9s block function. It functions much
>like a slow, conservative block cipher with 512+160 bits of key and
>secret plaintext input (512+1024 for SHA-2-384 and -512).
>=20
>So the concern (C) has been raised that an attacker who may know some
>plaintext, and sees one or more samples of ciphertext, and the
>non-truncated MAC tag around
> this ciphertext, may then be able to =B3reach back through=B2 the HMAC to
>obtain the MAC key. This would enable him to forge ciphertext, which
>would enable him to and flip various bits decrypted plaintext bits. (Of
>course the current design allows anyone to do
> this today it=B9s just that the later MAC will detect it so it becomes a
>game of oracle testing).
>=20
>Additionally, the concern (D) is raised that an attacker who completely
>succeeds with (C) may then be able to =B3reach back through=B2 several
>additional layers
> of HMAC in the TLS PRF in order to derive one or both of the cipher keys
>allowing full decryption of the protocol stream.
>=20
>To be clear, I say =B3reach back through=B2 because I don=B9t think there =
is
>actually a name for this attack model. Even if we were just talking about
>a hash function
> instead of HMAC, this is an attack capability *beyond* primary preimage.
>Primary preimage is =B3given h(M), find M=B9 such that h(M=B9) =3D h(M)=B2=
, whereas
>this attack is: =B3given h(M), find M=B2!
>=20
>In other words, the attacker doesn=B9t get to control the message input.
>Such a feat has never been openly proposed in the literature (that I=B9ve
>seen on hash
> functions), not even theorized, not even for MD4.
>=20
>But again, our scenario (C) is not the use of plain hash functions. We=B9r=
e
>talking about attacking the use of HMAC<Hfn>(k, msg) to recover the
>secret key bits
> of input. This is yet another step removed from =B3unthinkable=B2.
>=20
>In the case where that the secret key length is the same as the MAC
>length, there=B9s even about a coin toss chance there will be two or more
>keys that yield
> the target hash MAC. When the MAC is truncated, there are exponentially
>more.
>=20
>But again, for the concern (D), we=B9re talking about accomplishing (C) an=
d
>then continuing on to attack the TLS PRF through several cascaded
>HMAC<Hfn>(k, msg)
> to recover the secret key bits of input. This is yet another step
>removed from =B3unthinkable=B2.
>=20
>My conclusion is that for any reasonable choice of hash function, the TLS
>PRF is noninvertible. To put this another way, if this feat were
>demonstrated even
> using the horribly broken MD5 it would be earth-shattering in its crypto
>impact. It is secure forever, unless there are seriously fundamental
>advances in complexity-theoretic cryptanalysis. And if that day comes,
>*it will be your fast ciphers that you=B9ll
> worry about*. The TLS PRF is by far the slowest, most conservatively
>designed stream cipher in common use.
>
>=20
>I would never say something is =B3impossible=B2 in cryptanalysis. We shoul=
d
>always be vigilant and paranoid. But the key to being *constructively
>paranoid*
> is to worry about the *right* thing. The security of HMAC<modern
>hash>(secret k, message) is *not* the right to worry about.
>=20
>The thing to worry about is block cipher modes=B9 propensity to turn into
>plaintext oracles. This has been demonstrated as a practical attack on
>over and over
> again.
>=20
>***
>RECOMMENDATIONS ***
>=20
>* Put TLS PRF and HMAC security way, way down if not last on the list of
>things likely to negatively affect security.
>=20
>For all future TLS cipher suites and TLS 1.3 in general is:
>=20
>* Use encrypt-then-HMAC. Seriously. Yes really. No other choice is
>defensible in this age. If you think =B3oh but GCM=B2 look more closely in=
to
>its design.
>=20
>* Use the NIST-specified truncation SHA-2-512/256 for the HMAC hash
>function.
>
>* Don=B9t truncate the TLS record MAC in an attempt to protect the master
>secret (as in the Finished message). Even if such an attack were
>practical, the attacker
> sees many samples of the MAC any way.
>=20
>* Do truncate the TLS record MAC to 128 bits because anything more is an
>indefensible waste of bandwidth.
>=20
>* Don=B9t panic.
>=20
>Thanks for reading this far. I=B9m fallible. TIA for details, factual
>corrections, and flames. These are my own personal opinions and not
>necessarily those of
> my employer.
>=20
>-        =20
>Marsh
>=20
>


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From Kenny.Paterson@rhul.ac.uk  Thu Nov 14 15:24:13 2013
Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 D554A11E8112 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:24:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
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 U+FqHERPhLFM for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 15:24:08 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8D54621F9E12 for <tls@ietf.org>; Thu, 14 Nov 2013 15:24:08 -0800 (PST)
Received: from mail60-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 23:24:08 +0000
Received: from mail60-ch1 (localhost [127.0.0.1])	by mail60-ch1-R.bigfish.com (Postfix) with ESMTP id 17B1A2E0470; Thu, 14 Nov 2013 23:24:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT005.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -6
X-BigFish: PS-6(zzbb2dI98dI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah8275bh8275dh1de097h186068h5eeeKz2dh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(479174003)(243025003)(24454002)(51704005)(81686001)(81342001)(74366001)(66066001)(65816001)(80022001)(80976001)(19580395003)(83322001)(19580405001)(36756003)(63696002)(81542001)(83506001)(76176001)(85306002)(74876001)(46102001)(15975445006)(4396001)(83072001)(51856001)(47736001)(54316002)(49866001)(47976001)(50986001)(31966008)(87266001)(56776001)(77096001)(56816003)(74662001)(54356001)(74482001)(47446002)(74502001)(76482001)(81816001)(79102001)(53806001)(77982001)(59766001)(69226001)(74706001)(2656002)(76786001)(15202345003)(76796001)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277; H:AMXPR03MB277.eurprd03.prod.outlook.com; CLIP:80.42.233.244; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail60-ch1 (localhost.localdomain [127.0.0.1]) by mail60-ch1 (MessageSwitch) id 1384471445420811_17668; Thu, 14 Nov 2013 23:24:05 +0000 (UTC)
Received: from CH1EHSMHS028.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241])	by mail60-ch1.bigfish.com (Postfix) with ESMTP id 627862C0270;	Thu, 14 Nov 2013 23:24:05 +0000 (UTC)
Received: from AM2PRD0311HT005.eurprd03.prod.outlook.com (157.56.249.149) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 23:24:05 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AM2PRD0311HT005.eurprd03.prod.outlook.com (10.255.162.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 23:24:03 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 23:24:02 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.247]) by AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.247]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 23:24:02 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: "mrex@sap.com" <mrex@sap.com>, Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO3zaO40RCOuXxpUqyO6le2oJDVpohW7MAgAB1XYCAAeSAgIABIe6AgAALoICAAAOvAIAAAWSAgAAEl4CAAHX4AA==
Date: Thu, 14 Nov 2013 23:24:02 +0000
Message-ID: <CEAB081E.EFD2%kenny.paterson@rhul.ac.uk>
In-Reply-To: <20131114162143.4719D1AA90@ld9781.wdf.sap.corp>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.233.244]
x-forefront-prvs: 0030839EEE
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4FFEA004603EA7478D0AC6FA9B8E955B@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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: Thu, 14 Nov 2013 23:24:13 -0000

On 14/11/2013 16:21, "Martin Rex" <mrex@sap.com> wrote:

>Ralf Skyper Kaiser wrote:
>>
>> With EtA you need to trust the MAC. With AtE you need to trust the
>>cipher
>> _and_ the MAC.
>
>I believe you're confused.
>
>The MAC provides integrity protection, the Encryption provides
>confidentiality.  The quality of the MAC has exactly Zero impact
>on the confidentiality provided by the Encryption.

Unfortunately, you're completely wrong. The MAC is also necessary to
preserve confidentiality in the face of active attacks. It's a very common
misunderstanding amongst novice cryptographers to believe that there's a
separation:

	MAC <-> integrity
	Enc <-> confidentiality

If you need an example, consider the security history of IPsec's
encryption-only modes. (Am I allowed to mention IPsec on a TLS list? Well,
I just did.)=20

These modes provide confidentiality against passive attackers, yes, but
they fail pretty spectacularly against active attackers. Bellovin was the
first to show that; the nadir for encryption-only IPsec came in my 2007
Oakland paper with Jean Paul Degabriele, full version here:

http://eprint.iacr.org/2007/125

(Just read the abstract if you've forgotten the headline.)

And, as far as I know, there are no significant attacks when IPsec is
configured in encrypt-then-MAC configurations (e.g. ESP conf+auth or ESP
followed by AH). On the other hand, all the configurations of IPsec where
the MAC is applied before the encryption are broken. (Another
demonstration that MAC-then-encrypt is not a robust choice.)

>For EtA, the characteristics&quality of the Cipher do not affect
>(and therefore can not improve) the quality of the MAC scheme
>at all.

That's true but irrelevant, unless you don't trust your MAC algorithm. So
why do you not trust HMAC-SHA256? Can you point to any shred of evidence
that it is weak in some way? That it is likely to become weak? That its
extensive security analysis is wrong? Without back-up of this kind, your
argument is just hot air. See also Marsh Ray's recent post.

>For AtE, the characteristics&quality of the Cipher additionally
>strengthen the quality of the MAC scheme, so weaknesses in the MAC
>scheme do not immediately translate into a vulnerability.

That's true too, but should be accorded small weight in the argument given
the litany of attacks against MAC-then-encrypt constructions.

>Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
>that does not have cryptographic hash properties (2nd paragraph Page 10):
>
>  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
>
>  GHASH is a keyed hash function but not, on its own, a cryptographic
>  hash function. This Recommendation only approves GHASH for use within
>  the context of GCM.
>
>The use of GHASH without cryptographic protection would not be safe.
>

Also true. But guess what? In GCM, the GHASH MAC is computed on the
ciphertext! The GHASH output is then encrypted using a further invocation
of the block cipher. Where does this leave your argument in favour of
MAC-then-encrypt?

Kenny



From tom@ritter.vg  Fri Nov 15 06:12:15 2013
Return-Path: <tom@ritter.vg>
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 AD88E11E81B0 for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 06:12:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 IfD6ojoKukPn for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 06:12:15 -0800 (PST)
Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3477E11E81AD for <tls@ietf.org>; Fri, 15 Nov 2013 06:12:15 -0800 (PST)
Received: by mail-pb0-f41.google.com with SMTP id jt11so3654174pbb.28 for <tls@ietf.org>; Fri, 15 Nov 2013 06:12:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1hdVE/NF76mOCYx/y9kmrVadS2k8XHN+lXUECgCt8N8=; b=mU8CiLKb8hlVBZ+SMWMmx3brsjpnknV3tEYmb9HxJ7gwbRXy0AA1VTGMJFN8QHwURc 9sh+Q5wgyphcKUcO8lyE80nN2YikvazldxLQgGmTDEQyeQjiGaD8A29oUmrDNcMGdrdp ZQuHjcXUfea3xUeKv7j6UjKplyGk91dmMTTx0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1hdVE/NF76mOCYx/y9kmrVadS2k8XHN+lXUECgCt8N8=; b=gmBGJnC+gqY1N1+QccWWmzYWPTIFoTG+lEekA6R6UJDylGF4JOYkLwf54POx2mFjt5 WtQISr4Kcg8E1jURNSQMZSKn9Odx3cKc4CxQ+rSEkbabV4bkTeYQKhFAeUipfRzq2rUA AyanJ5g3GdCGspw7X/K9GpcAgumX5x92gnQRfjD/pwvDSlfyrYWDAwbghXbXCYJrIf3Y tq6YZK3J2o+crtt8P8o/42aibvs+8m8RrwJ9GSFJhh7vA+hHPQvhhOuq4ZhqQsKXZTBL 7hwo5+8vlKWBbY/Bx/Tgke9wQTU5h2X7WCaVpeivRc9Zqc45K/qaoLun5l5naZK0bOfU 4NGw==
X-Gm-Message-State: ALoCoQl2jSxOyalgYAC50TUDqhLXwFmAj9KAIEK3zlRyjjzvoe6kecKEop95VWJE0ZSx9Gg7ExNf
X-Received: by 10.68.244.2 with SMTP id xc2mr7081649pbc.58.1384524734822; Fri, 15 Nov 2013 06:12:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.169.193 with HTTP; Fri, 15 Nov 2013 06:11:54 -0800 (PST)
In-Reply-To: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
From: Tom Ritter <tom@ritter.vg>
Date: Fri, 15 Nov 2013 09:11:54 -0500
Message-ID: <CA+cU71k86kOm2UDCAw7rtb=f8-30BtZZ+QZ7w_S0n4wc2dGVHQ@mail.gmail.com>
To: Marsh Ray <maray@microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Fri, 15 Nov 2013 14:12:15 -0000

+1

-tom

From n.mavrogiannopoulos@gmail.com  Fri Nov 15 07:24:23 2013
Return-Path: <n.mavrogiannopoulos@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 B123B11E81A2 for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 07:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 cAGSbJRXG6lQ for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 07:24:23 -0800 (PST)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id EA5F321F9A5F for <tls@ietf.org>; Fri, 15 Nov 2013 07:24:22 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id ec20so2856385lab.38 for <tls@ietf.org>; Fri, 15 Nov 2013 07:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=fkwXNjNOSzqYENLN2/VT1+v+WB5cHRaNUGSyD7bZgX0=; b=bv3Tpg5KK5V1MpoVyo4Lll8v0reSCe0gnEq42Yf3u1AeUFfCqE2FNK4mfjXEh4XeYg K4hHXu2lU0uMovA+pOOVwYdED23CU3IdFYV9ct/9uxxn2yCZs7FlJQ/Z7eqoFnthCxJS of/NOwqEjM88i3xR84kDqlRmmdyXy+SwftPawhlNJgUUDiVZMYCbhvDrLN7dqdcuFBx/ VlrUj6Ep+tet+2ydKk8lANFI7twFg496OfK9jL0yaoUF+KTEC5AlmFqirVldlrdEkC1x z8TqXGvonsjr1O81vGouNfpCsLbtbFPz1lXqg4PE64Ab7MYp1n+cD/qjEC/pNnRFZnL4 R6eQ==
MIME-Version: 1.0
X-Received: by 10.152.3.42 with SMTP id 10mr4708007laz.22.1384529061838; Fri, 15 Nov 2013 07:24:21 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Fri, 15 Nov 2013 07:24:21 -0800 (PST)
In-Reply-To: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Fri, 15 Nov 2013 16:24:21 +0100
X-Google-Sender-Auth: QZ2gobM56T5lY3VTq8Mb95qzlJY
Message-ID: <CAJU7zaK237JJPageTC+HRzLvmvi-1yEaS08VG_zCDpmMH_YwuA@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Marsh Ray <maray@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Fri, 15 Nov 2013 15:24:23 -0000

On Thu, Nov 14, 2013 at 10:00 PM, Marsh Ray <maray@microsoft.com> wrote:
>
>
> Our knowledge of generic hashing constructions has evolved:
[...]
> My conclusion is that for any reasonable choice of hash function, the TLS
> PRF is noninvertible. To put this another way, if this feat were
> demonstrated even using the horribly broken MD5 it would be earth-shatter=
ing
> in its crypto impact. It is secure forever, unless there are seriously
> fundamental advances in complexity-theoretic cryptanalysis. And if that d=
ay
> comes, *it will be your fast ciphers that you=E2=80=99ll worry about*. Th=
e TLS PRF
> is by far the slowest, most conservatively designed stream cipher in comm=
on
> use.

Hello,
 These are interesting facts and I don't think anyone denied them in
this list. The fact however that EtA is ok, doesn't imply that AtE is
not ok. The only stream cipher in TLS had never issues due to the mode
of encryption (AtE). Why switch it to EtA when we know the issue and
can fix (fix and not hack) the currently used mode?

In any case that is argumentation for the sake of argumentation. Now
we are full of hacks solving the issue and what we need is some action
on this topic.

regards,
Nikos

From rransom.8774@gmail.com  Fri Nov 15 11:43:18 2013
Return-Path: <rransom.8774@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 E8D4611E81C4 for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 11:43:18 -0800 (PST)
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 xg3W178TIfmX for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 11:43:18 -0800 (PST)
Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 83F3D11E812F for <tls@ietf.org>; Fri, 15 Nov 2013 11:42:52 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id j7so812593qaq.13 for <tls@ietf.org>; Fri, 15 Nov 2013 11:42:52 -0800 (PST)
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:content-transfer-encoding; bh=Hr61sLhUaAXDCrlHHXMJCLH+rqcX7dkHEZGBVb7A0QU=; b=qBFJU4+SR62hba/mMFEvdrl9r0uay5VaTHmfzjxb5QHZo/4XuQWZz/2UgQ2392vi1o 9PNE2o0NWPrKpq1+uqrA/cm86EDTLlZlyDiR4Vkn2vABw/QXGVKAhAIAxRf9rMNgIx1s iSpUuT5lWaXpOtHfr2KEZgQdFRwPmCI1Zvqox5juUIIUZq9CCB9FmBiax7/3v/mHwLFI R3h5YJQTKDTtxlXbsrzRXxQ1GePFa0fTFUY5cHyOZ44Q8ujxBdP2mosWdkldktyy8i+m AKQqs5fwybQUlcJYql5KluOmCDtMW7q3wTC0y00RXdjBVgSmEYArixIP4d1JSviPhJ4t /bYQ==
MIME-Version: 1.0
X-Received: by 10.229.54.65 with SMTP id p1mr13546191qcg.18.1384544571988; Fri, 15 Nov 2013 11:42:51 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Fri, 15 Nov 2013 11:42:51 -0800 (PST)
In-Reply-To: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Fri, 15 Nov 2013 11:42:51 -0800
Message-ID: <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: Marsh Ray <maray@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Fri, 15 Nov 2013 19:43:19 -0000

On 11/14/13, Marsh Ray <maray@microsoft.com> wrote:

> HMAC uses a double invocation of the full hash function each of which is
> initialized with a secret key. There's some pretty well respected proven
> properties on the security of HMAC.

Are these properties proved for all iterative hash functions, or only
for hash functions with the same general structure (block cipher in
feedforward mode) as MD5 and the pre-SHA-3 NSA hash functions?


> Additionally, the concern (D) is raised that an attacker who completely
> succeeds with (C) may then be able to "reach back through" several
> additional layers of HMAC in the TLS PRF in order to derive one or both o=
f
> the cipher keys allowing full decryption of the protocol stream.
>
> To be clear, I say "reach back through" because I don't think there is
> actually a name for this attack model. Even if we were just talking about=
 a
> hash function instead of HMAC, this is an attack capability *beyond* prim=
ary
> preimage. Primary preimage is "given h(M), find M' such that h(M') =3D h(=
M)",
> whereas this attack is: "given h(M), find M"!

I call that a =E2=80=9Cpreimage recovery attack=E2=80=9D.  I don't think th=
at name is
standard, but it is an accurate description of the attack.


> The thing to worry about is block cipher modes' propensity to turn into
> plaintext oracles. This has been demonstrated as a practical attack on ov=
er
> and over again.

This is the most important point, and it's already being ignored (again).


> * Use encrypt-then-HMAC. Seriously. Yes really. No other choice is
> defensible in this age. If you think "oh but GCM" look more closely into =
its
> design.

There are plenty of other defensible choices for a MAC.

GCM has some bad design features, but its MAC is the good part (at
least for implementations with hardware support for multiplication in
GF(2)[X]).

Poly1305 (as used in draft-agl-chacha20-poly1305-03) is faster than
HMAC, and almost as secure.

SipHash is faster than Poly1305, and as secure as an HMAC truncated to
64 bits.  I don't expect it to be used in TLS, but it's certainly good
enough for voice communication protocols over UDP.

With a good hash function (one which does not permit the
length-extension attack), such as any of the SHA-3 finalists, H(k, m)
is a good MAC.


Robert Ransom

From maray@microsoft.com  Fri Nov 15 14:44:30 2013
Return-Path: <maray@microsoft.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 7899711E815C for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 14:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 NM+L-+5itf0g for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 14:44:26 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id CD84411E8193 for <tls@ietf.org>; Fri, 15 Nov 2013 14:44:25 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) with Microsoft SMTP Server (TLS) id 15.0.820.5; Fri, 15 Nov 2013 22:44:21 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) with mapi id 15.00.0820.005; Fri, 15 Nov 2013 22:44:21 +0000
From: Marsh Ray <maray@microsoft.com>
To: Robert Ransom <rransom.8774@gmail.com>
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAvwiuAAANTVBA=
Date: Fri, 15 Nov 2013 22:44:21 +0000
Message-ID: <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com> <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com>
In-Reply-To: <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.79]
x-o365ent-eop-header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(479174003)(24454002)(199002)(189002)(51704005)(377454003)(76796001)(54356001)(74876001)(74706001)(76786001)(56816003)(79102001)(77982001)(76576001)(51856001)(69226001)(63696002)(77096001)(59766001)(85306002)(15202345003)(83072001)(53806001)(15975445006)(33646001)(76482001)(65816001)(47446002)(74502001)(19580395003)(50986001)(47976001)(87936001)(54316002)(81342001)(2656002)(31966008)(83322001)(19580405001)(80022001)(46102001)(74662001)(66066001)(56776001)(81686001)(81542001)(80976001)(4396001)(87266001)(47736001)(81816001)(74316001)(74366001)(49866001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB074; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:131.107.192.79; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Fri, 15 Nov 2013 22:44:30 -0000

RnJvbTogUm9iZXJ0IFJhbnNvbSBbbWFpbHRvOnJyYW5zb20uODc3NEBnbWFpbC5jb21dDQpTZW50
OiBGcmlkYXksIE5vdmVtYmVyIDE1LCAyMDEzIDExOjQzIEFNDQo+IA0KPiBPbiAxMS8xNC8xMywg
TWFyc2ggUmF5IDxtYXJheUBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gPiBITUFDIHVzZXMgYSBk
b3VibGUgaW52b2NhdGlvbiBvZiB0aGUgZnVsbCBoYXNoIGZ1bmN0aW9uIGVhY2ggb2Ygd2hpY2gN
Cj4gPiBpcyBpbml0aWFsaXplZCB3aXRoIGEgc2VjcmV0IGtleS4gVGhlcmUncyBzb21lIHByZXR0
eSB3ZWxsIHJlc3BlY3RlZA0KPiA+IHByb3ZlbiBwcm9wZXJ0aWVzIG9uIHRoZSBzZWN1cml0eSBv
ZiBITUFDLg0KPiANCj4gQXJlIHRoZXNlIHByb3BlcnRpZXMgcHJvdmVkIGZvciBhbGwgaXRlcmF0
aXZlIGhhc2ggZnVuY3Rpb25zLCBvciBvbmx5IGZvciBoYXNoDQo+IGZ1bmN0aW9ucyB3aXRoIHRo
ZSBzYW1lIGdlbmVyYWwgc3RydWN0dXJlIChibG9jayBjaXBoZXIgaW4gZmVlZGZvcndhcmQNCj4g
bW9kZSkgYXMgTUQ1IGFuZCB0aGUgcHJlLVNIQS0zIE5TQSBoYXNoIGZ1bmN0aW9ucz8NCg0KT25l
IHdvdWxkIGNlcnRhaW5seSBob3BlIHRoZSBwcm9wZXJ0aWVzIHdvdWxkIHN0aWxsIGhvbGQgd2hl
biB1c2VkIHdpdGggYWN0dWFsIGhhc2ggZnVuY3Rpb25zIHdoaWNoIGRpZmZlciBmcm9tIGFuIGlk
ZWFsIGhhc2ggZnVuY3Rpb24gaW4gYSBzdWJzZXQgb2Ygd2F5cy4NCg0KSVNUUiBvbmUgb2YgdGhl
IG9yaWdpbmFsIE5JU1QgcmVxdWlyZW1lbnRzIGZvciBTSEEtMyB3YXMgdGhhdCBpdCBiZSBjb21w
YXRpYmxlIHdpdGggZXhpc3RpbmcgY29uc3RydWN0aW9ucyBsaWtlIEhNQUMuIE9uIHRoZSBvdGhl
ciBoYW5kLCBOSVNUIHNlZW1lZCB0byBmZWVsIHRoYXQgc29tZSBvZiB0aGUgb3RoZXIgb3JpZ2lu
YWwgcmVxdWlyZW1lbnRzIHdlcmUgc3RpbGwgbmVnb3RpYWJsZSAoZS5nLiwgcHJlaW1hZ2UgcmVz
aXN0YW5jZSBvZiB0d28gdGltZXMgY29sbGlzaW9uIHJlc2lzdGFuY2UpLg0KDQpOSVNUIHN1Z2dl
c3RzIHRoZXkgd2lsbCBzdGFuZGFyZGl6ZSBhIHNwZWNpZmljIE1BQyBtb2RlIGZvciBTSEEtMy4g
SSBoYXZlbid0IGhlYXJkIGFueXRoaW5nIHRvIHN1Z2dlc3QgdGhpcyBwcm92aWRlcyBhbnkgc2Vj
dXJpdHkgYWR2YW50YWdlIG92ZXIgSE1BQywganVzdCBhIGxpdHRsZSBtb3JlIHBlcmZvcm1hbmNl
IGZvciBzaG9ydCBtZXNzYWdlcy4NCg0KPiBJIGNhbGwgdGhhdCBhIOKAnHByZWltYWdlIHJlY292
ZXJ5IGF0dGFja+KAnS4gIEkgZG9uJ3QgdGhpbmsgdGhhdCBuYW1lIGlzIHN0YW5kYXJkLA0KPiBi
dXQgaXQgaXMgYW4gYWNjdXJhdGUgZGVzY3JpcHRpb24gb2YgdGhlIGF0dGFjay4NCg0KSW50dWl0
aXZlbHkgdGhhdCBtYWtlcyBzZW5zZSBhcyBhIGRlc2NyaXB0aXZlIHRlcm0uDQoNCkJ1dCBJIGZp
bmQgZm9yIG15c2VsZiB0aGF0IGhhdmluZyBzdWNoIGFuIGF0dHJhY3RpdmUgdGVybSBhcm91bmQg
aXMgYSBkYW5nZXJvdXMgdGVtcHRhdGlvbiENCg0KTXkgc2VhcmNoIGVuZ2luZSB0dXJucyB1cCBv
bmx5IG9uZSBoaXQgZm9yIHRoZSB0ZXJtOg0KaHR0cDovL2NyeXB0by5zdGFja2V4Y2hhbmdlLmNv
bS9xdWVzdGlvbnMvNTU4OS9zcGVlZGluZy11cC1wYXJ0aWFsbHkta25vd24tcGxhaW50ZXh0LXBy
ZWltYWdlLXJlY292ZXJ5LWF0dGFjay1vbi1tZDUNCg0KSSB0aGluayBpdCdzIGEgcmVhc29uYWJs
ZSBxdWVzdGlvbiBhbmQgdGhlIGFza2VyIGdldHMgYSBnb29kIGFuc3dlciwgYnV0IEkgd291bGQg
bXVjaCByYXRoZXIgc2VlIGl0IGRlZmluZWQgYSBiaXQgbW9yZSBmb3JtYWxseS4gSXQgcHJvYmFi
bHkgaGFzIGJlZW4gc29tZXdoZXJlLg0KDQo+IFRoZXJlIGFyZSBwbGVudHkgb2Ygb3RoZXIgZGVm
ZW5zaWJsZSBjaG9pY2VzIGZvciBhIE1BQy4NCg0KWWVhaCwgSSBkaWRuJ3QgbWVhbiB0byBpbXBs
eSBzbyBtdWNoIHRoYXQgSE1BQyBpcyB0aGUgT25lIFRydWUgTUFDIG9yIHRoYXQgaW50ZWdyYXRl
ZCBBRSBtb2RlcyBjYW4gbmV2ZXIgYmUgZGVmZW5zaWJsZS4gSnVzdCB0aGF0IE1BQy0odGhlbnxh
bmQpLUVuY3J5cHQgYXJlIGJyb2tlbiB3aGlsZSBFbmNyeXB0LXRoZW4tSE1BQyBpcyBhIHZlcnkg
Y29uc2VydmF0aXZlIGRlc2lnbiB3aGljaCBoYXMgc3Rvb2QgdGhlIHRlc3Qgb2YgdGltZSBhbmQg
ZW1lcmdlZCB2aWN0b3Jpb3VzLg0KDQpTZWU6IGh0dHBzOi8vdHdpdHRlci5jb20vZWx3b3ovc3Rh
dHVzLzQwMTEzNTgxNDMwNzg4OTE1Mg0KRmlndXJlIDIgZnJvbSBodHRwOi8vZXByaW50LmlhY3Iu
b3JnLzIwMDAvMDI1DQoNCj4gR0NNIGhhcyBzb21lIGJhZCBkZXNpZ24gZmVhdHVyZXMsIGJ1dCBp
dHMgTUFDIGlzIHRoZSBnb29kIHBhcnQgKGF0IGxlYXN0IGZvcg0KPiBpbXBsZW1lbnRhdGlvbnMg
d2l0aCBoYXJkd2FyZSBzdXBwb3J0IGZvciBtdWx0aXBsaWNhdGlvbiBpbiBHRigyKVtYXSkuDQoN
CldoYXQgKmRvZXNuJ3QqIGxvb2sgZ29vZCBpZiB3ZSByZXN0cmljdCBvdXIgZGlzY3Vzc2lvbiB0
byBjb25maWd1cmF0aW9ucyB3aGljaCBoYXZlIGV4cGxpY2l0IGhhcmR3YXJlIHN1cHBvcnQ/DQoN
CldhaXQuLi5JJ2xsIGFuc3dlciB0aGF0OiBSQzQgOi0pDQogDQo+IFdpdGggYSBnb29kIGhhc2gg
ZnVuY3Rpb24gKG9uZSB3aGljaCBkb2VzIG5vdCBwZXJtaXQgdGhlIGxlbmd0aC1leHRlbnNpb24N
Cj4gYXR0YWNrKSwgc3VjaCBhcyBhbnkgb2YgdGhlIFNIQS0zIGZpbmFsaXN0cywgSChrLCBtKSBp
cyBhIGdvb2QgTUFDLg0KDQpXaGF0IGlmIChhcyBpbiB0aGUgVExTIGhhbmRzaGFrZSkgbSBpdHNl
bGYgd2FzIHVzZWQgdG8gbmVnb3RpYXRlIHRoZSBsZW5ndGggb2Ygaz8NCg0KLSBNYXJzaA0KVXN1
YWwgZGlzY2xhaW1lcnMgYXBwbHkuDQo=

From mrex@sap.com  Fri Nov 15 15:11:30 2013
Return-Path: <mrex@sap.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 9B61121F9B9F for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 15:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.049
X-Spam-Level: 
X-Spam-Status: No, score=-9.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8]
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 Y6m5X034jLwh for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 15:11:26 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 21E3C11E8128 for <tls@ietf.org>; Fri, 15 Nov 2013 15:11:25 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAFNBOkK023921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Nov 2013 00:11:24 +0100 (MET)
In-Reply-To: <CEAB081E.EFD2%kenny.paterson@rhul.ac.uk>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Date: Sat, 16 Nov 2013 00:11:24 +0100 (CET)
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: <20131115231124.0E9071AA9D@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 15 Nov 2013 23:11:30 -0000

Paterson, Kenny wrote:
> 
> "Martin Rex" <mrex@sap.com> wrote:
> >
> >The MAC provides integrity protection, the Encryption provides
> >confidentiality.  The quality of the MAC has exactly Zero impact
> >on the confidentiality provided by the Encryption.
> 
> The MAC is also necessary to preserve confidentiality in the face
> of active attacks.

That is a contortion of reality.  The MAC does not preserve anything
here.  The purpose of the MAC in communication protocols is to
mitigate the reaction/behaviour of the recipient of the communication
to become an oracle that can be polled quickly, repeatedly and often
to reveal fractions of bits of information that can be accumulated
by an attacker into disclosure of bytes of assumed confidential data.


> 
> If you need an example, consider the security history of IPsec's
> encryption-only modes. (Am I allowed to mention IPsec on a TLS list?
> Well, I just did.) 

The few things that I looked at were simple consequences of obviously
flawed assumptions, i.e. providing an oracle to the attacker and
no mechanism to stop an attacker from polling the oracle and learning.


Cryptographic algorithms have specific properties, and so do protocols
employing cryptographic algorithms.  Silently assuming that certain
properties will exist by accident/chance, rather than by explicit
design, is somewhat naive.  While it has been finally spelled
out in rfc5246 (TLSv1.2):

  http://tools.ietf.org/html/rfc5246#page-16

   Any protocol designed for use over TLS must be carefully designed to
   deal with all possible attacks against it.  As a practical matter,
   this means that the protocol designer must be aware of what security
   properties TLS does and does not provide and cannot safely rely on
   the latter.

a lot of consumers just don't get it.  They want to continue using
TLS as a magic pixie dust that provides universal security.


> 
> And, as far as I know, there are no significant attacks when IPsec is
> configured in encrypt-then-MAC configurations (e.g. ESP conf+auth or ESP
> followed by AH). On the other hand, all the configurations of IPsec where
> the MAC is applied before the encryption are broken. (Another
> demonstration that MAC-then-encrypt is not a robust choice.)


It is formally provable that MAC-then-encrypt for the existing symmetric
ciphers is at least as safe as encrypt-then-MAC.  The problem is, that
this applies only to _real_  MAC-then-encrypt, not to
any MAC-then-ExtendAndOtherStuff-then-Encrypt schemes that have
been used in IPsec and TLS, and are still being used in CMS|S/Mime
and WSSecurity, where additional unauthenticated data (e.g. padding)
is added after the MAC and before encryption, and where the recipient
will be offering a public decryption oracle.


> 
> >For EtA, the characteristics&quality of the Cipher do not affect
> >(and therefore can not improve) the quality of the MAC scheme
> >at all.
> 
> That's true but irrelevant, unless you don't trust your MAC algorithm. So
> why do you not trust HMAC-SHA256?

This isn't about the best-case scenarios, but about worst case scenarios,
i.e. HMAC-MD5.  The GHASH of AES-GCM by itself is weaker than HMAC-MD5,
but by being encrypted, the attacker can not take advantage of this.
An encrypted MAC will never be weaker than a plaintext MAC, but a
plaintext MAC may be turn out to be a weakness/vulnerability.


> 
> >Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
> >that does not have cryptographic hash properties (2nd paragraph Page 10):
> >
> >  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
> >
> >  GHASH is a keyed hash function but not, on its own, a cryptographic
> >  hash function. This Recommendation only approves GHASH for use within
> >  the context of GCM.
> >
> >The use of GHASH without cryptographic protection would not be safe.
> >
> 
> Also true. But guess what? In GCM, the GHASH MAC is computed on the
> ciphertext!

The point is, that the AES-GCM MAC _is_ encrypted, and sending it
unencrypted would not be a good idea.


>
> The GHASH output is then encrypted using a further invocation
> of the block cipher. Where does this leave your argument in favour of
> MAC-then-encrypt?

The MAC in TLS'es GenericBlockCipher ought to be left encrypted.
And to make code changes small, efficient and managable, going
from mac-pad-encrypt to pad-mac-encrypt, as Serge Vaudenay suggested,
is IMO the most reasonable way forward.


-Martin

From mike-list@pobox.com  Fri Nov 15 16:11:37 2013
Return-Path: <mike-list@pobox.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 7F7E811E8209 for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 16:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.904
X-Spam-Level: 
X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_42=0.6, SARE_SUB_OBFU_Q0=0.303]
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 O9aIrb-u+cml for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 16:11:32 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4E711E80E4 for <tls@ietf.org>; Fri, 15 Nov 2013 16:11:31 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E48F0EE35 for <tls@ietf.org>; Fri, 15 Nov 2013 19:11:29 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=PghvAHdorb01hahSjkLZFX7YY 2c=; b=cEJsfvFdHlZgirzaOAe1fdQKTA9R0QYRxjiEtEutDCcqtL9yIV+l/n9Vy 7NxA9ZaPfaWj6uORxkOd7hNAG0cPtLcqfIAO0xf6chTL6r0Of7p8pPRGxolQzCRC k+5TUQPEYzGKjNG9cfZjOowMxTDzNSYIFZBigMf4GCgXAV8dfc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=vvomLJwbbinHrUTv7Of pWjbxuKhnNL+a830FIp7VcTm1jaQbFgHgGnjM/9aVI0sVIpfWobsY76ncoyyEdsO ql9cuyKl3FL3YAprthgLdmnZFpRRiPyIthc82GpwL1G+Z3gE+0GvptFjHYQRa9op EjI6Z57RbQDuhPSYjcuP7fs4=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D8E3BEE34 for <tls@ietf.org>; Fri, 15 Nov 2013 19:11:29 -0500 (EST)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 164B8EE33 for <tls@ietf.org>; Fri, 15 Nov 2013 19:11:28 -0500 (EST)
Message-ID: <5286B82F.1030501@pobox.com>
Date: Fri, 15 Nov 2013 16:11:27 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: TLS Mailing List <tls@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: A3FD5E42-4E53-11E3-9464-F66B0E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Subject: [TLS] Dear @tqbf
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: Sat, 16 Nov 2013 00:11:37 -0000

Dear @tqbf,

Here's a quick profile of the guy you're making fun of on Twitter:

I have a B.S. and M.S. in electrical engineering.

In 1993, I dropped out of the PhD program at UCSB to start an Internet
company back when nobody outside academia or the government knew what the
Internet even was.

Our first product was an email server.  If you exchanged email with anybody
using AT&T's Worldnet email service in the mid- to late 90's, then my code
delivered your messages.

Just before Netscape Communications Corp. went public they realized they
needed an email server of their own.  Instead of building one, they had us
create a Netscape-branded version of our product for them.

If you were to ask Eric Allman what his motivation to improve sendmail was
(also in the mid- to late 1990's), he'd have to say it was our product.  We
eliminated whole classes of security problems by not running as root, not
interpreting email addresses as programs to be exec'ed by a shell, and having
a whitelist of programs (e.g. procmail) that were safe for mail processing.
There's also the bits of not losing mail or needing the cryptic sendmail.cf.

Related to this working group, I was probably the first person to fully
implement TLS 1.2 and put up a server online for people to test against.
This server was instrumental in helping Opera, Microsoft, Apple, CryptLib,
and others hone their own TLS 1.2 code.

I was approached to help with the renegotiation bug, though I did not accept
due to the fact that they couldn't tell me what they wanted help with at the
time.  Once the issue became public, I did join the team in finding a fix.
During that time I implemented no less than three different proposals in the
test server.

Despite what the haters of that time called the "TLS WG DDoS" due to the
lengthy and often heated discussions, we did end up with an extension that
fixed the problem.  Fixed it for all versions including SSLv3.  Is fairly
easy to implement, and is deployed and protecting users in over 80% of
servers (according to SSL Pulse[1]).

     [1] SSL Pulse:  https://www.trustworthyinternet.org/ssl-pulse/

So, you can see that I'm an engineer and not a cryptographer.  Anybody who
follows this list regularly knows that.  That's why I ask questions about
cryptography subjects.  I always read the opinions of the cryptographers on
this list, so that I can better understand the concepts.  And I welcome the
participation of the newer arrivals to this group.

On the specific question about "fixing" RC4, up until yesterday I understood
that the problem with RC4 was bias in the first part of the keystream and the
fact that TLS didn't drop the first several bytes of output.  So, when I saw
that there was a proposal to add padding to TLS records BEFORE the data, to
fix a problem with CBC mode (unauthenticated padding), I correlated that to
the RC4 problem I was aware of and thought perhaps this unrelated fix could
ALSO fix the problem with RC4.

I would be negligent if I hadn't asked the question!  And if it actually was
possible to improve RC4 in a backward-compatible way with a simple padding
fix, wouldn't that be the very definition of awesome?

But you seem to want to create an atmosphere where people are afraid to ask
any question where the answer might be "no" lest you make fun of them behind
their back.  I appreciate the fact that some people called you out on it.

Your stance appears to be the common, "just implement AES-GCM" since we know
it's secure.  Well, that would be great, but requires TLS 1.2 to be
implemented, along with an entirely new cipher mode (AEAD).  And if you
haven't already done so, you need to implement TLS 1.1 as well since a server
might choose that version.  And you need to implement AES-GCM.  And while
you're at it, don't forget elliptic curve cryptography because modular DH
groups are slower and limited to 1024 bits and we really like EC math.

Now throw in the uncertainty of a "TLS 2.0 Specification Competition" and who
in their right mind is going to go down that path?  They'd probably hold off
on any TLS 1.2 implementation plan (if they even have one) and wait to see
what the world-wide crypto community comes up with.

Meanwhile the attacks are getting better and deployed code is showing its age
more and more.  One quarter of sites still accept SSL version 2, almost 70%
are vulnerable to BEAST, and 1/3 currently require your unloved RC4.  (Again,
see SSL Pulse for the stats.)  Partially this must be due to the fact that
RC4 was THE recommended cipher suite, above all CBC ciphers, for SSL 3.0 and
TLS 1.0, until very recently.

So the logical thing to do (according to you) is not even TRY to see if RC4
can be improved in the interim between now and two years from now when we
finally start seeing wide deployment of code implementing the winner of the
hypothetical TLS competition.  Makes so much sense.

For the rest of the working group, the point (note that I tried very hard NOT
to send this message; my apologies) is that if you have a question, no matter
how dumb Mr. Ptacek will think you are, please ask it.  At least one member
of this working group won't make fun of you.

Mike


From patrick@patrickmn.com  Fri Nov 15 17:24:55 2013
Return-Path: <patrick@patrickmn.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 A3CFB11E810D for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 17:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.527
X-Spam-Level: 
X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q0=0.303]
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 wb1rcnR9j+fD for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 17:24:51 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 55E4711E80E9 for <tls@ietf.org>; Fri, 15 Nov 2013 17:24:51 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so570378wes.40 for <tls@ietf.org>; Fri, 15 Nov 2013 17:24:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D9ECKe9sahCN3DATMLnYheGBm9IbMTe9HWbf0EVI238=; b=FXX7imAd0uG6ENP5fx9Qz049+rjxR5UjToMkQJubFrqigH/hpEwpbIzE9l6IZNaI5T d+xB6eviwBY01RW3swEiaWGOpXB8OpOHy3nPxpfK0gu5xw0F8udNFQJAa2hLBdM6rrUQ nK5eF+OeLEhNINF6/xU38KOMQ4lAL6TBl0mFis+2n65wNRTpdJCINeq5w0a81HzOOR4j iMDIrSY8NSlDDnvKzM8Odrz0EwU6nTbQrrjOsz920jZwQY1aF071CqhJ51MA9/KlkUqX 85BDD+EYcHfPVv15hvN0eajDaL/APrxGn0P7pbCqFhaGhTzGf4PXIUyjICG3UWVJ5Gxm KLAg==
X-Gm-Message-State: ALoCoQksDeR9am2tNs71ZuXAcQ5NkfiZjfvYG+JV7PdblkCbgPUA8ci/q2LLVA6EOuGqwSk/prfC
MIME-Version: 1.0
X-Received: by 10.180.24.137 with SMTP id u9mr9287892wif.5.1384565089942; Fri, 15 Nov 2013 17:24:49 -0800 (PST)
Received: by 10.194.235.201 with HTTP; Fri, 15 Nov 2013 17:24:49 -0800 (PST)
In-Reply-To: <5286B82F.1030501@pobox.com>
References: <5286B82F.1030501@pobox.com>
Date: Fri, 15 Nov 2013 20:24:49 -0500
Message-ID: <CAEw2jfzvgZP73m1ST19d8PirwX9DZO=w=8=gEyr64DivLo3+3w@mail.gmail.com>
From: Patrick Mylund Nielsen <cryptography@patrickmylund.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Content-Type: multipart/alternative; boundary=f46d04447f675ad8df04eb412ebb
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [TLS] Dear @tqbf
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: Sat, 16 Nov 2013 01:25:38 -0000

--f46d04447f675ad8df04eb412ebb
Content-Type: text/plain; charset=UTF-8

On Fri, Nov 15, 2013 at 7:11 PM, Michael D'Errico <mike-list@pobox.com>wrote:

> Dear @tqbf,
>
> Here's a quick profile of the guy you're making fun of on Twitter:
>
> I have a B.S. and M.S. in electrical engineering.
>
> In 1993, I dropped out of the PhD program at UCSB to start an Internet
> company back when nobody outside academia or the government knew what the
> Internet even was.
>
> Our first product was an email server.  If you exchanged email with anybody
> using AT&T's Worldnet email service in the mid- to late 90's, then my code
> delivered your messages.
>
> Just before Netscape Communications Corp. went public they realized they
> needed an email server of their own.  Instead of building one, they had us
> create a Netscape-branded version of our product for them.
>
> If you were to ask Eric Allman what his motivation to improve sendmail was
> (also in the mid- to late 1990's), he'd have to say it was our product.  We
> eliminated whole classes of security problems by not running as root, not
> interpreting email addresses as programs to be exec'ed by a shell, and
> having
> a whitelist of programs (e.g. procmail) that were safe for mail processing.
> There's also the bits of not losing mail or needing the cryptic
> sendmail.cf.
>
> Related to this working group, I was probably the first person to fully
> implement TLS 1.2 and put up a server online for people to test against.
> This server was instrumental in helping Opera, Microsoft, Apple, CryptLib,
> and others hone their own TLS 1.2 code.
>
> I was approached to help with the renegotiation bug, though I did not
> accept
> due to the fact that they couldn't tell me what they wanted help with at
> the
> time.  Once the issue became public, I did join the team in finding a fix.
> During that time I implemented no less than three different proposals in
> the
> test server.
>
> Despite what the haters of that time called the "TLS WG DDoS" due to the
> lengthy and often heated discussions, we did end up with an extension that
> fixed the problem.  Fixed it for all versions including SSLv3.  Is fairly
> easy to implement, and is deployed and protecting users in over 80% of
> servers (according to SSL Pulse[1]).
>
>     [1] SSL Pulse:  https://www.trustworthyinternet.org/ssl-pulse/
>
> So, you can see that I'm an engineer and not a cryptographer.  Anybody who
> follows this list regularly knows that.  That's why I ask questions about
> cryptography subjects.  I always read the opinions of the cryptographers on
> this list, so that I can better understand the concepts.  And I welcome the
> participation of the newer arrivals to this group.
>
> On the specific question about "fixing" RC4, up until yesterday I
> understood
> that the problem with RC4 was bias in the first part of the keystream and
> the
> fact that TLS didn't drop the first several bytes of output.  So, when I
> saw
> that there was a proposal to add padding to TLS records BEFORE the data, to
> fix a problem with CBC mode (unauthenticated padding), I correlated that to
> the RC4 problem I was aware of and thought perhaps this unrelated fix could
> ALSO fix the problem with RC4.
>
> I would be negligent if I hadn't asked the question!  And if it actually
> was
> possible to improve RC4 in a backward-compatible way with a simple padding
> fix, wouldn't that be the very definition of awesome?
>
> But you seem to want to create an atmosphere where people are afraid to ask
> any question where the answer might be "no" lest you make fun of them
> behind
> their back.  I appreciate the fact that some people called you out on it.
>
> Your stance appears to be the common, "just implement AES-GCM" since we
> know
> it's secure.  Well, that would be great, but requires TLS 1.2 to be
> implemented, along with an entirely new cipher mode (AEAD).  And if you
> haven't already done so, you need to implement TLS 1.1 as well since a
> server
> might choose that version.  And you need to implement AES-GCM.  And while
> you're at it, don't forget elliptic curve cryptography because modular DH
> groups are slower and limited to 1024 bits and we really like EC math.
>
> Now throw in the uncertainty of a "TLS 2.0 Specification Competition" and
> who
> in their right mind is going to go down that path?  They'd probably hold
> off
> on any TLS 1.2 implementation plan (if they even have one) and wait to see
> what the world-wide crypto community comes up with.
>
> Meanwhile the attacks are getting better and deployed code is showing its
> age
> more and more.  One quarter of sites still accept SSL version 2, almost 70%
> are vulnerable to BEAST, and 1/3 currently require your unloved RC4.
>  (Again,
> see SSL Pulse for the stats.)  Partially this must be due to the fact that
> RC4 was THE recommended cipher suite, above all CBC ciphers, for SSL 3.0
> and
> TLS 1.0, until very recently.
>
> So the logical thing to do (according to you) is not even TRY to see if RC4
> can be improved in the interim between now and two years from now when we
> finally start seeing wide deployment of code implementing the winner of the
> hypothetical TLS competition.  Makes so much sense.
>
> For the rest of the working group, the point (note that I tried very hard
> NOT
> to send this message; my apologies) is that if you have a question, no
> matter
> how dumb Mr. Ptacek will think you are, please ask it.  At least one member
> of this working group won't make fun of you.
>
> Mike
>

I agree with you both:

1. If you ridicule somebody for asking questions, you just maintain the
status quo. It's useless and annoying. The security industry is bad at
this; Cryptography in academia is much better, at least in my experience.

Nobody knows everything. There is no reason you should be ridiculed for
asking a question, even if you "are supposed" to know the answer.

However,

2. If people see your advice as authoritative, or you are implementing
cryptography in software non-recreationally/in something people will use,
you deserve all the flak you get if you don't actually know how to
implement it, or what you are talking about. Cryptography is just about the
worst arena for reckless experimentation.

If the response you are referring to was because of your question,

> Would it be possible to "fix" RC4 using this extension?  Simply insert a
random amount (at least 256 bytes) of pseudo-random padding at the
beginning of the first record sent using an RC4 cipher suite?

then this seems to be a clear example of #1. Without knowing what tqbf is
thinking, I would guess that he understood it as you suggesting it is done,
rather than simply asking a genuine question to understand if it's
possible. I know that a lot of the time he is responding to people who are
arguing, confidently, points they do not (even fundamentally) understand,
but which end up affecting (most often negatively) thousands of innocent
consumers.

--f46d04447f675ad8df04eb412ebb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Nov 15, 2013 at 7:11 PM, Michael D&#39;Errico <span dir=3D"ltr">&lt;<a =
href=3D"mailto:mike-list@pobox.com" target=3D"_blank">mike-list@pobox.com</=
a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">Dear @tqbf,<br>
<br>
Here&#39;s a quick profile of the guy you&#39;re making fun of on Twitter:<=
br>
<br>
I have a B.S. and M.S. in electrical engineering.<br>
<br>
In 1993, I dropped out of the PhD program at UCSB to start an Internet<br>
company back when nobody outside academia or the government knew what the<b=
r>
Internet even was.<br>
<br>
Our first product was an email server. =C2=A0If you exchanged email with an=
ybody<br>
using AT&amp;T&#39;s Worldnet email service in the mid- to late 90&#39;s, t=
hen my code<br>
delivered your messages.<br>
<br>
Just before Netscape Communications Corp. went public they realized they<br=
>
needed an email server of their own. =C2=A0Instead of building one, they ha=
d us<br>
create a Netscape-branded version of our product for them.<br>
<br>
If you were to ask Eric Allman what his motivation to improve sendmail was<=
br>
(also in the mid- to late 1990&#39;s), he&#39;d have to say it was our prod=
uct. =C2=A0We<br>
eliminated whole classes of security problems by not running as root, not<b=
r>
interpreting email addresses as programs to be exec&#39;ed by a shell, and =
having<br>
a whitelist of programs (e.g. procmail) that were safe for mail processing.=
<br>
There&#39;s also the bits of not losing mail or needing the cryptic <a href=
=3D"http://sendmail.cf" target=3D"_blank">sendmail.cf</a>.<br>
<br>
Related to this working group, I was probably the first person to fully<br>
implement TLS 1.2 and put up a server online for people to test against.<br=
>
This server was instrumental in helping Opera, Microsoft, Apple, CryptLib,<=
br>
and others hone their own TLS 1.2 code.<br>
<br>
I was approached to help with the renegotiation bug, though I did not accep=
t<br>
due to the fact that they couldn&#39;t tell me what they wanted help with a=
t the<br>
time. =C2=A0Once the issue became public, I did join the team in finding a =
fix.<br>
During that time I implemented no less than three different proposals in th=
e<br>
test server.<br>
<br>
Despite what the haters of that time called the &quot;TLS WG DDoS&quot; due=
 to the<br>
lengthy and often heated discussions, we did end up with an extension that<=
br>
fixed the problem. =C2=A0Fixed it for all versions including SSLv3. =C2=A0I=
s fairly<br>
easy to implement, and is deployed and protecting users in over 80% of<br>
servers (according to SSL Pulse[1]).<br>
<br>
=C2=A0 =C2=A0 [1] SSL Pulse: =C2=A0<a href=3D"https://www.trustworthyintern=
et.org/ssl-pulse/" target=3D"_blank">https://www.<u></u>trustworthyinternet=
.org/ssl-<u></u>pulse/</a><br>
<br>
So, you can see that I&#39;m an engineer and not a cryptographer. =C2=A0Any=
body who<br>
follows this list regularly knows that. =C2=A0That&#39;s why I ask question=
s about<br>
cryptography subjects. =C2=A0I always read the opinions of the cryptographe=
rs on<br>
this list, so that I can better understand the concepts. =C2=A0And I welcom=
e the<br>
participation of the newer arrivals to this group.<br>
<br>
On the specific question about &quot;fixing&quot; RC4, up until yesterday I=
 understood<br>
that the problem with RC4 was bias in the first part of the keystream and t=
he<br>
fact that TLS didn&#39;t drop the first several bytes of output. =C2=A0So, =
when I saw<br>
that there was a proposal to add padding to TLS records BEFORE the data, to=
<br>
fix a problem with CBC mode (unauthenticated padding), I correlated that to=
<br>
the RC4 problem I was aware of and thought perhaps this unrelated fix could=
<br>
ALSO fix the problem with RC4.<br>
<br>
I would be negligent if I hadn&#39;t asked the question! =C2=A0And if it ac=
tually was<br>
possible to improve RC4 in a backward-compatible way with a simple padding<=
br>
fix, wouldn&#39;t that be the very definition of awesome?<br>
<br>
But you seem to want to create an atmosphere where people are afraid to ask=
<br>
any question where the answer might be &quot;no&quot; lest you make fun of =
them behind<br>
their back. =C2=A0I appreciate the fact that some people called you out on =
it.<br>
<br>
Your stance appears to be the common, &quot;just implement AES-GCM&quot; si=
nce we know<br>
it&#39;s secure. =C2=A0Well, that would be great, but requires TLS 1.2 to b=
e<br>
implemented, along with an entirely new cipher mode (AEAD). =C2=A0And if yo=
u<br>
haven&#39;t already done so, you need to implement TLS 1.1 as well since a =
server<br>
might choose that version. =C2=A0And you need to implement AES-GCM. =C2=A0A=
nd while<br>
you&#39;re at it, don&#39;t forget elliptic curve cryptography because modu=
lar DH<br>
groups are slower and limited to 1024 bits and we really like EC math.<br>
<br>
Now throw in the uncertainty of a &quot;TLS 2.0 Specification Competition&q=
uot; and who<br>
in their right mind is going to go down that path? =C2=A0They&#39;d probabl=
y hold off<br>
on any TLS 1.2 implementation plan (if they even have one) and wait to see<=
br>
what the world-wide crypto community comes up with.<br>
<br>
Meanwhile the attacks are getting better and deployed code is showing its a=
ge<br>
more and more. =C2=A0One quarter of sites still accept SSL version 2, almos=
t 70%<br>
are vulnerable to BEAST, and 1/3 currently require your unloved RC4. =C2=A0=
(Again,<br>
see SSL Pulse for the stats.) =C2=A0Partially this must be due to the fact =
that<br>
RC4 was THE recommended cipher suite, above all CBC ciphers, for SSL 3.0 an=
d<br>
TLS 1.0, until very recently.<br>
<br>
So the logical thing to do (according to you) is not even TRY to see if RC4=
<br>
can be improved in the interim between now and two years from now when we<b=
r>
finally start seeing wide deployment of code implementing the winner of the=
<br>
hypothetical TLS competition. =C2=A0Makes so much sense.<br>
<br>
For the rest of the working group, the point (note that I tried very hard N=
OT<br>
to send this message; my apologies) is that if you have a question, no matt=
er<br>
how dumb Mr. Ptacek will think you are, please ask it. =C2=A0At least one m=
ember<br>
of this working group won&#39;t make fun of you.<br>
<br>
Mike<br></blockquote><div><br></div><div>I agree with you both:</div><div><=
br></div><div>1. If you ridicule somebody for asking questions, you just ma=
intain the status quo. It&#39;s useless and annoying. The security industry=
 is bad at this; Cryptography in academia is much better, at least in my ex=
perience.</div>
<div><br></div><div>Nobody knows everything. There is no reason you should =
be ridiculed for asking a question, even if you &quot;are supposed&quot; to=
 know the answer.</div>
<div><br></div><div>However,</div>

<div><br></div><div>2. If people see your advice as authoritative, or you a=
re implementing cryptography in software non-recreationally/in something pe=
ople will use, you deserve all the flak you get if you don&#39;t actually k=
now how to implement it, or what you are talking about. Cryptography is jus=
t about the worst arena for reckless experimentation.</div>


<div><br></div><div>If the response you are referring to was because of you=
r question,</div><div><br></div><div>&gt; Would it be possible to &quot;fix=
&quot; RC4 using this extension? =C2=A0Simply insert a random amount (at le=
ast 256 bytes) of pseudo-random padding at the beginning of the first recor=
d sent using an RC4 cipher suite?<br>
</div><div><br></div><div>then this seems to be a clear example of #1. With=
out knowing what tqbf is thinking, I would guess that he understood it as y=
ou suggesting it is done, rather than simply asking a genuine question to u=
nderstand if it&#39;s possible. I know that a lot of the time he is respond=
ing to people who are arguing, confidently, points they do not (even fundam=
entally) understand, but which end up affecting (most often negatively) tho=
usands of innocent consumers.</div>

</div></div></div>

--f46d04447f675ad8df04eb412ebb--

From maray@microsoft.com  Fri Nov 15 18:45:01 2013
Return-Path: <maray@microsoft.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 AD56D11E813A for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 18:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.403
X-Spam-Level: 
X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_05=-1.11, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q0=0.303]
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 JVigelSCRnNf for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 18:44:57 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7D11E810B for <tls@ietf.org>; Fri, 15 Nov 2013 18:44:57 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sat, 16 Nov 2013 02:44:55 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) with mapi id 15.00.0820.005; Sat, 16 Nov 2013 02:44:54 +0000
From: Marsh Ray <maray@microsoft.com>
To: Michael D'Errico <mike-list@pobox.com>, TLS Mailing List <tls@ietf.org>
Thread-Topic: [TLS] Dear @tqbf
Thread-Index: AQHO4mB29zTAF07uGE+mDu8vfSccL5onH3UQ
Date: Sat, 16 Nov 2013 02:44:54 +0000
Message-ID: <74fc29c26fca4f289f5a4c8447297fbb@BY2PR03MB074.namprd03.prod.outlook.com>
References: <5286B82F.1030501@pobox.com>
In-Reply-To: <5286B82F.1030501@pobox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.192.79]
x-o365ent-eop-header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(13464003)(377454003)(50894002)(189002)(199002)(87266001)(31966008)(74662001)(63696002)(74502001)(2656002)(74706001)(46102001)(81342001)(81542001)(74876001)(81686001)(85306002)(69226001)(54316002)(56776001)(59766001)(47446002)(51856001)(77982001)(76482001)(83322001)(83072001)(19580395003)(56816003)(54356001)(53806001)(47736001)(49866001)(4396001)(47976001)(50986001)(66066001)(79102001)(15975445006)(80022001)(77096001)(81816001)(76576001)(80976001)(76786001)(76796001)(19580405001)(87936001)(65816001)(33646001)(561944002)(74316001)(74366001)(221513003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:131.107.192.79; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Subject: Re: [TLS] Dear @tqbf
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: Sat, 16 Nov 2013 02:45:01 -0000

We love you Mike but you left out the part about:

* you implementing an entire TLS stack from scratch

* your experiments analyzing SHA-N performance on FPGAs, and

* that time we sat at the banquet table at Defcon and hacked the conference=
 badge embedded system and brute forced the all the ninja party invite code=
s and posted them online and when we went to the party the badge scanner ha=
d been shut down thus exposing that the real party invites were paper based=
 and the whole thing was just security theater.

@tqbf was being a sarcastic ass. He was making fun of the entire WG, not ju=
st you specifically. If he's really so smart he'd show up here and offer on=
e useful contribution for every 9 darts he throws.

- Marsh
Usual disclaimers apply.

P.S. I thought the question you posed about RC4 was entirely appropriate.



> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Michael D'Errico
> Sent: Friday, November 15, 2013 4:11 PM
> To: TLS Mailing List
> Subject: [TLS] Dear @tqbf
>=20
> Dear @tqbf,
>=20
> Here's a quick profile of the guy you're making fun of on Twitter:
>=20
> I have a B.S. and M.S. in electrical engineering.
>=20
> In 1993, I dropped out of the PhD program at UCSB to start an Internet
> company back when nobody outside academia or the government knew
> what the Internet even was.
>=20
> Our first product was an email server.  If you exchanged email with anybo=
dy
> using AT&T's Worldnet email service in the mid- to late 90's, then my cod=
e
> delivered your messages.
>=20
> Just before Netscape Communications Corp. went public they realized they
> needed an email server of their own.  Instead of building one, they had u=
s
> create a Netscape-branded version of our product for them.
>=20
> If you were to ask Eric Allman what his motivation to improve sendmail wa=
s
> (also in the mid- to late 1990's), he'd have to say it was our product.  =
We
> eliminated whole classes of security problems by not running as root, not
> interpreting email addresses as programs to be exec'ed by a shell, and ha=
ving
> a whitelist of programs (e.g. procmail) that were safe for mail processin=
g.
> There's also the bits of not losing mail or needing the cryptic sendmail.=
cf.
>=20
> Related to this working group, I was probably the first person to fully
> implement TLS 1.2 and put up a server online for people to test against.
> This server was instrumental in helping Opera, Microsoft, Apple, CryptLib=
,
> and others hone their own TLS 1.2 code.
>=20
> I was approached to help with the renegotiation bug, though I did not acc=
ept
> due to the fact that they couldn't tell me what they wanted help with at =
the
> time.  Once the issue became public, I did join the team in finding a fix=
.
> During that time I implemented no less than three different proposals in =
the
> test server.
>=20
> Despite what the haters of that time called the "TLS WG DDoS" due to the
> lengthy and often heated discussions, we did end up with an extension tha=
t
> fixed the problem.  Fixed it for all versions including SSLv3.  Is fairly=
 easy to
> implement, and is deployed and protecting users in over 80% of servers
> (according to SSL Pulse[1]).
>=20
>      [1] SSL Pulse:  https://www.trustworthyinternet.org/ssl-pulse/
>=20
> So, you can see that I'm an engineer and not a cryptographer.  Anybody wh=
o
> follows this list regularly knows that.  That's why I ask questions about
> cryptography subjects.  I always read the opinions of the cryptographers =
on
> this list, so that I can better understand the concepts.  And I welcome t=
he
> participation of the newer arrivals to this group.
>=20
> On the specific question about "fixing" RC4, up until yesterday I underst=
ood
> that the problem with RC4 was bias in the first part of the keystream and=
 the
> fact that TLS didn't drop the first several bytes of output.  So, when I =
saw that
> there was a proposal to add padding to TLS records BEFORE the data, to fi=
x a
> problem with CBC mode (unauthenticated padding), I correlated that to the
> RC4 problem I was aware of and thought perhaps this unrelated fix could
> ALSO fix the problem with RC4.
>=20
> I would be negligent if I hadn't asked the question!  And if it actually =
was
> possible to improve RC4 in a backward-compatible way with a simple paddin=
g
> fix, wouldn't that be the very definition of awesome?
>=20
> But you seem to want to create an atmosphere where people are afraid to
> ask any question where the answer might be "no" lest you make fun of them
> behind their back.  I appreciate the fact that some people called you out=
 on
> it.
>=20
> Your stance appears to be the common, "just implement AES-GCM" since we
> know it's secure.  Well, that would be great, but requires TLS 1.2 to be
> implemented, along with an entirely new cipher mode (AEAD).  And if you
> haven't already done so, you need to implement TLS 1.1 as well since a
> server might choose that version.  And you need to implement AES-GCM.
> And while you're at it, don't forget elliptic curve cryptography because
> modular DH groups are slower and limited to 1024 bits and we really like =
EC
> math.
>=20
> Now throw in the uncertainty of a "TLS 2.0 Specification Competition" and
> who in their right mind is going to go down that path?  They'd probably h=
old
> off on any TLS 1.2 implementation plan (if they even have one) and wait t=
o
> see what the world-wide crypto community comes up with.
>=20
> Meanwhile the attacks are getting better and deployed code is showing its
> age more and more.  One quarter of sites still accept SSL version 2, almo=
st
> 70% are vulnerable to BEAST, and 1/3 currently require your unloved RC4.
> (Again, see SSL Pulse for the stats.)  Partially this must be due to the =
fact that
> RC4 was THE recommended cipher suite, above all CBC ciphers, for SSL 3.0
> and TLS 1.0, until very recently.
>=20
> So the logical thing to do (according to you) is not even TRY to see if R=
C4 can
> be improved in the interim between now and two years from now when we
> finally start seeing wide deployment of code implementing the winner of t=
he
> hypothetical TLS competition.  Makes so much sense.
>=20
> For the rest of the working group, the point (note that I tried very hard=
 NOT
> to send this message; my apologies) is that if you have a question, no ma=
tter
> how dumb Mr. Ptacek will think you are, please ask it.  At least one memb=
er
> of this working group won't make fun of you.
>=20
> Mike
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From bryan@ravensight.org  Fri Nov 15 20:53:01 2013
Return-Path: <bryan@ravensight.org>
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 53A8811E8175 for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 20:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.696
X-Spam-Level: 
X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q0=0.303]
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 zcjpijj28swO for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 20:52:57 -0800 (PST)
Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id D27F211E8168 for <tls@ietf.org>; Fri, 15 Nov 2013 20:52:56 -0800 (PST)
Received: by mail-oa0-f51.google.com with SMTP id i4so4965530oah.10 for <tls@ietf.org>; Fri, 15 Nov 2013 20:52:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=Ne2YzX3tF10NDznIyTYCPymZNuY3Elh4o+mjZLbaXw4=; b=S/ppwqr9nmW9oqbuWZXfeJMkLN/SyAB5439nPiBrAOctXanMc9wI7bfxUWIlJ40Qlg gHGxvcim8cjmnHIe09Zeapok/bnSeK6T6lc9CCQR5AmpQcqne390HYfxRfCTOnzEHt4t UFQt3iIe4Xn05S/MwPmgN8SEcxP+U6l9MXsYB7XazpNNKVn+CSc48kwreyhM++51ITKO urv0RegcXYOkIQOFAdiK2qS/a2kB54dwUr6dzWkQa1bppWtvwSJrQwbhZfJuFx/4nXpR BwuYrHqzCchCBjoWjNzjBRusXPG2awUmDhe3ZxSbQsXcI/7+3AOVP/CuXdTrHCr2yyqG hN0A==
X-Gm-Message-State: ALoCoQl8PnAmg/aP/unoXAbptl4WhiVcQN//ejB8UnMHnPIXYD7wn1c0va4M+2hqAEVp54xO6cqm
X-Received: by 10.60.149.169 with SMTP id ub9mr10058207oeb.39.1384577576236; Fri, 15 Nov 2013 20:52:56 -0800 (PST)
Received: from Genie (108-202-93-53.lightspeed.mssnks.sbcglobal.net. [108.202.93.53]) by mx.google.com with ESMTPSA id r6sm8244048obi.14.2013.11.15.20.52.55 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Nov 2013 20:52:55 -0800 (PST)
From: "Bryan C. Geraghty" <bryan@ravensight.org>
To: "'TLS Mailing List'" <tls@ietf.org>
References: <5286B82F.1030501@pobox.com> <74fc29c26fca4f289f5a4c8447297fbb@BY2PR03MB074.namprd03.prod.outlook.com>
In-Reply-To: <74fc29c26fca4f289f5a4c8447297fbb@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Fri, 15 Nov 2013 22:52:55 -0600
Message-ID: <001e01cee287$b759c8a0$260d59e0$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHO4mB29zTAF07uGE+mDu8vfSccL5onH3UQgAAXjoA=
Content-Language: en-us
Subject: Re: [TLS] Dear @tqbf
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: Sat, 16 Nov 2013 04:53:01 -0000

Mike, 

I respect your past contributions. However, I recommend the next time you
get heated, you walk away from the keyboard. Yes, Tom was being sarcastic
but this is no better; possibly worse. I tried to pick apart all of the
rhetoric you employed in your post and couldn't take it anymore. 

What this all comes down to are these points:

* You have a lot of valuable experience implementing TLS but don't fully
understand the crypto
* Tom and his team have a lot of experience breaking crypto and protocols
* TLS is crumbling under improving analysis & attacks
* Other people on this list are arguing (not just asking) about things that
were proven 10 years ago

Where do we go from here?

Bryan

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Marsh
Ray
Sent: Friday, November 15, 2013 8:45 PM
To: Michael D'Errico; TLS Mailing List
Subject: Re: [TLS] Dear @tqbf

We love you Mike but you left out the part about:

* you implementing an entire TLS stack from scratch

* your experiments analyzing SHA-N performance on FPGAs, and

* that time we sat at the banquet table at Defcon and hacked the conference
badge embedded system and brute forced the all the ninja party invite codes
and posted them online and when we went to the party the badge scanner had
been shut down thus exposing that the real party invites were paper based
and the whole thing was just security theater.

@tqbf was being a sarcastic ass. He was making fun of the entire WG, not
just you specifically. If he's really so smart he'd show up here and offer
one useful contribution for every 9 darts he throws.

- Marsh
Usual disclaimers apply.

P.S. I thought the question you posed about RC4 was entirely appropriate.


> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of 
> Michael D'Errico
> Sent: Friday, November 15, 2013 4:11 PM
> To: TLS Mailing List
> Subject: [TLS] Dear @tqbf
> 
> Dear @tqbf,
> 
> Here's a quick profile of the guy you're making fun of on Twitter:
> 
> I have a B.S. and M.S. in electrical engineering.
> 
> In 1993, I dropped out of the PhD program at UCSB to start an Internet 
> company back when nobody outside academia or the government knew what 
> the Internet even was.
> 
> Our first product was an email server.  If you exchanged email with 
> anybody using AT&T's Worldnet email service in the mid- to late 90's, 
> then my code delivered your messages.
> 
> Just before Netscape Communications Corp. went public they realized 
> they needed an email server of their own.  Instead of building one, 
> they had us create a Netscape-branded version of our product for them.
> 
> If you were to ask Eric Allman what his motivation to improve sendmail 
> was (also in the mid- to late 1990's), he'd have to say it was our 
> product.  We eliminated whole classes of security problems by not 
> running as root, not interpreting email addresses as programs to be 
> exec'ed by a shell, and having a whitelist of programs (e.g. procmail)
that were safe for mail processing.
> There's also the bits of not losing mail or needing the cryptic
sendmail.cf.
> 
> Related to this working group, I was probably the first person to 
> fully implement TLS 1.2 and put up a server online for people to test
against.
> This server was instrumental in helping Opera, Microsoft, Apple, 
> CryptLib, and others hone their own TLS 1.2 code.
> 
> I was approached to help with the renegotiation bug, though I did not 
> accept due to the fact that they couldn't tell me what they wanted 
> help with at the time.  Once the issue became public, I did join the team
in finding a fix.
> During that time I implemented no less than three different proposals 
> in the test server.
> 
> Despite what the haters of that time called the "TLS WG DDoS" due to 
> the lengthy and often heated discussions, we did end up with an 
> extension that fixed the problem.  Fixed it for all versions including 
> SSLv3.  Is fairly easy to implement, and is deployed and protecting 
> users in over 80% of servers (according to SSL Pulse[1]).
> 
>      [1] SSL Pulse:  https://www.trustworthyinternet.org/ssl-pulse/
> 
> So, you can see that I'm an engineer and not a cryptographer.  Anybody 
> who follows this list regularly knows that.  That's why I ask 
> questions about cryptography subjects.  I always read the opinions of 
> the cryptographers on this list, so that I can better understand the 
> concepts.  And I welcome the participation of the newer arrivals to this
group.
> 
> On the specific question about "fixing" RC4, up until yesterday I 
> understood that the problem with RC4 was bias in the first part of the 
> keystream and the fact that TLS didn't drop the first several bytes of 
> output.  So, when I saw that there was a proposal to add padding to 
> TLS records BEFORE the data, to fix a problem with CBC mode 
> (unauthenticated padding), I correlated that to the
> RC4 problem I was aware of and thought perhaps this unrelated fix 
> could ALSO fix the problem with RC4.
> 
> I would be negligent if I hadn't asked the question!  And if it 
> actually was possible to improve RC4 in a backward-compatible way with 
> a simple padding fix, wouldn't that be the very definition of awesome?
> 
> But you seem to want to create an atmosphere where people are afraid 
> to ask any question where the answer might be "no" lest you make fun 
> of them behind their back.  I appreciate the fact that some people 
> called you out on it.
> 
> Your stance appears to be the common, "just implement AES-GCM" since 
> we know it's secure.  Well, that would be great, but requires TLS 1.2 
> to be implemented, along with an entirely new cipher mode (AEAD).  And 
> if you haven't already done so, you need to implement TLS 1.1 as well 
> since a server might choose that version.  And you need to implement
AES-GCM.
> And while you're at it, don't forget elliptic curve cryptography 
> because modular DH groups are slower and limited to 1024 bits and we 
> really like EC math.
> 
> Now throw in the uncertainty of a "TLS 2.0 Specification Competition" 
> and who in their right mind is going to go down that path?  They'd 
> probably hold off on any TLS 1.2 implementation plan (if they even 
> have one) and wait to see what the world-wide crypto community comes up
with.
> 
> Meanwhile the attacks are getting better and deployed code is showing 
> its age more and more.  One quarter of sites still accept SSL version 
> 2, almost 70% are vulnerable to BEAST, and 1/3 currently require your
unloved RC4.
> (Again, see SSL Pulse for the stats.)  Partially this must be due to 
> the fact that
> RC4 was THE recommended cipher suite, above all CBC ciphers, for SSL 
> 3.0 and TLS 1.0, until very recently.
> 
> So the logical thing to do (according to you) is not even TRY to see 
> if RC4 can be improved in the interim between now and two years from 
> now when we finally start seeing wide deployment of code implementing 
> the winner of the hypothetical TLS competition.  Makes so much sense.
> 
> For the rest of the working group, the point (note that I tried very 
> hard NOT to send this message; my apologies) is that if you have a 
> question, no matter how dumb Mr. Ptacek will think you are, please ask 
> it.  At least one member of this working group won't make fun of you.
> 
> Mike
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


From watsonbladd@gmail.com  Fri Nov 15 20:53:38 2013
Return-Path: <watsonbladd@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 EF7FE11E81CA for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 20:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.741
X-Spam-Level: 
X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 i3hcM3eBOnfO for <tls@ietfa.amsl.com>; Fri, 15 Nov 2013 20:53:38 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB111E81C4 for <tls@ietf.org>; Fri, 15 Nov 2013 20:53:33 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id ey16so1849135wid.7 for <tls@ietf.org>; Fri, 15 Nov 2013 20:53:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OD4BDgEoUkU029ZDvrL0pxQFb5QWUqqaZAyCsPgXKlg=; b=cHiC1w/35pjtVePGv2iiK2jNhe/iY55B5bdli2jZFVaEkXKAgGXdAjU9TDAt6E0Okh eRKeQI4o3aOPyqfeQNGsVdOOFuSnfvkHSe3cdFHHVrxCOnSu3B71bVb9ywkzHB4eF/a4 sKum+po3P1E+bjkCrlnPTrr99Sav3riGoaidzmWEA50EGbP5tVorgXvO2gn/MIqtxPV8 F7rRqlE+wxkRp1hArlObrH919grwk3qiwX8UN3LCe5ILmU0qFsF0kOtRWNyiOV3ytZhD 9Gp102+jTACYOP+uDAAaSo3zuY/nfg5EUnnxS+jb1CwPb0pP8iHpyjSiLWGZPXHI0XQ0 W8ZQ==
MIME-Version: 1.0
X-Received: by 10.194.178.6 with SMTP id cu6mr3005580wjc.61.1384577612970; Fri, 15 Nov 2013 20:53:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 15 Nov 2013 20:53:32 -0800 (PST)
Date: Fri, 15 Nov 2013 20:53:32 -0800
Message-ID: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] This working group has failed
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: Sat, 16 Nov 2013 04:53:39 -0000

In the past decade there have been many attacks against TLS.
With the exception of CRIME, not one of them relied on any results
that were not known
at the time the TLS 1.0 standard was being written. (See the citations
for the RC4 paper to see this, or the infamous Rogaway email about AtE
vs EtA). Every time this standards group has had a choice to make
regarding cryptography, they have made the wrong one. Even AES-GCM got
screwed up: nonces should be counters, but all implementations make
them random, introducing an artificial birthday bound issue due to
truncation in the standard.

TLS is solving the deadest of dead problems in cryptography: using the
PKI to establish a secure channel between two endpoints. Diffie and
Hellman solved this in their paper. Were TLS to be submitted by an
undergraduate as a solution to this problem it would earn an F.
Implementers such as AGL are bypassing the WG, choosing to emit I-Ds
and implementing and deploying because there is little to be gained
from WG discussions. This is not necessarily a bad thing, but it does
raise a question of whether what is good for Google is good for the
Web as a whole.

What problems would a hypothetical competition solve that TLS 1.2
hasn't already? Let's deal with real problems: TLS 1.2 is not getting
deployed, RC4 is still out there, the handshake protocol takes too
many round trips and is very hard to implement in an interoperable way
due to options, all the implementations with modern cryptographic
support have sucky APIs that make it impossible for ordinary
developers to use correctly, etc. All of this I have said before as
main priorities, but they are the biggest issues affecting us today. I
propose that a chair (do we have one?) convene a meeting via IRC or in
person at some convenient event to determine what problems should be
priorities, and then we will address them.

There are a few good points: I am glad to see that major vendors are
represented on this list, and are generally willing to work together
to insure interoperability and remove obstacles to improving internet
security. I am also glad to see that we are acutely aware of the
issues currently threatening the lives and property of internet users.

Sincerely,
Watson

From hannes.tschofenig@gmx.net  Sat Nov 16 02:14:26 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 DF05F11E810A for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 02:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Ts0x1t3u3umf for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 02:14:22 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id B145F11E8103 for <tls@ietf.org>; Sat, 16 Nov 2013 02:14:16 -0800 (PST)
Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LmrZY-1VE5Up0hWm-00h4Gr for <tls@ietf.org>; Sat, 16 Nov 2013 11:14:15 +0100
Message-ID: <52874576.9000708@gmx.net>
Date: Sat, 16 Nov 2013 11:14:14 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
In-Reply-To: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:7gVKZOvdAfuItSerwnTRqqX+m/8d41oYv7gV85pVlb27RGxdUyd vQXLCS/Gcl+rpcAgbu5q6B4tID1owJCP5WWZPDEF9W8WY5VPOq0ilESaAjqzZvcSDqWlngi bvp7TfRBrSFHXJkuFrXIf7YmIZS+IwR6YzY6PdqKfPXwxGH/d8E7ajAtTVxyMlSaIn4Nucf kZKYeFV2+JVatYNsETz1g==
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] Deployment ... Re:  This working group has failed
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: Sat, 16 Nov 2013 10:14:27 -0000

Hi Watson,

I understand your frustration and I wanted to pick up one point that you 
raised, namely why does it take so long to get TLS versions and 
extensions deployed.

I had recently a chat with a friend, Thomas Schreck who works for the 
Siemens CERT, and in the discussion about TLS I told him that he needs 
to deploy TLS 1.2 inside the company. He responded to me that support 
for TLS 1.2 has only been added to OpenSSL last year (which seems to be 
correct when I check the change logs where the initial support has been 
added with version 1.0.1).

The TLS 1.2 spec was, however, finished in 2008.

Having the code in the library is only the first step since then all the 
applications that use the library also need to be updated (re-compliled 
at least and shipped). Hard to say how long that takes and depends on 
the application and the company.

To be positive and constructive in the discussion I wonder what could be 
done to improve the situation.

Does the OpenSSL and the GnuTLS projects (and other projects) need more 
contributors?

Is there more awareness building needed to get companies to understand 
what the different libraries provide and why they should use a 
particular version?

Where does the delay come from?

Ciao
Hannes

Am 16.11.13 05:53, schrieb Watson Ladd:
> In the past decade there have been many attacks against TLS.
> With the exception of CRIME, not one of them relied on any results
> that were not known
> at the time the TLS 1.0 standard was being written. (See the citations
> for the RC4 paper to see this, or the infamous Rogaway email about AtE
> vs EtA). Every time this standards group has had a choice to make
> regarding cryptography, they have made the wrong one. Even AES-GCM got
> screwed up: nonces should be counters, but all implementations make
> them random, introducing an artificial birthday bound issue due to
> truncation in the standard.
>
> TLS is solving the deadest of dead problems in cryptography: using the
> PKI to establish a secure channel between two endpoints. Diffie and
> Hellman solved this in their paper. Were TLS to be submitted by an
> undergraduate as a solution to this problem it would earn an F.
> Implementers such as AGL are bypassing the WG, choosing to emit I-Ds
> and implementing and deploying because there is little to be gained
> from WG discussions. This is not necessarily a bad thing, but it does
> raise a question of whether what is good for Google is good for the
> Web as a whole.
>
> What problems would a hypothetical competition solve that TLS 1.2
> hasn't already? Let's deal with real problems: TLS 1.2 is not getting
> deployed, RC4 is still out there, the handshake protocol takes too
> many round trips and is very hard to implement in an interoperable way
> due to options, all the implementations with modern cryptographic
> support have sucky APIs that make it impossible for ordinary
> developers to use correctly, etc. All of this I have said before as
> main priorities, but they are the biggest issues affecting us today. I
> propose that a chair (do we have one?) convene a meeting via IRC or in
> person at some convenient event to determine what problems should be
> priorities, and then we will address them.
>
> There are a few good points: I am glad to see that major vendors are
> represented on this list, and are generally willing to work together
> to insure interoperability and remove obstacles to improving internet
> security. I am also glad to see that we are acutely aware of the
> issues currently threatening the lives and property of internet users.
>
> Sincerely,
> Watson
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From havoc@defuse.ca  Sat Nov 16 10:10:03 2013
Return-Path: <havoc@defuse.ca>
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 134B711E8100 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 10:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 4HAiWrFzufGb for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 10:09:58 -0800 (PST)
Received: from defuse.ca (defuse.ca [192.99.8.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4211E80E3 for <tls@ietf.org>; Sat, 16 Nov 2013 10:09:57 -0800 (PST)
Received: from [192.168.1.102] (S01065404a6902716.cg.shawcable.net [174.0.254.229]) by defuse.ca (Postfix) with ESMTPSA id B7A621006D1 for <tls@ietf.org>; Sat, 16 Nov 2013 13:10:05 -0500 (EST)
Message-ID: <5287B4F6.1060102@defuse.ca>
Date: Sat, 16 Nov 2013 11:09:58 -0700
From: Taylor Hornby <havoc@defuse.ca>
Organization: https://defuse.ca/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net>
In-Reply-To: <52874576.9000708@gmx.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Deployment ... Re:  This working group has failed
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: Sat, 16 Nov 2013 18:10:03 -0000

On 11/16/2013 03:14 AM, Hannes Tschofenig wrote:
> To be positive and constructive in the discussion I wonder what could be
> done to improve the situation.
> 
> Does the OpenSSL and the GnuTLS projects (and other projects) need more
> contributors?
> 
> Is there more awareness building needed to get companies to understand
> what the different libraries provide and why they should use a
> particular version?
> 
> Where does the delay come from?
> 

Firefox is one of the last browsers to get TLS 1.1 and TLS 1.2 support.
It's still not enabled by default in the stable release. Looking at
their development history is probably the best place to start.

TLS 1.1:

https://bugzilla.mozilla.org/show_bug.cgi?id=565047
https://bugzilla.mozilla.org/show_bug.cgi?id=733647

TLS 1.2:

https://bugzilla.mozilla.org/show_bug.cgi?id=480514
https://bugzilla.mozilla.org/show_bug.cgi?id=861266

Most of the delay seems to be in Bug 565047. TLS 1.1 was standardized in
2006, but the *ticket* to implement TLS 1.1 was created FOUR YEARS
later. Then, once it was, it took TWO YEARS to implement.

Non-compliant servers are wasting a ton of time in QA, too:

https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48
https://bugzilla.mozilla.org/show_bug.cgi?id=839310

Why doesn't TLS's fallback mechanism work?

So, it seems to me that:

1. The most significant delay is between when the standard is released
and when vendors realize they have to implement it. Until there's a
problem with the old version, they're hardly thinking about it.

2. Once they do realize it's necessary, it takes a long time to implement.

-- 
Taylor Hornby

From sm@resistor.net  Sat Nov 16 10:12:34 2013
Return-Path: <sm@resistor.net>
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 BD6B111E8100 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 10:12:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.134
X-Spam-Level: 
X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 ulMqdvZlZKmN for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 10:12:33 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 608DA11E80E3 for <tls@ietf.org>; Sat, 16 Nov 2013 10:12:33 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAGICK9R013111; Sat, 16 Nov 2013 10:12:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384625545; bh=i+VKuvmb3nshmA/31BVYI+81XitRToiLEfdL38An7+c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Dki9dJNgh0CPD3jgABUvqVdP5Y6yCgPLn1MHQoE3AeAT/zSLdC7AgCD4exre7ZzJ/ TmlkVK1ELLdIE4B8fID6sdrWs7lBogLTNpJDiOHCzmz5tN9ElW/ECi7vG46R441tTo A1+xyftvU2T0oBp3qFuaLSBpX5wwswAefQG40OGk=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384625545; i=@resistor.net; bh=i+VKuvmb3nshmA/31BVYI+81XitRToiLEfdL38An7+c=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Fd0uJjaSo11dVYXWSoVWV8Xli28sUcym3R8Vfrx6ejhGVWcizCmOyQhMBs9a/O+if BRBRkjDK/inX5IfKr0QCIWrTmAL/oyQNCDFKTDsx2nDwqISwO7T7+bfYunQ46yJs5Y 8ejVx5IVM9l0h7gRY1Q5wgROlW8RBI5TAzg6iSoo=
Message-Id: <6.2.5.6.2.20131116065610.0c538678@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 16 Nov 2013 07:25:22 -0800
To: Watson Ladd <watsonbladd@gmail.com>
From: SM <sm@resistor.net>
In-Reply-To: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.g mail.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: tls@ietf.org
Subject: Re: [TLS] This working group has failed
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: Sat, 16 Nov 2013 18:12:34 -0000

Hi Watson,
At 20:53 15-11-2013, Watson Ladd wrote:
>What problems would a hypothetical competition solve that TLS 1.2
>hasn't already? Let's deal with real problems: TLS 1.2 is not getting
>deployed, RC4 is still out there, the handshake protocol takes too
>many round trips and is very hard to implement in an interoperable way
>due to options, all the implementations with modern cryptographic
>support have sucky APIs that make it impossible for ordinary
>developers to use correctly, etc. All of this I have said before as

It is well-known that TLS 1.2 was not getting deployed.  There are 
two libraries which are widely used.  If one of them does not support 
TLS 1.x deployment will be slow.  The lack of deployment affects 
several other IETF protocols.

A RFC is not successful if it is not implemented.  RFC 6982 discusses 
about running code.

Regards,
-sm 


From holz@net.in.tum.de  Sat Nov 16 11:36:06 2013
Return-Path: <holz@net.in.tum.de>
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 9A41611E817C for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 11:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.902
X-Spam-Level: 
X-Spam-Status: No, score=0.902 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292]
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 3TuF+IneWyKZ for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 11:35:57 -0800 (PST)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2C11E8123 for <tls@ietf.org>; Sat, 16 Nov 2013 11:35:57 -0800 (PST)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 6575B80975; Sat, 16 Nov 2013 20:35:54 +0100 (CET)
Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 1444880374 for <tls@ietf.org>; Sat, 16 Nov 2013 20:35:49 +0100 (CET)
Message-ID: <5287C95A.20906@net.in.tum.de>
Date: Sat, 16 Nov 2013 20:36:58 +0100
From: Ralph Holz <holz@net.in.tum.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
CC: tls@ietf.org
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <6.2.5.6.2.20131116065610.0c538678@resistor.net>
In-Reply-To: <6.2.5.6.2.20131116065610.0c538678@resistor.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Subject: Re: [TLS] This working group has failed
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: Sat, 16 Nov 2013 19:36:23 -0000

Hi,

> It is well-known that TLS 1.2 was not getting deployed.  There are two
> libraries which are widely used.  If one of them does not support TLS

FWIW: When we recently scanned IPv4 with a standard openssl, we found
about 33M hosts that supported SSL3 or higher, and 14% of them accepted
our offer of TLSv1.2.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

From sm@resistor.net  Sat Nov 16 11:55:07 2013
Return-Path: <sm@resistor.net>
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 CDA4C11E8152 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 11:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.289
X-Spam-Level: 
X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 0fiAuu9JxGE8 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 11:55:07 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBDC11E80F5 for <tls@ietf.org>; Sat, 16 Nov 2013 11:55:06 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rAGJssKY029276; Sat, 16 Nov 2013 11:54:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1384631700; bh=UUmrgQZLfXH5Cr6bWPpllHoGrKb7YKr63IoHd4SAv2A=; h=Date:To:From:Subject:Cc; b=E/CsjHJz5525CJAg5LaJlgeQ8uh5R+T/p/WAXHnay+YX54mJAtGRS0GqFWdG2tpWO rgxTn7rI6USHl4f4fLag/smCiC3OXJfb06zxlSH4yxFPVHj14Z4v0hC3XGs3iiLQSi SZTwA3iHxDVu1q3HtNQlGT4LIV+8J6xCPSoYqJ1k=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1384631700; i=@resistor.net; bh=UUmrgQZLfXH5Cr6bWPpllHoGrKb7YKr63IoHd4SAv2A=; h=Date:To:From:Subject:Cc; b=m9IN5vODlfOc3w+C+8zzDOv33PiXbEVkuqYbd589OL+hARwdVHF/T5K6AFXY/fuat 9uoJRSVx5CptAbanBgZ0xGq2S+d+wPmnPvhxQ388aCqNbW0kWRbPsfQzC0jKK4U0p2 ht7ktX8Jee7s5oIS2/hOkB3A7fXjzTBq72Z+9pQ4=
Message-Id: <6.2.5.6.2.20131116114647.0c7a7170@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 16 Nov 2013 11:52:29 -0800
To: Adam Langley <agl@google.com>
From: SM <sm@resistor.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: tls@ietf.org
Subject: [TLS] draft-agl-tls-chacha20poly1305-03
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: Sat, 16 Nov 2013 19:55:07 -0000

Hi Adam,

For what it is worth, OpenSSH implemented ChaCha20-Poly1305 based on 
what is proposed in draft-agl-tls-chacha20poly1305-03.

Regards,
-sm


From alangley@gmail.com  Sat Nov 16 12:43:57 2013
Return-Path: <alangley@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 0980811E8252 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 12:43:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 II0tatBPRmgl for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 12:43:56 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 610D111E8290 for <tls@ietf.org>; Sat, 16 Nov 2013 12:43:56 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id ea20so3742576lab.40 for <tls@ietf.org>; Sat, 16 Nov 2013 12:43:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=SlnxlVKcStUPCIhd2J/UUy5qkPqF2iZVMuupxvjcIjE=; b=TWdncFDH2uVqpmdIeohHQLADNGQuncdz1rEi5DSZycxRdiZOs4/SwfVheExyFVqXoo NlMGfFXODD72KSxbhDFvCpA/FArclD1xUBxiLUplvoLh0Ara8eFcxy6qeI8+6B3+mOCP V6otlV9NhudK2lXV5wS0R8AIvtsGc/eqbUW/bp2bH3tvo8KWncJm3om9KipaXPObkPfM upkA+iEhNq934zHObyzCTY/BN4rF/7dKItpNVXrL3ualKIC8KLDBwWav4EIXruHZdAKe eXUpCV9okR/zooTblt/vS32zUT+WjPj0SO3LmpARHwlB7F3hyV+fx0nAKOmv05pOmfQW r7mg==
MIME-Version: 1.0
X-Received: by 10.152.170.133 with SMTP id am5mr8095857lac.9.1384634635188; Sat, 16 Nov 2013 12:43:55 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.112.96.230 with HTTP; Sat, 16 Nov 2013 12:43:55 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20131116114647.0c7a7170@elandnews.com>
References: <6.2.5.6.2.20131116114647.0c7a7170@elandnews.com>
Date: Sat, 16 Nov 2013 15:43:55 -0500
X-Google-Sender-Auth: 4vxgc_eLmQQ8553F41BPnAgStgM
Message-ID: <CAMfhd9UBJ_foNrQw93BKBWjAZGpbMWnsjxqh7ZfSuRUTJyLMCw@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: SM <sm@resistor.net>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-agl-tls-chacha20poly1305-03
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: Sat, 16 Nov 2013 20:43:57 -0000

On Sat, Nov 16, 2013 at 2:52 PM, SM <sm@resistor.net> wrote:
> For what it is worth, OpenSSH implemented ChaCha20-Poly1305 based on what is
> proposed in draft-agl-tls-chacha20poly1305-03.

Yea. I told djm that he should match the AEAD construction exactly
because then he would be able to use the OpenSSL API in the future,
but to no avail :)


Cheers

AGL

From ekr@rtfm.com  Sat Nov 16 16:47:54 2013
Return-Path: <ekr@rtfm.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 CEF2411E8105 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 16:47:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 PxVuzdsJ9LuR for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 16:47:47 -0800 (PST)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 52AE011E80E2 for <tls@ietf.org>; Sat, 16 Nov 2013 16:47:47 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id w61so1220626wes.29 for <tls@ietf.org>; Sat, 16 Nov 2013 16:47:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=2bsfKxHAdxhul+TDLnYB+uRu3yWtAJKlZtl6NmVcaFU=; b=MeCL3APRjFXsG7Ay9acIhevqZ24unHRTg8vXBkdUBcY04w+pWgfYMnswQJnW6shyqZ dVULdxc3fCiCq8ev4p+pNw6VFI52IyDWw78/TWfehhSQKia8q1NJFufhiy2Ucoef5NOR cwLlQIsNN+3dRM7MrFIjxflZexdqysQ0PsSzp77VLcLBDoXBIisvcGI+r4sz6W63gwSM rhGjBhfNKUrNmUT4D5s4ews9C3NWDSMijZnr2j43QRGqoboLnAWdCUwbWNsFXgshHNMh pI7Cj49YAg7myDK79L8YbVC9gDx241qU8lniGy1NvT/VXedrW7zl4UEM2kj/SiRZbu6c gD0Q==
X-Gm-Message-State: ALoCoQnZqGFh6p4zP0oyrRlnVTc7/ET5mm4pdcGUEwgB75k6/LdIGMxF+joAqXIH9LaDFdzpL8pi
X-Received: by 10.194.93.3 with SMTP id cq3mr11913924wjb.26.1384649264688; Sat, 16 Nov 2013 16:47:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Sat, 16 Nov 2013 16:47:04 -0800 (PST)
X-Originating-IP: [74.95.2.168]
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 16 Nov 2013 16:47:04 -0800
Message-ID: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bb048228f8a4404eb54c71f
Subject: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 00:47:54 -0000

--047d7bb048228f8a4404eb54c71f
Content-Type: text/plain; charset=ISO-8859-1

One of the topics we didn't really get to in Vancouver was the fate of
the static RSA ciphersuites. We'll eventually need to decide on this
for TLS 1.3.

Note that this isn't a question of either of the following:

* Removal of RSA from TLS 1.2 and below. There are still plenty of
  clients which only do static RSA and we can't actually break them
  for a long time.

* Removal of the use of RSA certificates: we would still almost
  certainly need ephemeral cipher suites where the server uses their
  RSA key for authentication, just like in the current RSA_DHE and
  RSA_ECDHE cipher suites.

The question is only for TLS 1.3 and only for static RSA.
(If you think differently, please raise on another thread.)


This message tries to summarize what I take to be the main arguments
for and against.

Static RSA has obvious deficiencies:

- It doesn't offer forward security.
- The larger key lengths that are required for security are increasingly
   uncompetitive with other algorithms (principally EC).

Additionally, since we know we want to offer ephemeral key agreement
modes such as DHE (see the recommendations in
http://tools.ietf.org/html/draft-sheffer-tls-bcp-01) it would reduce
complexity to *only* offer such modes rather than having to support
static RSA as well.

This isn't a no-brainer, though. Static RSA is still by far the
dominant key exchange algorithm and if you have an RSA certificate, is
strictly faster than any ephemeral suite. So, we're asking everyone to
take a performance hit at the same time as we're trying to make TLS
faster; of course this is a computational cost rather than one of
network latency, but there are still applications where that matters,
especially in constrained devices.

There are also some settings where PFS is actually undesirable,
especially for diagnosis and monitoring. In this settings, it's much
more convenient to simply provide the monitoring device with the
server key. ssldump and wireshark, for instance, both provide this
feature.

Please use this thread to discuss.

-Ekr

--047d7bb048228f8a4404eb54c71f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>One of the topics we didn&#39;t really get to in Vanc=
ouver was the fate of</div><div>the static RSA ciphersuites. We&#39;ll even=
tually need to decide on this</div><div>for TLS 1.3.</div><div><br></div><d=
iv>

Note that this isn&#39;t a question of either of the following:</div><div><=
br></div><div>* Removal of RSA from TLS 1.2 and below. There are still plen=
ty of</div><div>=A0 clients which only do static RSA and we can&#39;t actua=
lly break them</div>

<div>=A0 for a long time.</div><div><br></div><div>* Removal of the use of =
RSA certificates: we would still almost</div><div>=A0 certainly need epheme=
ral cipher suites where the server uses their</div><div>=A0 RSA key for aut=
hentication, just like in the current RSA_DHE and</div>

<div>=A0 RSA_ECDHE cipher suites.</div><div><br></div><div>The question is =
only for TLS 1.3 and only for static RSA.</div><div>(If you think different=
ly, please raise on another thread.)</div><div><br></div><div><br></div>
<div>
This message tries to summarize what I take to be the main arguments</div><=
div>for and against.</div><div><br></div><div>Static RSA has obvious defici=
encies:</div><div><br></div><div>- It doesn&#39;t offer forward security.</=
div>

<div>- The larger key lengths that are required for security are increasing=
ly</div><div>=A0 =A0uncompetitive with other algorithms (principally EC).</=
div><div><br></div><div>Additionally, since we know we want to offer epheme=
ral key agreement</div>

<div>modes such as DHE (see the recommendations in</div><div><a href=3D"htt=
p://tools.ietf.org/html/draft-sheffer-tls-bcp-01">http://tools.ietf.org/htm=
l/draft-sheffer-tls-bcp-01</a>) it would reduce</div><div>complexity to *on=
ly* offer such modes rather than having to support</div>

<div>static RSA as well.</div><div><br></div><div>This isn&#39;t a no-brain=
er, though. Static RSA is still by far the</div><div>dominant key exchange =
algorithm and if you have an RSA certificate, is</div><div>strictly faster =
than any ephemeral suite. So, we&#39;re asking everyone to</div>

<div>take a performance hit at the same time as we&#39;re trying to make TL=
S</div><div>faster; of course this is a computational cost rather than one =
of</div><div>network latency, but there are still applications where that m=
atters,</div>

<div>especially in constrained devices.</div><div><br></div><div>There are =
also some settings where PFS is actually undesirable,</div><div>especially =
for diagnosis and monitoring. In this settings, it&#39;s much</div><div>

more convenient to simply provide the monitoring device with the</div><div>=
server key. ssldump and wireshark, for instance, both provide this</div><di=
v>feature.</div><div><br></div><div>Please use this thread to discuss.</div=
>

<div><br></div><div>-Ekr</div><div><br></div><div><br></div></div>

--047d7bb048228f8a4404eb54c71f--

From hallam@gmail.com  Sat Nov 16 19:21:22 2013
Return-Path: <hallam@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 7DB8F11E83C3 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 19:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9wq0jeiuiS-1 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 19:21:21 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9411E83CD for <tls@ietf.org>; Sat, 16 Nov 2013 19:21:20 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id ea20so3856912lab.40 for <tls@ietf.org>; Sat, 16 Nov 2013 19:21:19 -0800 (PST)
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=qAdoIB4AOmfrL7Xr4lS7nfZ5IMFI/W3x+DQz1qI4Ifs=; b=itdZS+RVeADEqw8TczkvYTW3VIyMcVID9y9YRS7bktnV+q43WT42JxR4/pZjfm5n04 5EUAh2K/GZsEKdX9GoR+6f4gHsTpbSyAkKS0Y2nZ9Ffsui5eOYIEMVBnGMv4qX2QakJ9 T2xivWHfzZW9xC00VU4Yjby55zHQgMjzybIJYQ0M7TxKrT2guiizaRXstmhohDfMf4PT MDJC4a6txOey8ZEnUYyWmJaAhVSbfLC813r6+1C1KzVgB6hAhqbhoLHtKdrtkDv6oOB8 Snkh6N1mss/280XpuSuI8VrijebqU2+pN5jXMGBBOcrok7aPok8djjt3wqKHBLfEgGeI 7Jmg==
MIME-Version: 1.0
X-Received: by 10.112.168.170 with SMTP id zx10mr8134494lbb.0.1384658479780; Sat, 16 Nov 2013 19:21:19 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Sat, 16 Nov 2013 19:21:19 -0800 (PST)
In-Reply-To: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
Date: Sat, 16 Nov 2013 22:21:19 -0500
Message-ID: <CAMm+LwgJv-NBbPskpjSS4TV-KEFhfu=0RATu=i6b6-kN+J_AiQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=001a11c23c88d298ec04eb56ece5
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 03:21:22 -0000

--001a11c23c88d298ec04eb56ece5
Content-Type: text/plain; charset=ISO-8859-1

I am OK with this provided that we also make a Kerberos ticket like fast
session set up mandatory to support. This need not be the existing scheme
since we are talking about rejigging the key negotiation.

I certainly like the idea that TLS 1.3 becomes synonymous with the gold
standard for security. Knocking out the weak ciphers, key lengths and key
negotiation mechanisms is a good way to slim down the protocol.

But maybe one change we should consider is to break apart the cipher suites
so that we don't need to spend so much time discussing them.

If we made the cipher suite ID longer then we could break them down into
fields. The first few bits could specify whether the field zones are 8, 12
or 16 bits and then allocate numbers to each cipher.

The client and server would still negotiate over specific cipher suites but
adding a new block cipher would be one registry addition not twenty.



On Sat, Nov 16, 2013 at 7:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> One of the topics we didn't really get to in Vancouver was the fate of
> the static RSA ciphersuites. We'll eventually need to decide on this
> for TLS 1.3.
>
> Note that this isn't a question of either of the following:
>
> * Removal of RSA from TLS 1.2 and below. There are still plenty of
>   clients which only do static RSA and we can't actually break them
>   for a long time.
>
> * Removal of the use of RSA certificates: we would still almost
>   certainly need ephemeral cipher suites where the server uses their
>   RSA key for authentication, just like in the current RSA_DHE and
>   RSA_ECDHE cipher suites.
>
> The question is only for TLS 1.3 and only for static RSA.
> (If you think differently, please raise on another thread.)
>
>
>  This message tries to summarize what I take to be the main arguments
> for and against.
>
> Static RSA has obvious deficiencies:
>
> - It doesn't offer forward security.
> - The larger key lengths that are required for security are increasingly
>    uncompetitive with other algorithms (principally EC).
>
> Additionally, since we know we want to offer ephemeral key agreement
> modes such as DHE (see the recommendations in
> http://tools.ietf.org/html/draft-sheffer-tls-bcp-01) it would reduce
> complexity to *only* offer such modes rather than having to support
> static RSA as well.
>
> This isn't a no-brainer, though. Static RSA is still by far the
> dominant key exchange algorithm and if you have an RSA certificate, is
> strictly faster than any ephemeral suite. So, we're asking everyone to
> take a performance hit at the same time as we're trying to make TLS
> faster; of course this is a computational cost rather than one of
> network latency, but there are still applications where that matters,
> especially in constrained devices.
>
> There are also some settings where PFS is actually undesirable,
> especially for diagnosis and monitoring. In this settings, it's much
> more convenient to simply provide the monitoring device with the
> server key. ssldump and wireshark, for instance, both provide this
> feature.
>
> Please use this thread to discuss.
>
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


-- 
Website: http://hallambaker.com/

--001a11c23c88d298ec04eb56ece5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am OK with this provided that we also make a Kerberos ti=
cket like fast session set up mandatory to support. This need not be the ex=
isting scheme since we are talking about rejigging the key negotiation.<div=
>
<br></div><div>I certainly like the idea that TLS 1.3 becomes synonymous wi=
th the gold standard for security. Knocking out the weak ciphers, key lengt=
hs and key negotiation mechanisms is a good way to slim down the protocol.<=
/div>
<div><br></div><div>But maybe one change we should consider is to break apa=
rt the cipher suites so that we don&#39;t need to spend so much time discus=
sing them.</div><div><br></div><div>If we made the cipher suite ID longer t=
hen we could break them down into fields. The first few bits could specify =
whether the field zones are 8, 12 or 16 bits and then allocate numbers to e=
ach cipher.</div>
<div><br></div><div>The client and server would still negotiate over specif=
ic cipher suites but adding a new block cipher would be one registry additi=
on not twenty.</div><div><br></div></div><div class=3D"gmail_extra"><br><br=
>
<div class=3D"gmail_quote">On Sat, Nov 16, 2013 at 7:47 PM, Eric Rescorla <=
span dir=3D"ltr">&lt;<a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@=
rtfm.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>One of the topics we didn&#39;t really get to in Vanc=
ouver was the fate of</div><div>the static RSA ciphersuites. We&#39;ll even=
tually need to decide on this</div><div>for TLS 1.3.</div><div><br></div>
<div>

Note that this isn&#39;t a question of either of the following:</div><div><=
br></div><div>* Removal of RSA from TLS 1.2 and below. There are still plen=
ty of</div><div>=A0 clients which only do static RSA and we can&#39;t actua=
lly break them</div>


<div>=A0 for a long time.</div><div><br></div><div>* Removal of the use of =
RSA certificates: we would still almost</div><div>=A0 certainly need epheme=
ral cipher suites where the server uses their</div><div>=A0 RSA key for aut=
hentication, just like in the current RSA_DHE and</div>


<div>=A0 RSA_ECDHE cipher suites.</div><div><br></div><div>The question is =
only for TLS 1.3 and only for static RSA.</div><div>(If you think different=
ly, please raise on another thread.)</div><div><br></div><div><br></div>

<div>
This message tries to summarize what I take to be the main arguments</div><=
div>for and against.</div><div><br></div><div>Static RSA has obvious defici=
encies:</div><div><br></div><div>- It doesn&#39;t offer forward security.</=
div>


<div>- The larger key lengths that are required for security are increasing=
ly</div><div>=A0 =A0uncompetitive with other algorithms (principally EC).</=
div><div><br></div><div>Additionally, since we know we want to offer epheme=
ral key agreement</div>


<div>modes such as DHE (see the recommendations in</div><div><a href=3D"htt=
p://tools.ietf.org/html/draft-sheffer-tls-bcp-01" target=3D"_blank">http://=
tools.ietf.org/html/draft-sheffer-tls-bcp-01</a>) it would reduce</div><div=
>
complexity to *only* offer such modes rather than having to support</div>

<div>static RSA as well.</div><div><br></div><div>This isn&#39;t a no-brain=
er, though. Static RSA is still by far the</div><div>dominant key exchange =
algorithm and if you have an RSA certificate, is</div><div>strictly faster =
than any ephemeral suite. So, we&#39;re asking everyone to</div>


<div>take a performance hit at the same time as we&#39;re trying to make TL=
S</div><div>faster; of course this is a computational cost rather than one =
of</div><div>network latency, but there are still applications where that m=
atters,</div>


<div>especially in constrained devices.</div><div><br></div><div>There are =
also some settings where PFS is actually undesirable,</div><div>especially =
for diagnosis and monitoring. In this settings, it&#39;s much</div><div>


more convenient to simply provide the monitoring device with the</div><div>=
server key. ssldump and wireshark, for instance, both provide this</div><di=
v>feature.</div><div><br></div><div>Please use this thread to discuss.</div=
>


<div><br></div><div>-Ekr</div><div><br></div><div><br></div></div>
<br>_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Website:=
 <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div>

--001a11c23c88d298ec04eb56ece5--

From geoffk@geoffk.org  Sat Nov 16 20:28:27 2013
Return-Path: <geoffk@geoffk.org>
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 1B10F11E84AC for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 20:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 YFnN97XI5bx3 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 20:28:14 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0E411E84F8 for <tls@ietf.org>; Sat, 16 Nov 2013 20:28:06 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 1718733D0ED; Sun, 17 Nov 2013 04:28:06 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 16 Nov 2013 20:28:05 -0800
In-Reply-To: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
Message-ID: <m238mv1wkq.fsf@localhost.localdomain>
Lines: 88
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 04:28:28 -0000

Eric Rescorla <ekr@rtfm.com> writes:

> One of the topics we didn't really get to in Vancouver was the fate of
> the static RSA ciphersuites. We'll eventually need to decide on this
> for TLS 1.3.
...
> Static RSA has obvious deficiencies:
> 
> - It doesn't offer forward security.
> - The larger key lengths that are required for security are increasingly
>    uncompetitive with other algorithms (principally EC).
> 
> Additionally, since we know we want to offer ephemeral key agreement
> modes such as DHE (see the recommendations in
> http://tools.ietf.org/html/draft-sheffer-tls-bcp-01) it would reduce
> complexity to *only* offer such modes rather than having to support
> static RSA as well.
> 
> This isn't a no-brainer, though. Static RSA is still by far the
> dominant key exchange algorithm and if you have an RSA certificate, is
> strictly faster than any ephemeral suite. So, we're asking everyone to
> take a performance hit at the same time as we're trying to make TLS
> faster; of course this is a computational cost rather than one of
> network latency, but there are still applications where that matters,
> especially in constrained devices.
> 
> There are also some settings where PFS is actually undesirable,
> especially for diagnosis and monitoring. In this settings, it's much
> more convenient to simply provide the monitoring device with the
> server key. ssldump and wireshark, for instance, both provide this
> feature.

Perhaps we could break the operations into three:

- key agreement and generation (including generation of keys for upper layers)
- bulk encryption/mac
- authentication

and negotiate these separately.

Then, if people want a key agreement where one side generates a random
master key, encrypts it with RSA, and sends it to the other, we can do
that.  The RSA key can be ephemeral (or, at least, changed much more
often than today's typical "once every two years"), which gives
forward secrecy, or the RSA key can be fixed, if forward secrecy is
explicitly not wanted.

The 'client' side needs to only do one RSA encryption and one (RSA)
signature verification, which are both the fast side of the
computation, so should be cheap enough.  (The client will probably
need to do some more signature verifications anyway, to verify the
certificate chain.)  You're adding only a single RSA signature
verification compared to the current non-PFS cipher suites.

For debugging, set a fixed RSA key.  When it's over, unconfigure the
fixed key, automatically generate a new one, and you're secure again.

There are a few cases that are more tricky.  Although I know of no
case where the bulk cipher is combined with key agreement or
authentication---there are some cases where a particular cipher is
standardised to be used with particular key agreement, SKIPJACK comes
to mind, but these are not technical restrictions---sometimes key
agreement and authentication are combined, for example in SRP.  I am
not sure if this is an important problem; it can always be worked
around by doing a separate key agreement and SRP (or whatever), and
using the key produced by SRP for a MAC on the original key agreement.
This is more expensive than plain SRP but it is similar to the
technique recommended for privacy using SRP where you start with an
anonymous cipher suite and then renegotiate SRP.

This will also help for those who want a 'raw public key' mode, they
can simply use 'no authentication'.  If you start the bulk
encryption before starting the authentication, you get privacy (but
probably more round trips).  And you could make client authentication
and server authentication the same messages, just in different
directions, which will help make the protocol more direction-agnostic,
and will also allow better negotiation of client authentication
algorithm and perhaps even server certificate roots.

The above covered two of the common reasons for renegotiation: privacy
and needing additional client auth.  The third is for ciphers that
need re-keying, which I think should be part of the 'bulk
encryption/mac' definition; if a cipher needs rekeying every 10M or
10T of data, the spec for using it in TLS should say when this
happens, and the 'key agreement & generation' algorithm should be
responsible for providing new keys.

Sorry for the length, hope there's at least one good idea in here!

From watsonbladd@gmail.com  Sat Nov 16 20:32:07 2013
Return-Path: <watsonbladd@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 2BE1D11E84F5 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 20:32:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.671
X-Spam-Level: 
X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.929,  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 w0usIYOkVfK2 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 20:32:06 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE4911E8205 for <tls@ietf.org>; Sat, 16 Nov 2013 20:32:06 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id m15so4893344wgh.6 for <tls@ietf.org>; Sat, 16 Nov 2013 20:32:05 -0800 (PST)
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=TVCAv1jYt3e8ioROTW8f8jVwGqvNl2bzPYO0HdHJSZQ=; b=bWS6FdyrhGXxQCYPsbVRbv3QzOoeObfxoDdKZaT+Tfp6gT/sMX6C1XY2nSdgmszHBc fSUFAXQnzUXyDQ0G8V1LV8w9wB08tUqdvKX7eZIqmsfxngKoTfbdi2d6u2UwagP6cN/w dgB76vYc0Qz845L5QWKLEFLqLz9OcA3PzqIdnke+/Cz35njJd34h3aoZ0uR7LV7MFIzV rJ816edXYegR6avlWTig/GUW5er+gOuTlzOrgoZjOcHGeQl55AAIauuNyye1gVsAPL8A ceUvgQucHwvwM7gDTIVA+Lo7/8NlLHQnaES39ArmK4Vx9nJJAjAZpcH430czZ1y2MceN FzWQ==
MIME-Version: 1.0
X-Received: by 10.180.183.11 with SMTP id ei11mr12355502wic.10.1384662725583;  Sat, 16 Nov 2013 20:32:05 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sat, 16 Nov 2013 20:32:05 -0800 (PST)
In-Reply-To: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
Date: Sat, 16 Nov 2013 20:32:05 -0800
Message-ID: <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 04:32:07 -0000

I think that we need a better idea of the problem we are trying to solve.
Trading computation for latency by going to ECDSA/RSA signing certs
and signing a Diffie-Hellman exchange is a good idea for Google and the web,
but not so for embedded devices.

Sincerely,
Watson Ladd

From ekr@rtfm.com  Sat Nov 16 21:04:01 2013
Return-Path: <ekr@rtfm.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 9603F21F8FF8 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 OKuhDvuOydgl for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:03:52 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1005611E8569 for <tls@ietf.org>; Sat, 16 Nov 2013 21:03:51 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id ey16so2555246wid.1 for <tls@ietf.org>; Sat, 16 Nov 2013 21:03:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=w/tZzCCtFOebo/PLF6vYNuec+XvqPdeHgBngVB9TiiA=; b=ZzFhopYkM5UEAyX/aHpLVrR0Y5ky3IqdOS05OCnTvXwDBBxb5R+ytikwxPSmxE5Sqd o8Vhm2dx0NC05LQpCCBNhYXphDeKCCzlanXzNQF2zbxM01Vh6n/RoIzv/YsxV7JhTPVe UjCtoK8XmQqEckqdwFQPvL/aiuJmUBOG/SBIM/yYyzEjkQUqGLrGC0EoQKsSXAp8vVKD WHS8K88A80dLS7woZrjD8RmRGUTifybMqOeqaHgu1awbT4r6sneT5u0q2B28MMK/9BUH MYN9W5bbxmbZ6G0xsGSOuL1dE80LHyn9dSqHMxx8VhY/tZch4y0X80X+UKfEMms6lQk/ YeWg==
X-Gm-Message-State: ALoCoQlg4KtTs/B122dkiCo8iuACEcNDyZLH5UtRxbgbKZvAkOn2oFEPRi1SObISfVpovm7lX8b3
X-Received: by 10.194.89.233 with SMTP id br9mr11968480wjb.15.1384664631126; Sat, 16 Nov 2013 21:03:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Sat, 16 Nov 2013 21:03:10 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 16 Nov 2013 21:03:10 -0800
Message-ID: <CABcZeBMESWo9PN7C-aeAmF+GdOGFxvS45FW=8RK1HqEEk2DPPg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=089e0102fb5c78c8fb04eb585be3
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 05:04:01 -0000

--089e0102fb5c78c8fb04eb585be3
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Nov 16, 2013 at 8:32 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> I think that we need a better idea of the problem we are trying to solve.
> Trading computation for latency by going to ECDSA/RSA signing certs
> and signing a Diffie-Hellman exchange is a good idea for Google and the
> web,
> but not so for embedded devices.
>

TLS is extensively used in both settings.

That said, using ephemeral keying doesn't really improve latency
that much. There are a number of cases to consider, but off the top
of my head you get between 0-1/2 RTT by switching to ephemeral
exchange, depending on how much information the client has
about the server.

-Ekr



> Sincerely,
> Watson Ladd
>

--089e0102fb5c78c8fb04eb585be3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Nov 16, 2013 at 8:32 PM, Watson Ladd <span dir=3D"ltr">&lt;=
<a href=3D"mailto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmai=
l.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I think that we need a better idea of the pr=
oblem we are trying to solve.<br>
Trading computation for latency by going to ECDSA/RSA signing certs<br>
and signing a Diffie-Hellman exchange is a good idea for Google and the web=
,<br>
but not so for embedded devices.<br></blockquote><div><br></div><div>TLS is=
 extensively used in both settings.</div><div><br></div><div>That said, usi=
ng ephemeral keying doesn&#39;t really improve latency</div><div>that much.=
 There are a number of cases to consider, but off the top</div>

<div>of my head you get between 0-1/2 RTT by switching to ephemeral</div><d=
iv>exchange, depending on how much information the client has</div><div>abo=
ut the server.</div><div><br></div><div>-Ekr</div><div><br></div><div>
=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Sincerely,<br>
Watson Ladd<br>
</blockquote></div><br></div></div>

--089e0102fb5c78c8fb04eb585be3--

From watsonbladd@gmail.com  Sat Nov 16 21:13:06 2013
Return-Path: <watsonbladd@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 E47FC11E858F for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.135
X-Spam-Level: 
X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.465,  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 Gl7MrwAZLyvl for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:13:06 -0800 (PST)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7811E858D for <tls@ietf.org>; Sat, 16 Nov 2013 21:13:06 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hm11so2551740wib.8 for <tls@ietf.org>; Sat, 16 Nov 2013 21:13:05 -0800 (PST)
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=7EidqF6/48oIkRe3Gz5oxgcm1xsDEmKbPgeJdMQUogo=; b=mGxo/yi4Y/GlzE+/75n4ti+Frrv89nmvWSA1tGXjdZwm8rxqwAO3c2Gvvq48fg/5oD DPZ5tGxRQBjwsGPq4Wny649f4ApgVzekxd+GTMVNfHF42Fc2u0murvEC7rVSbBJr/DZM 3gihB/sBkWWlGHH1YeiIWM4r+YPT5CIU9tWaiFy+IcPxSlroEsHd46zR3ugWU2uftSFD SHP08dFFQFUJB8dolXxP0ZDTKASIP8pYU7EuIGYkncr/c8HTBpL8lCK4beLETHPzEk1y 8i9gWE2wHabxzAmsuzeS17coHORMqBNC7ansE4ElM1a6z4aefjL55GuFV53MVuiJdc5B kQ+Q==
MIME-Version: 1.0
X-Received: by 10.180.14.132 with SMTP id p4mr5639437wic.58.1384665185439; Sat, 16 Nov 2013 21:13:05 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sat, 16 Nov 2013 21:13:05 -0800 (PST)
In-Reply-To: <CABcZeBMESWo9PN7C-aeAmF+GdOGFxvS45FW=8RK1HqEEk2DPPg@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com> <CABcZeBMESWo9PN7C-aeAmF+GdOGFxvS45FW=8RK1HqEEk2DPPg@mail.gmail.com>
Date: Sat, 16 Nov 2013 21:13:05 -0800
Message-ID: <CACsn0ckcPvm4fBB-7YqQ0HbUNcUbG8dVYL0wquOCTcMneM=JJQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 05:13:07 -0000

On Sat, Nov 16, 2013 at 9:03 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Sat, Nov 16, 2013 at 8:32 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> I think that we need a better idea of the problem we are trying to solve.
>> Trading computation for latency by going to ECDSA/RSA signing certs
>> and signing a Diffie-Hellman exchange is a good idea for Google and the
>> web,
>> but not so for embedded devices.
>
>
> TLS is extensively used in both settings.
Actually, I take back what I said. ECC is much, much faster than RSA
on small devices
especially with hardware support. Static DH could be of interest here.
>
> That said, using ephemeral keying doesn't really improve latency
> that much. There are a number of cases to consider, but off the top
> of my head you get between 0-1/2 RTT by switching to ephemeral
> exchange, depending on how much information the client has
> about the server.
If you use a signature, rather than an encrypted message, you get
three passes rather than four, and can send
arbitrary client data in the third pass that is authenticated and
encrypted. This is effectively a 1-RT protocol if
the client goes first in the application layer.

Sincerely,
Watson


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From ekr@rtfm.com  Sat Nov 16 21:27:52 2013
Return-Path: <ekr@rtfm.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 EE60E11E85A6 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 00oAgcsyqv7W for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:27:46 -0800 (PST)
Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2C99211E85B0 for <tls@ietf.org>; Sat, 16 Nov 2013 21:27:17 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id k14so5034239wgh.29 for <tls@ietf.org>; Sat, 16 Nov 2013 21:27:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WQJFsj2ptxIB40qNDEQcOzhF/k1pvoX+F8LusKgQWx0=; b=B2vBKaO5eD2ZxZuxi5R24RCKR/GNmnIKUXbRXucyHr15fAJbBWA9RRGh4r7DYBQGDK SxL/4VUxVI0d9CWPVvMvMHQAnKz3M2Fyr95uNqWBimX2X0JYeAfy9w+SUCPUDPLOEArC t2U1ob6ce7ME73/jjKgbYZNQFJeS0j7Uw+fmgnS2zZtZm1ZJJ1WEef7C5/Fm3tHNfDgs kpWsUjULHBSa4YqtqhEUYk6pzl1Jt1D7wmrBWBguujDLi+OzdLGBLS5k7lq1qQW3CpIA JXX8hqgw9pF7aiHzw1qgMwBVyoR6Sexy64KbWJQgPaGvmrlIwMOzdkK0D+tBBSx2kLZV Ahig==
X-Gm-Message-State: ALoCoQl2RmOwqpAgNP42xmMQPDVODSoCWyjizLWW6yTJOqncpwiD7v3H4GGuFVc1UqeLDfToOO2M
X-Received: by 10.180.12.67 with SMTP id w3mr12547906wib.0.1384666034380; Sat, 16 Nov 2013 21:27:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Sat, 16 Nov 2013 21:26:34 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <CACsn0ckcPvm4fBB-7YqQ0HbUNcUbG8dVYL0wquOCTcMneM=JJQ@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com> <CABcZeBMESWo9PN7C-aeAmF+GdOGFxvS45FW=8RK1HqEEk2DPPg@mail.gmail.com> <CACsn0ckcPvm4fBB-7YqQ0HbUNcUbG8dVYL0wquOCTcMneM=JJQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 16 Nov 2013 21:26:34 -0800
Message-ID: <CABcZeBMwNh8NnzPD-_68etMWdSJqwsyTp2CDxuijSpkswkUWyw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c227401cba6804eb58afdd
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 05:27:53 -0000

--001a11c227401cba6804eb58afdd
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Nov 16, 2013 at 9:13 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Sat, Nov 16, 2013 at 9:03 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>  > That said, using ephemeral keying doesn't really improve latency
> > that much. There are a number of cases to consider, but off the top
> > of my head you get between 0-1/2 RTT by switching to ephemeral
> > exchange, depending on how much information the client has
> > about the server.
> If you use a signature, rather than an encrypted message, you get
> three passes rather than four, and can send
> arbitrary client data in the third pass that is authenticated and
> encrypted. This is effectively a 1-RT protocol if
> the client goes first in the application layer.


I'll revise what I said to 0-1RTT improvement. With that said...

- This depends on the client being able to send their share in the
first message, which requires some foreknowledge of what
parameters are acceptable.

- On repeated exchanges, the client can cache the server's
cert (Fast Track) and we're back to 1 RT.

- TLS with False Start is already 1RT, albeit without the client
being able to verify handshake correctness until he sees the
server's response.

-Ekr

--001a11c227401cba6804eb58afdd
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 16, 2013 at 9:13 PM, Watson Ladd <span dir="ltr">&lt;<a href="mailto:watsonbladd@gmail.com" target="_blank">watsonbladd@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Nov 16, 2013 at 9:03 PM, Eric Rescorla &lt;<a href="mailto:ekr@rtfm.com">ekr@rtfm.com</a>&gt; wrote:<br>

</div><div class="im">
&gt; That said, using ephemeral keying doesn&#39;t really improve latency<br>
&gt; that much. There are a number of cases to consider, but off the top<br>
&gt; of my head you get between 0-1/2 RTT by switching to ephemeral<br>
&gt; exchange, depending on how much information the client has<br>
&gt; about the server.<br>
</div>If you use a signature, rather than an encrypted message, you get<br>
three passes rather than four, and can send<br>
arbitrary client data in the third pass that is authenticated and<br>
encrypted. This is effectively a 1-RT protocol if<br>
the client goes first in the application layer.</blockquote><div><br></div><div>I&#39;ll revise what I said to 0-1RTT improvement. With that said...</div><div><br></div><div>- This depends on the client being able to send their share in the<br>

</div><div>first message, which requires some foreknowledge of what</div><div>parameters are acceptable.</div><div><br></div><div>- On repeated exchanges, the client can cache the server&#39;s</div><div>cert (Fast Track) and we&#39;re back to 1 RT.</div>

<div><br></div><div>- TLS with False Start is already 1RT, albeit without the client</div><div>being able to verify handshake correctness until he sees the</div><div>server&#39;s response.</div><div><br></div><div>-Ekr<br>

</div><div><br></div><div><br></div></div></div></div>

--001a11c227401cba6804eb58afdd--

From ekr@rtfm.com  Sat Nov 16 21:30:22 2013
Return-Path: <ekr@rtfm.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 5C8D111E85C0 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Hpl8FaVMH+35 for <tls@ietfa.amsl.com>; Sat, 16 Nov 2013 21:30:16 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9178511E8120 for <tls@ietf.org>; Sat, 16 Nov 2013 21:30:15 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hq4so2560125wib.4 for <tls@ietf.org>; Sat, 16 Nov 2013 21:30:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2tCt+iMkUKnN3gRow2OYDPrWrdK/16/MhLNO7cXCIhY=; b=EDrDgtLPtmZpOg8dNO5Ir0L/4zdPikygs29+P0NB0q+YW/1ptG4obClBJ8Ljmb7BrD HPVnadFveI2cU2mcSbrEXOZVlQUrYLAxGHJ6djyDZq9jgbgtzoLi0yWpoIaJ9QjFkD57 MHruTgmBVT4oera4ZyxgYA/AsYhe//J3q78/LPL6wQEjesi9s1q+hhIRf5aen/o2ymMG S4tbXj0gj+pAznnoEyFraFqcbfF512qLNYmHAH4Nya2ukT9Xoq7szsqexBANZbPd+ZYj +BKthL4bvhhOcjhCxK4Nh4UYhgrRW/+X01/zXtXHmkBThehgtGQSd/KCUBLDc9xGhqy0 cIqw==
X-Gm-Message-State: ALoCoQli0HzjgFvlfVqgBxSDubx05mWZeAzfRFoZq3CDnkhtacAayvc84A4U3YL5ZDqk+LftPZra
X-Received: by 10.180.24.137 with SMTP id u9mr12547087wif.5.1384666213916; Sat, 16 Nov 2013 21:30:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Sat, 16 Nov 2013 21:29:33 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <m238mv1wkq.fsf@localhost.localdomain>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <m238mv1wkq.fsf@localhost.localdomain>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 16 Nov 2013 21:29:33 -0800
Message-ID: <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Content-Type: multipart/alternative; boundary=f46d04447f67d0363404eb58b955
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 05:30:22 -0000

--f46d04447f67d0363404eb58b955
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
>
> Then, if people want a key agreement where one side generates a random
> master key, encrypts it with RSA, and sends it to the other, we can do
> that.  The RSA key can be ephemeral (or, at least, changed much more
> often than today's typical "once every two years"), which gives
> forward secrecy, or the RSA key can be fixed, if forward secrecy is
> explicitly not wanted
>

Oops, yeah, forgot to mention this.

As you say, it's possible to generate a short-term RSA key and use it
for multiple connections. This gives some level of forward security.

-Ekr

--f46d04447f67d0363404eb58b955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <span dir=3D"ltr">&lt;<a href=
=3D"mailto:geoffk@geoffk.org" target=3D"_blank">geoffk@geoffk.org</a>&gt;</=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">


Then, if people want a key agreement where one side generates a random<br>
master key, encrypts it with RSA, and sends it to the other, we can do<br>
that. =A0The RSA key can be ephemeral (or, at least, changed much more<br>
often than today&#39;s typical &quot;once every two years&quot;), which giv=
es<br>
forward secrecy, or the RSA key can be fixed, if forward secrecy is<br>
explicitly not wanted<br></blockquote><div><br></div><div>Oops, yeah, forgo=
t to mention this.</div><div><br></div><div>As you say, it&#39;s possible t=
o generate a short-term RSA key and use it</div><div>for multiple connectio=
ns. This gives some level of forward security.</div>

<div><br></div><div>-Ekr</div><div><br></div></div></div></div>

--f46d04447f67d0363404eb58b955--

From hannes.tschofenig@gmx.net  Sun Nov 17 02:30:47 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 3865B11E8A84 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 02:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 S8PQ0x4sXJbY for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 02:30:42 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB011E810A for <tls@ietf.org>; Sun, 17 Nov 2013 02:30:41 -0800 (PST)
Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lh7M3-1VNnlf1yv1-00oW2B for <tls@ietf.org>; Sun, 17 Nov 2013 11:30:40 +0100
Message-ID: <52889ACF.3050302@gmx.net>
Date: Sun, 17 Nov 2013 11:30:39 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Taylor Hornby <havoc@defuse.ca>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <5287B4F6.1060102@defuse.ca>
In-Reply-To: <5287B4F6.1060102@defuse.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:XWlU0kdrbi+iz/3ebK+b18kWh9d0UwvVKMsGQ3TKVYl20C8rDyV qw83m+HFUM8fwP7EKPJzb0zD4PViWuZ9Y3N3uFCpHP0yYJRP62y0/uPVY6XNyaYZmJr+x8h xZOG6z0U8sSJFW7iaYS/l32tylhukW3NlMfOQhY42kpug/t+ExQISXMJZPqOtZtbKmUqxu9 YtSi4nrgv/3f5PfSKnzMg==
Cc: tls@ietf.org
Subject: Re: [TLS] Deployment ... Re:  This working group has failed
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: Sun, 17 Nov 2013 10:30:47 -0000

Hi Taylor,

Would be interesting to hear from someone working for Mozilla (like Ekr, 
our TLS WG chair) why things are progressing so slowly and what exactly 
their problem is.

Ciao
Hannes

Am 16.11.13 19:09, schrieb Taylor Hornby:
> On 11/16/2013 03:14 AM, Hannes Tschofenig wrote:
>> To be positive and constructive in the discussion I wonder what could be
>> done to improve the situation.
>>
>> Does the OpenSSL and the GnuTLS projects (and other projects) need more
>> contributors?
>>
>> Is there more awareness building needed to get companies to understand
>> what the different libraries provide and why they should use a
>> particular version?
>>
>> Where does the delay come from?
>>
>
> Firefox is one of the last browsers to get TLS 1.1 and TLS 1.2 support.
> It's still not enabled by default in the stable release. Looking at
> their development history is probably the best place to start.
>
> TLS 1.1:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=565047
> https://bugzilla.mozilla.org/show_bug.cgi?id=733647
>
> TLS 1.2:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=480514
> https://bugzilla.mozilla.org/show_bug.cgi?id=861266
>
> Most of the delay seems to be in Bug 565047. TLS 1.1 was standardized in
> 2006, but the *ticket* to implement TLS 1.1 was created FOUR YEARS
> later. Then, once it was, it took TWO YEARS to implement.
>
> Non-compliant servers are wasting a ton of time in QA, too:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=733647#c48
> https://bugzilla.mozilla.org/show_bug.cgi?id=839310
>
> Why doesn't TLS's fallback mechanism work?
>
> So, it seems to me that:
>
> 1. The most significant delay is between when the standard is released
> and when vendors realize they have to implement it. Until there's a
> problem with the old version, they're hardly thinking about it.
>
> 2. Once they do realize it's necessary, it takes a long time to implement.
>


From ynir@checkpoint.com  Sun Nov 17 03:13:18 2013
Return-Path: <ynir@checkpoint.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 DA37311E8AC2 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 03:13:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.166
X-Spam-Level: 
X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 j3abFtmhzX4v for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 03:13:13 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A10BA11E8241 for <tls@ietf.org>; Sun, 17 Nov 2013 03:13:03 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rAHBCuK9000346; Sun, 17 Nov 2013 13:12:56 +0200
X-CheckPoint: {5288A2A0-3-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 13:12:56 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Thread-Topic: [TLS] Deployment ... Re:  This working group has failed
Thread-Index: AQHO4rSnkbVJpNqTEEuoz3WRzLISMZooBy4AgAER/4CAAAvQgA==
Date: Sun, 17 Nov 2013 11:12:55 +0000
Message-ID: <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <5287B4F6.1060102@defuse.ca> <52889ACF.3050302@gmx.net>
In-Reply-To: <52889ACF.3050302@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.100]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C154E4BDE9E274C9F5B63B3130C2477@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org list" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re:  This working group has failed
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: Sun, 17 Nov 2013 11:13:19 -0000

On Nov 17, 2013, at 12:30 PM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>=
 wrote:

> Hi Taylor,
>=20
> Would be interesting to hear from someone working for Mozilla (like Ekr, =
our TLS WG chair) why things are progressing so slowly and what exactly the=
ir problem is.
>=20

Hi Hannes

We have heard before from people at Google and at Microsoft. Google only ad=
ded TLS 1.2 very recently, and Microsoft added it very early, but disabled =
it by default for a long time.

There were issues with failures of connections attempts using TLS 1.2.  The=
re have been issues with 1.1, but 1.2 produced much more of them.

 1. TLS 1.2 is the first version to require support of extensions. Some ser=
vers broke when extensions existed.
 2. Some servers broke on unrecognized extensions.
 3. Some server break on missing extensions - certain servers will not acce=
pt a TLS 1.2 ClientHello without the SignatureAlgorithm extension

Combining 1 & 3, you can't win. Some servers just won't work.

I don't know what changed. Perhaps the percentage of servers that are broke=
n like that has diminished. But not it looks like the browser vendors have =
deemed it as sufficiently low to allow them to make this on by default.

Yoav


From hannes.tschofenig@gmx.net  Sun Nov 17 03:53:20 2013
Return-Path: <hannes.tschofenig@gmx.net>
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 7427F11E8BB2 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 03:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Yn+YF6Pbetu5 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 03:53:14 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 635F811E8BB0 for <tls@ietf.org>; Sun, 17 Nov 2013 03:53:14 -0800 (PST)
Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M03qC-1VPEZh1Ghg-00uFnc for <tls@ietf.org>; Sun, 17 Nov 2013 12:53:13 +0100
Message-ID: <5288AE28.4050109@gmx.net>
Date: Sun, 17 Nov 2013 12:53:12 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <5287B4F6.1060102@defuse.ca> <52889ACF.3050302@gmx.net> <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
In-Reply-To: <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Hkm3n5zsOEhhF1Qz58b9r6/0R5DVtmRwtOt7+rku/rZaq5kH/xI 0R6MMujPj6eTalbMPQItNBLGvpPpEJWO4W8pAmfj5+w/8YDz6p931LDexsB0MwzEvYzlqbR xWdLuLiwQV162duss9gim5xmdQafBrvocUsT3YP4NKwPyzqVMM6X/MqWodfrMFUT3sYhJLY GwhMrdMDittrnZXL7A+Pg==
Cc: "tls@ietf.org list" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re:  This working group has failed
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: Sun, 17 Nov 2013 11:53:20 -0000

Hi Yoav,

thanks for the response.

I interested in those views only to collect some data points for 
improving the rate of adoption in the future. You might think I am 
strange but I think we should learn from those mistakes and avoid them 
in the future.

 From what you write below I am wondering what TLS libraries these 
problematic servers have been using? Do we know more about that?

Ciao
Hannes

Am 17.11.13 12:12, schrieb Yoav Nir:
>
> On Nov 17, 2013, at 12:30 PM, Hannes Tschofenig
> <Hannes.Tschofenig@gmx.net> wrote:
>
>> Hi Taylor,
>>
>> Would be interesting to hear from someone working for Mozilla (like
>> Ekr, our TLS WG chair) why things are progressing so slowly and
>> what exactly their problem is.
>>
>
> Hi Hannes
>
> We have heard before from people at Google and at Microsoft. Google
> only added TLS 1.2 very recently, and Microsoft added it very early,
> but disabled it by default for a long time.
>
> There were issues with failures of connections attempts using TLS
> 1.2.  There have been issues with 1.1, but 1.2 produced much more of
> them.
>
> 1. TLS 1.2 is the first version to require support of extensions.
> Some servers broke when extensions existed. 2. Some servers broke on
> unrecognized extensions. 3. Some server break on missing extensions -
> certain servers will not accept a TLS 1.2 ClientHello without the
> SignatureAlgorithm extension
>
> Combining 1 & 3, you can't win. Some servers just won't work.
>
> I don't know what changed. Perhaps the percentage of servers that are
> broken like that has diminished. But not it looks like the browser
> vendors have deemed it as sufficiently low to allow them to make this
> on by default.
>
> Yoav
>


From rsalz@akamai.com  Sun Nov 17 07:17:26 2013
Return-Path: <rsalz@akamai.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 C087311E8DBF for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 07:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uXj-L2FAcfGw for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 07:17:21 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0804B11E8DCB for <tls@ietf.org>; Sun, 17 Nov 2013 07:17:16 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 255A2473D0; Sun, 17 Nov 2013 15:17:16 +0000 (GMT)
Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 044E1473C5; Sun, 17 Nov 2013 15:17:16 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id F2615FE055; Sun, 17 Nov 2013 15:17:15 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Sun, 17 Nov 2013 10:17:15 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Watson Ladd <watsonbladd@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Date: Sun, 17 Nov 2013 10:17:01 -0500
Thread-Topic: [TLS] This working group has failed
Thread-Index: Ac7ih9PVs7unID98Sh2a4fyzxNS3MQBIBUrQ
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE207@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
In-Reply-To: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] This working group has failed
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: Sun, 17 Nov 2013 15:17:26 -0000

> Implementers such as AGL are bypassing the WG, choosing to emit I-Ds and =
implementing and deploying because there is little
> to be gained from WG discussions. This is not necessarily a bad thing, bu=
t it does raise a question of whether what is good for
> Google is good for the Web as a whole.

If, a few years ago, Microsoft did the same thing I have no doubt what the =
public reaction would be.

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA


From mpg@elzevir.fr  Sun Nov 17 07:28:53 2013
Return-Path: <mpg@elzevir.fr>
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 B5B6511E8DD4 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 07:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 ptJvpGD1NVlR for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 07:28:48 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0665011E8DFD for <tls@ietf.org>; Sun, 17 Nov 2013 07:28:27 -0800 (PST)
Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 1FB0816093; Sun, 17 Nov 2013 16:28:26 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 43D2923AA5; Sun, 17 Nov 2013 16:28:24 +0100 (CET)
Message-ID: <5288E097.6050606@elzevir.fr>
Date: Sun, 17 Nov 2013 16:28:23 +0100
From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@elzevir.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
In-Reply-To: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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: Sun, 17 Nov 2013 15:28:53 -0000

On 17/11/2013 01:47, Eric Rescorla wrote:
> This isn't a no-brainer, though. Static RSA is still by far the
> dominant key exchange algorithm and if you have an RSA certificate, is
> strictly faster than any ephemeral suite.

Yes, if you have an RSA certificate. OTOH, if in the coming years ECDSA
certificates become more popular, then ECDHE_ECDSA is less computationally
expensive for the server than static RSA, though more expensive for the client.

(By the way, having key exchanges that are less expensive for the server is also
good to make DOS attacks harder.)

> There are also some settings where PFS is actually undesirable,
> especially for diagnosis and monitoring. In this settings, it's much
> more convenient to simply provide the monitoring device with the
> server key. ssldump and wireshark, for instance, both provide this
> feature.
> 
I don't know about ssldump, but with wireshark if you're interested in debugging
only a handful of sessions, it can directly use the premaster secret if you can
get your SSL library to display it (I know NSS can do it, I don't know if
OpenSSL can).

Also, it is possible to (temporarily) use static keys with a
supposedly-ephemeral (EC)DH key exchange and an option could be added to
wireshark and similar tools to take advantage of that.


Overall, I'd be inclined to drop static RSA key exchange in TLS 1.3 and allow
only ephemeral key exchanges (except maybe for the PSK key exchanges).

Manuel.

From mnot@mnot.net  Sun Nov 17 12:26:04 2013
Return-Path: <mnot@mnot.net>
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 9621611E81A8 for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 12:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 notYHoUWQeNs for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 12:25:57 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6210011E821C for <tls@ietf.org>; Sun, 17 Nov 2013 12:25:10 -0800 (PST)
Received: from [192.168.1.72] (unknown [118.209.179.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B03F5509B8; Sun, 17 Nov 2013 15:25:04 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
Date: Mon, 18 Nov 2013 07:24:59 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <48FED074-6468-42E7-9B63-7895DC17D916@mnot.net>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <5287B4F6.1060102@defuse.ca> <52889ACF.3050302@gmx.net> <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1822)
Cc: "tls@ietf.org list" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re:  This working group has failed
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: Sun, 17 Nov 2013 20:26:04 -0000

On 17 Nov 2013, at 10:12 pm, Yoav Nir <ynir@checkpoint.com> wrote:

> 1. TLS 1.2 is the first version to require support of extensions. Some =
servers broke when extensions existed.
> 2. Some servers broke on unrecognized extensions.
> 3. Some server break on missing extensions - certain servers will not =
accept a TLS 1.2 ClientHello without the SignatureAlgorithm extension

It seems like TLS is facing problems similar to those that HTTP is =
regarding Upgrade. Maybe the takeaway is that one of the more important =
things to get right is the test suite for extensibility / versioning in =
any new protocol (alas, too late for TLS and HTTP=85).

Cheers,


--
Mark Nottingham   http://www.mnot.net/




From aerowolf@gmail.com  Sun Nov 17 12:43:37 2013
Return-Path: <aerowolf@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 245BD11E929B for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 12:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
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 UIyuMBDv6RFi for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 12:43:35 -0800 (PST)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9622E11E9299 for <tls@ietf.org>; Sun, 17 Nov 2013 12:43:23 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t60so460449wes.28 for <tls@ietf.org>; Sun, 17 Nov 2013 12:43:22 -0800 (PST)
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=nZhmPpyrp7xiN0aXAhsyYpnf/J/p44mpzxo+0T5SyqQ=; b=HVwoqgBwOD7NEUCTStsJJof8EdS4FUGdXiou631gG6hiDVvJ1sIypSTGhycIQeShjA E/wb/srCuRcdNrdRKD2pgSCcOP8Y/ezVACzLaJPB70yFYWr16Yf6aGT+5BWs4CYn5G9Z bkPldCvKqHpUckCa2BPuIY5IwetVSrXA567JE8kLKuVLuC5rRbE/kHyXFPg7IaS8pVZZ /oOaP1CUR795J+M7p/K94LfH2D2HwlOY0eHjB1mQ3ok6mJU+I7R/ylE18GW1AL1ewODL BoD/EhukK5KARt7fFclBca9Q6NPdsCUPupK0vZcsqnN8zQA20QQaE+lBOqn9Tvo9rsic cJkg==
MIME-Version: 1.0
X-Received: by 10.194.122.99 with SMTP id lr3mr13764458wjb.21.1384721002388; Sun, 17 Nov 2013 12:43:22 -0800 (PST)
Received: by 10.194.134.67 with HTTP; Sun, 17 Nov 2013 12:43:22 -0800 (PST)
Received: by 10.194.134.67 with HTTP; Sun, 17 Nov 2013 12:43:22 -0800 (PST)
In-Reply-To: <52874576.9000708@gmx.net>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net>
Date: Sun, 17 Nov 2013 12:43:22 -0800
Message-ID: <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>
From: Kyle Hamilton <aerowolf@gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary=089e011779b575e36f04eb657b28
Cc: tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Sun, 17 Nov 2013 20:43:37 -0000

--089e011779b575e36f04eb657b28
Content-Type: text/plain; charset=UTF-8

If the library were a drop-in replacement that didn't alter binary
compatibility, it would be a simple matter to just drop it in, put a new
config defaults and override file in place, and call it done.

Unfortunately, C is not this easy. The application linking process is
complex (particularly with OpenSSL's FIPScanister), and it's not getting
any easier -- I love how simple it is to drop a new CLR assembly in place
and have the environment simply pick up the changes, but that
configurability comes at the price of having to use the CLR runtime.

Perhaps something that would perform the same function as and
overload/override the platform-native dynlib loading would help, then
integrated into the security libraries that most need it, would help.

I have found myself despising C and C++ and other compiled-to-native
languages as a result of this kind of thing. I am not volunteering to
create such, and frankly I wouldn't even know where to begin -- but
standardizing dynamic library capabilities across most/all OSes would go a
long way toward making security updates and new security capabilities much
easier for administrators to deal with.

-Kyle H
On Nov 16, 2013 2:14 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net>
wrote:

> Hi Watson,
>
> I understand your frustration and I wanted to pick up one point that you
> raised, namely why does it take so long to get TLS versions and extensions
> deployed.
>
> I had recently a chat with a friend, Thomas Schreck who works for the
> Siemens CERT, and in the discussion about TLS I told him that he needs to
> deploy TLS 1.2 inside the company. He responded to me that support for TLS
> 1.2 has only been added to OpenSSL last year (which seems to be correct
> when I check the change logs where the initial support has been added with
> version 1.0.1).
>
> The TLS 1.2 spec was, however, finished in 2008.
>
> Having the code in the library is only the first step since then all the
> applications that use the library also need to be updated (re-compliled at
> least and shipped). Hard to say how long that takes and depends on the
> application and the company.
>
> To be positive and constructive in the discussion I wonder what could be
> done to improve the situation.
>
> Does the OpenSSL and the GnuTLS projects (and other projects) need more
> contributors?
>
> Is there more awareness building needed to get companies to understand
> what the different libraries provide and why they should use a particular
> version?
>
> Where does the delay come from?
>
> Ciao
> Hannes
>
> Am 16.11.13 05:53, schrieb Watson Ladd:
>
>> In the past decade there have been many attacks against TLS.
>> With the exception of CRIME, not one of them relied on any results
>> that were not known
>> at the time the TLS 1.0 standard was being written. (See the citations
>> for the RC4 paper to see this, or the infamous Rogaway email about AtE
>> vs EtA). Every time this standards group has had a choice to make
>> regarding cryptography, they have made the wrong one. Even AES-GCM got
>> screwed up: nonces should be counters, but all implementations make
>> them random, introducing an artificial birthday bound issue due to
>> truncation in the standard.
>>
>> TLS is solving the deadest of dead problems in cryptography: using the
>> PKI to establish a secure channel between two endpoints. Diffie and
>> Hellman solved this in their paper. Were TLS to be submitted by an
>> undergraduate as a solution to this problem it would earn an F.
>> Implementers such as AGL are bypassing the WG, choosing to emit I-Ds
>> and implementing and deploying because there is little to be gained
>> from WG discussions. This is not necessarily a bad thing, but it does
>> raise a question of whether what is good for Google is good for the
>> Web as a whole.
>>
>> What problems would a hypothetical competition solve that TLS 1.2
>> hasn't already? Let's deal with real problems: TLS 1.2 is not getting
>> deployed, RC4 is still out there, the handshake protocol takes too
>> many round trips and is very hard to implement in an interoperable way
>> due to options, all the implementations with modern cryptographic
>> support have sucky APIs that make it impossible for ordinary
>> developers to use correctly, etc. All of this I have said before as
>> main priorities, but they are the biggest issues affecting us today. I
>> propose that a chair (do we have one?) convene a meeting via IRC or in
>> person at some convenient event to determine what problems should be
>> priorities, and then we will address them.
>>
>> There are a few good points: I am glad to see that major vendors are
>> represented on this list, and are generally willing to work together
>> to insure interoperability and remove obstacles to improving internet
>> security. I am also glad to see that we are acutely aware of the
>> issues currently threatening the lives and property of internet users.
>>
>> Sincerely,
>> Watson
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--089e011779b575e36f04eb657b28
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">If the library were a drop-in replacement that didn&#39;t al=
ter binary compatibility, it would be a simple matter to just drop it in, p=
ut a new config defaults and override file in place, and call it done.</p>

<p dir=3D"ltr">Unfortunately, C is not this easy. The application linking p=
rocess is complex (particularly with OpenSSL&#39;s FIPScanister), and it&#3=
9;s not getting any easier -- I love how simple it is to drop a new CLR ass=
embly in place and have the environment simply pick up the changes, but tha=
t configurability comes at the price of having to use the CLR runtime.</p>

<p dir=3D"ltr">Perhaps something that would perform the same function as an=
d overload/override the platform-native dynlib loading would help, then int=
egrated into the security libraries that most need it, would help.</p>
<p dir=3D"ltr">I have found myself despising C and C++ and other compiled-t=
o-native languages as a result of this kind of thing. I am not volunteering=
 to create such, and frankly I wouldn&#39;t even know where to begin -- but=
 standardizing dynamic library capabilities across most/all OSes would go a=
 long way toward making security updates and new security capabilities much=
 easier for administrators to deal with.</p>

<p dir=3D"ltr">-Kyle H</p>
<div class=3D"gmail_quote">On Nov 16, 2013 2:14 AM, &quot;Hannes Tschofenig=
&quot; &lt;<a href=3D"mailto:hannes.tschofenig@gmx.net">hannes.tschofenig@g=
mx.net</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
Hi Watson,<br>
<br>
I understand your frustration and I wanted to pick up one point that you ra=
ised, namely why does it take so long to get TLS versions and extensions de=
ployed.<br>
<br>
I had recently a chat with a friend, Thomas Schreck who works for the Sieme=
ns CERT, and in the discussion about TLS I told him that he needs to deploy=
 TLS 1.2 inside the company. He responded to me that support for TLS 1.2 ha=
s only been added to OpenSSL last year (which seems to be correct when I ch=
eck the change logs where the initial support has been added with version 1=
.0.1).<br>

<br>
The TLS 1.2 spec was, however, finished in 2008.<br>
<br>
Having the code in the library is only the first step since then all the ap=
plications that use the library also need to be updated (re-compliled at le=
ast and shipped). Hard to say how long that takes and depends on the applic=
ation and the company.<br>

<br>
To be positive and constructive in the discussion I wonder what could be do=
ne to improve the situation.<br>
<br>
Does the OpenSSL and the GnuTLS projects (and other projects) need more con=
tributors?<br>
<br>
Is there more awareness building needed to get companies to understand what=
 the different libraries provide and why they should use a particular versi=
on?<br>
<br>
Where does the delay come from?<br>
<br>
Ciao<br>
Hannes<br>
<br>
Am 16.11.13 05:53, schrieb Watson Ladd:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In the past decade there have been many attacks against TLS.<br>
With the exception of CRIME, not one of them relied on any results<br>
that were not known<br>
at the time the TLS 1.0 standard was being written. (See the citations<br>
for the RC4 paper to see this, or the infamous Rogaway email about AtE<br>
vs EtA). Every time this standards group has had a choice to make<br>
regarding cryptography, they have made the wrong one. Even AES-GCM got<br>
screwed up: nonces should be counters, but all implementations make<br>
them random, introducing an artificial birthday bound issue due to<br>
truncation in the standard.<br>
<br>
TLS is solving the deadest of dead problems in cryptography: using the<br>
PKI to establish a secure channel between two endpoints. Diffie and<br>
Hellman solved this in their paper. Were TLS to be submitted by an<br>
undergraduate as a solution to this problem it would earn an F.<br>
Implementers such as AGL are bypassing the WG, choosing to emit I-Ds<br>
and implementing and deploying because there is little to be gained<br>
from WG discussions. This is not necessarily a bad thing, but it does<br>
raise a question of whether what is good for Google is good for the<br>
Web as a whole.<br>
<br>
What problems would a hypothetical competition solve that TLS 1.2<br>
hasn&#39;t already? Let&#39;s deal with real problems: TLS 1.2 is not getti=
ng<br>
deployed, RC4 is still out there, the handshake protocol takes too<br>
many round trips and is very hard to implement in an interoperable way<br>
due to options, all the implementations with modern cryptographic<br>
support have sucky APIs that make it impossible for ordinary<br>
developers to use correctly, etc. All of this I have said before as<br>
main priorities, but they are the biggest issues affecting us today. I<br>
propose that a chair (do we have one?) convene a meeting via IRC or in<br>
person at some convenient event to determine what problems should be<br>
priorities, and then we will address them.<br>
<br>
There are a few good points: I am glad to see that major vendors are<br>
represented on this list, and are generally willing to work together<br>
to insure interoperability and remove obstacles to improving internet<br>
security. I am also glad to see that we are acutely aware of the<br>
issues currently threatening the lives and property of internet users.<br>
<br>
Sincerely,<br>
Watson<br>
______________________________<u></u>_________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/<u></u>listinfo/tls</a><br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org" target=3D"_blank">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/<u></u>listinfo/tls</a><br>
</blockquote></div>

--089e011779b575e36f04eb657b28--

From juhovh@iki.fi  Sun Nov 17 13:48:43 2013
Return-Path: <juhovh@iki.fi>
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 4DE5A11E886D for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 13:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level: 
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
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 44nDx4b1vs7P for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 13:48:27 -0800 (PST)
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfa.amsl.com (Postfix) with ESMTP id 7276511E92EC for <tls@ietf.org>; Sun, 17 Nov 2013 13:48:26 -0800 (PST)
Received: from [10.187.75.77] (85-76-137-52-nat.elisa-mobile.fi [85.76.137.52]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 866F4216601; Sun, 17 Nov 2013 23:48:19 +0200 (EET)
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-EA1E4120-FAC6-4EAE-AE91-8B6B895C061C
Content-Transfer-Encoding: 7bit
Message-Id: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi>
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Sun, 17 Nov 2013 23:44:44 +0200
To: Kyle Hamilton <aerowolf@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Sun, 17 Nov 2013 21:48:43 -0000

--Apple-Mail-EA1E4120-FAC6-4EAE-AE91-8B6B895C061C
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable


> On 17.11.2013, at 22.43, Kyle Hamilton <aerowolf@gmail.com> wrote:
>=20
> If the library were a drop-in replacement that didn't alter binary compati=
bility, it would be a simple matter to just drop it in, put a new config def=
aults and override file in place, and call it done.
>=20
> Unfortunately, C is not this easy.
>=20
...
> I have found myself despising C and C++ and other compiled-to-native langu=
ages as a result of this kind of thing.
>=20

I'm not sure why C is getting the blame here. C++ has had its problems with b=
inary compatibility across compiler versions etc, but C calling conventions a=
re usually very clearly defined. (cdecl/stdcall separation on windows confus=
es this a bit) Yes, a Windows library doesn't work well in Linux, but neithe=
r do CLR binaries, Mono is not a serious option for this kind of stuff.

What is a bigger problem is designing a stable API between major upgrades. T=
his is indeed slightly easier in languages that support overloading methods,=
 like C++ or C#, compared to plain C. However, TLS 1.2 (and based on the dis=
cussion TLS 1.3/2.0 as well) are major updates to the protocol, I don't thin=
k it is going to be that easy to do a major upgrade without affecting the AP=
I, be it CLR or compiled to native. Having a new crossplatform dynamic loade=
r doesn't help much if the API cannot be kept stable, it would only add new r=
estrictions.

The problem you've brought up is certainly valid, but I'm not sure if the bl=
ame is going to the right place. Complex compilation process of OpenSSL is m=
ostly coming from FIPS requirements as well and no platform or linker can pr=
event that, because the problem itself is not technical but bureaucratic. So=
me things just can't be avoided, but all ideas of how to make TLS upgrades l=
ess painful should be taken into account. As much as I'd like to design the p=
rotocol from scratch as well, it doesn't help if no one is going to use it.


Juho


--Apple-Mail-EA1E4120-FAC6-4EAE-AE91-8B6B895C061C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><br></div><div>On 17.11.2013, at 22.43=
, Kyle Hamilton &lt;<a href=3D"mailto:aerowolf@gmail.com">aerowolf@gmail.com=
</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><p dir=3D"ltr">I=
f the library were a drop-in replacement that didn't alter binary compatibil=
ity, it would be a simple matter to just drop it in, put a new config defaul=
ts and override file in place, and call it done.</p>

<p dir=3D"ltr">Unfortunately, C is not this easy. </p></div></blockquote><di=
v>...</div><blockquote type=3D"cite"><div><p dir=3D"ltr">I have found myself=
 despising C and C++ and other compiled-to-native languages as a result of t=
his kind of thing.</p></div></blockquote><div><br></div>I'm not sure why C i=
s getting the blame here. C++ has had its problems with binary compatibility=
 across compiler versions etc, but C calling conventions are usually very cl=
early defined. (cdecl/stdcall separation on windows confuses this a bit) Yes=
, a Windows library doesn't work well in Linux, but neither do CLR binaries,=
 Mono is not a serious option for this kind of stuff.<div><br></div><div>Wha=
t is a bigger problem is designing a stable API between major upgrades. This=
 is indeed slightly easier in languages that support overloading methods, li=
ke C++ or C#, compared to plain C. However, TLS 1.2 (and based on the discus=
sion TLS 1.3/2.0 as well) are major updates to the protocol, I don't think i=
t is going to be that easy to do a major upgrade without affecting the API, b=
e it CLR or compiled to native. Having a new crossplatform dynamic loader do=
esn't help much if the API cannot be kept stable, it would only add new rest=
rictions.</div><div><br></div><div>The problem you've brought up is certainl=
y valid, but I'm not sure if the blame is going to the right place. Complex c=
ompilation process of OpenSSL is mostly coming from FIPS requirements as wel=
l and no platform or linker can prevent that, because the problem itself is n=
ot technical but bureaucratic. Some things just can't be avoided, but all id=
eas of how to make TLS upgrades less painful should be taken into account. A=
s much as I'd like to design the protocol from scratch as well, it doesn't h=
elp if no one is going to use it.</div><div><br></div><div><br></div><div>Ju=
ho<br><div><br></div></div></body></html>=

--Apple-Mail-EA1E4120-FAC6-4EAE-AE91-8B6B895C061C--

From watsonbladd@gmail.com  Sun Nov 17 20:50:36 2013
Return-Path: <watsonbladd@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 3C7B611E822A for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 20:50:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.14
X-Spam-Level: 
X-Spam-Status: No, score=-2.14 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QPXtV5655yQw for <tls@ietfa.amsl.com>; Sun, 17 Nov 2013 20:50:35 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6CD11E8165 for <tls@ietf.org>; Sun, 17 Nov 2013 20:50:35 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id t61so5680835wes.16 for <tls@ietf.org>; Sun, 17 Nov 2013 20:50:34 -0800 (PST)
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=GzwR5I9Rfaf65bEMHLHeGf6i0goJnz/BozVgoBYZFII=; b=axnmU3qppzEMy7LmCjTPR30dFer2shtAC4MqDar3Hge4+2whI48pX7yjwdS/2zwYdA liSXBx3dMBUVx+hDFtdaWE6ttyM8JTF2sXE5gmAKKmhEV+mbDkymz0KSGj3UAkaUxj2V 0dAs35PJXwL+cvHYSmj4PFazFzUbUe8eMWpHlV3yvrffaAXJTe83lbPClVgWw8Spl8Ag yUAPYb1PZjkJFsZ05v9hQ8dbs4g/t1os7TqqJ22DzzUGOOHHH5vmrhaVk50/yzrApoM9 gb8k2CSJqJY+g8yeT2hkpkImrtDhmPX6tC9fXB4atfE8OXutlFsoyMeMcksOHnhF5jph TTMQ==
MIME-Version: 1.0
X-Received: by 10.195.13.45 with SMTP id ev13mr15046958wjd.20.1384750234352; Sun, 17 Nov 2013 20:50:34 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sun, 17 Nov 2013 20:50:34 -0800 (PST)
In-Reply-To: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi>
Date: Sun, 17 Nov 2013 20:50:34 -0800
Message-ID: <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= <juhovh@iki.fi>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>, Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Mon, 18 Nov 2013 04:50:37 -0000

TLS 1.2 solves the same problem as TLS 1.0. It should therefore have
the same API.
Somehow, having a state machine driven by data coming from a socket
driven by various options is
hard to design a good API around. (Seriously, transition(stateobject,
data_fed_in, length of data, data_maybe_coming_out, length_out) and
getcurrentstate(stateobject) together with some queries and setup of
options would do just fine.)

Part of the reason for the lack of updates is good Internet
citizenship brings no rewards. F5 customers don't give a damn about
holding the rest of
us back so long as that little lock icon still appears, embedded
device makers see no reason to upgrade, etc. Add this to the fight of
browser makers for market share, and anything that is good to do/has a
risk of breaking some sites will not get done.

The complexity of OpenSSL building, and most of the complexity of
OpenSSL is purely gratuitous. There is no reason it cannot be as clear
as the Go TLS library or PolarSSL.

This of course means that we have to live with whatever choices we
make for a long time, and ensure that implementations are simple
enough
to be bug-free.
Sincerely,
Watson Ladd

From rsalz@akamai.com  Mon Nov 18 07:12:31 2013
Return-Path: <rsalz@akamai.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 340AF11E81DF for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 07:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 dH8Xi30pHs-k for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 07:12:23 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB711E8142 for <tls@ietf.org>; Mon, 18 Nov 2013 07:02:51 -0800 (PST)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7D45D165546; Mon, 18 Nov 2013 15:02:50 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 71FAF165537; Mon, 18 Nov 2013 15:02:50 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 43F992FD51; Mon, 18 Nov 2013 15:02:50 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Mon, 18 Nov 2013 10:02:49 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 18 Nov 2013 10:02:49 -0500
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: Ac7kGbucNmJmDST8Q5OvY22hs5M9cQAVWqwA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com>
In-Reply-To: <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Mon, 18 Nov 2013 15:12:31 -0000

> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the =
same API.

Do you really believe this or are you trying to just be provocative?


-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA

From watsonbladd@gmail.com  Mon Nov 18 08:35:15 2013
Return-Path: <watsonbladd@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 94B4911E811A for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 08:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.33
X-Spam-Level: 
X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.270,  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 YG4wTihVN1LS for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 08:35:13 -0800 (PST)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC1D11E810F for <tls@ietf.org>; Mon, 18 Nov 2013 08:34:44 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id y10so6322620wgg.2 for <tls@ietf.org>; Mon, 18 Nov 2013 08:34:43 -0800 (PST)
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=ycxaeC7Zn3EHFlnZScHIsJLwAc+8bw5JSKZC/W81Mbk=; b=1InL+WJ6crX6h51NSrKG2746n6k4MUZ7eLrlkgdK4suzn7HkS2WOj2ave4TjW8j7Oq tx3uTkAoXok9I7V8BcKfnwJ9C+2NO0U3mJDnNlwVcIgdVdDk1ofK3wcoBgBYMMOtzD1L 2a3jkubO8zO+3jplv7rxAhp1awly83PzpWxCwe2kXi2GkR8OOq51CaE0N3wkyya3Q5gg XcmwvCK0inlffXd2fRQniVM5oaoRNCgtSAOTBID4u6q+O1RYi1MJBvvHyaKS7XtyXkkG TWyTYnlqSmokAmJA85bus4IOjVeVEmE05RMOzGy0sjpUWBL0Q7naYz5nu7UH57GLbmBl EV8g==
MIME-Version: 1.0
X-Received: by 10.180.103.193 with SMTP id fy1mr5100365wib.10.1384792483514; Mon, 18 Nov 2013 08:34:43 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 18 Nov 2013 08:34:43 -0800 (PST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com>
Date: Mon, 18 Nov 2013 08:34:43 -0800
Message-ID: <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Mon, 18 Nov 2013 16:35:15 -0000

On Mon, Nov 18, 2013 at 7:02 AM, Salz, Rich <rsalz@akamai.com> wrote:
>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.
>
> Do you really believe this or are you trying to just be provocative?
Do you really believe that backwards compatibility at the source level
had to be sacrificed?
Stable interfaces are the norm, unstable ones are remarkable. How many
prongs does a ground-fault detecting electricity socket have?
BLAS has multiple implementations, all with the same API. MPI looks
the same on a bunch of Xboxes wired together with Ethernet as it does
on a several million dollar supercomputer. GMP doesn't gratuitously
change its interface with every performance enhancement, and to this
day "Hello World" works unchanged on my machine, some 40 years after
it first ran on a PDP-11. Everything about the environment it runs on
is different, from the word size, to the endianness, to the output
mechanism, to the interface I am using. And yet it works with only a
recompile.

TCP has undergone many changes to the implementation, yet the BSD
sockets API still works. Why exactly does an application need to care
about which ciphersuite is used? Why does it need to do more than hand
over some trusted PKI roots, and a server certificate?

The current APIs have caused lots of security bugs as people don't use
them correctly. The solution: high level APIs that won't change when
the implementation is upgraded. Is this really too lofty a goal? The
costs of the current approach are obvious: what are the costs of
making better APIs?
Sincerely,
Watson Ladd

>
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From rsalz@akamai.com  Mon Nov 18 08:44:03 2013
Return-Path: <rsalz@akamai.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 C5DF011E80E7 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 08:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level: 
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ALpWRxRSmKot for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 08:43:58 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 718E211E817E for <tls@ietf.org>; Mon, 18 Nov 2013 08:41:23 -0800 (PST)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E6ADE284CB; Mon, 18 Nov 2013 16:41:19 +0000 (GMT)
Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id D2AA9284CA; Mon, 18 Nov 2013 16:41:19 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id C5C3EFE066; Mon, 18 Nov 2013 16:41:19 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 18 Nov 2013 11:41:19 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 18 Nov 2013 11:41:19 -0500
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: Ac7kfBeeKuyRm2B6TUqjs7sOGYBRBQAAFSTA
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com>
In-Reply-To: <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
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: Mon, 18 Nov 2013 16:44:03 -0000

VGhlc2Ugc2VlbSBjb250cmFkaWN0b3J5IHRvIG1lOg0KDQo+PiBUTFMgMS4yIHNvbHZlcyB0aGUg
c2FtZSBwcm9ibGVtIGFzIFRMUyAxLjAuIEl0IHNob3VsZCB0aGVyZWZvcmUgaGF2ZSB0aGUgc2Ft
ZSBBUEkuDQo+IFRoZSBjdXJyZW50IEFQSXMgaGF2ZSBjYXVzZWQgbG90cyBvZiBzZWN1cml0eSBi
dWdzIGFzIHBlb3BsZSBkb24ndCB1c2UgdGhlbSBjb3JyZWN0bHkuIFRoZSBzb2x1dGlvbjogaGln
aCBsZXZlbCBBUElzIHRoYXQgd29uJ3QgY2hhbmdlIC4uLg0KDQpUaGUgSUVURiBoYXMgdHJhZGl0
aW9uYWxseSBhdm9pZGVkIEFQSSdzIGFuZCBkb2Vzbid0IGdldCBpbnZvbHZlZCBpbiBoaWdoLWxl
dmVsIGxhbmd1YWdlIHdhcnMgKG90aGVyIHRoYW4gQVNOLjEvREVSIHZzIEFTQ0lJIGFydCA6KQ0K
DQoJL3IkDQoNCi0tICANClByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcg0KQWthbWFpIFRlY2hu
b2xvZ3kNCkNhbWJyaWRnZSwgTUENCg==

From SRS0=lvm6=U3=acm.org=bmoeller@srs.kundenserver.de  Mon Nov 18 09:09:21 2013
Return-Path: <SRS0=lvm6=U3=acm.org=bmoeller@srs.kundenserver.de>
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 C741E11E817B for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 09:09:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.626
X-Spam-Level: 
X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=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 bDfDHTbuqMZo for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 09:09:15 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8837811E8190 for <tls@ietf.org>; Mon, 18 Nov 2013 09:08:25 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MbK2G-1W15ed1fm8-00J5iI; Mon, 18 Nov 2013 18:08:23 +0100
Received: by mail-ob0-f172.google.com with SMTP id gq1so2178657obb.17 for <tls@ietf.org>; Mon, 18 Nov 2013 09:08:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uKSQgRbOWui6SvaGcTab9vuPfNw8Q3YF+sSQDmvprEs=; b=bUnYQPxCjFiJkcRerYJG6tVwm6QoykMJSuoo1RjB81VQ5vapLRKlm9NKskS8xD2tPA AKw5FOciuv7M739lWU3jM73vv70TkseeDyRveRkALJmPv0pg3WsJRl1GAe/nHXK9oSgL s32nnLynjgP9FcALA1UYC6YEV+t3Z1Ylu4uj3J4N8W70vwkxiZSMG/GKi1vAPkmtHKrP g0oNydZkRjP5Yb4XwiieeEWyAxxU1hQvWlw84wwtfjiVmulOeXrWhjAXtD29Ptpag3q2 ZXHRPlYPlOSVRc5FdJOT0VoLiRKslyp+cphBKVWDxMHSemxL5263zH2GQQObLcD8TyOP QdiA==
MIME-Version: 1.0
X-Received: by 10.60.145.241 with SMTP id sx17mr1483634oeb.57.1384794502205; Mon, 18 Nov 2013 09:08:22 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Mon, 18 Nov 2013 09:08:22 -0800 (PST)
In-Reply-To: <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com> <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com> <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Mon, 18 Nov 2013 18:08:22 +0100
Message-ID: <CADMpkcKWNEw-LaMG7dXS50S0Gikxa5HnYp2m-O5o_fJKXSOk9Q@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Marsh Ray <maray@microsoft.com>
Content-Type: multipart/alternative; boundary=047d7b5d474a641bbc04eb769889
X-Provags-ID: V02:K0:4rIPGnb3/ve2kRdyQdG/Yf4BiLYLPkFZsiuXnR/j7r0 SQm4uQf7CQ1UQl9mjoTz83nz2jKqpxpp/80bRZ9BVPoUpq7Q+s ldrYyO79bkzs7mJuZnKSKPJtTBoH6XwuD9/XQVfuTnzlPNwWB/ MmOQ1Fu8DM510zR1z7MEws24lZ/ymJDVyxDCNohIn+uJFcZYD4 xnbYcF31mdfahUIyt0ArOHnh0l3KgSIlY/jD+CCJLid4mg1rky lgVRLTNTTVKq+bzJkRjXO8WhgjaCgxyrneU+Udtrnp59D7FhpK obUGTC1oGAvbjse39Q3fkqYAFIIfk5JolIyZFzqPVejw6jsaei aS8Q0xq3kUb8CE4xRHk8O335fcyh6YKeCpA86kYTaOUZPU2In0 CSx6++z8AeyRNt66T4WcGqjIULjz2S0P0Ot1nlbpGLcSN/CuoC dItSM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
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: Mon, 18 Nov 2013 17:12:41 -0000

--047d7b5d474a641bbc04eb769889
Content-Type: text/plain; charset=ISO-8859-1

>
> Yeah, I didn't mean to imply so much that HMAC is the One True MAC or that
> integrated AE modes can never be defensible. Just that
> MAC-(then|and)-Encrypt are broken while Encrypt-then-HMAC is a very
> conservative design which has stood the test of time and emerged victorious.



 See: https://twitter.com/elwoz/status/401135814307889152
> Figure 2 from http://eprint.iacr.org/2000/025
>
>
While you are right, http://eprint.iacr.org/2000/025 alone isn't why MtE is
broken (and https://twitter.com/marshray/status/401147046767239169/photo/1thus
is a gross over-simplification -- not that there's anything wrong with
that, per se ...).

That Bellare/Namprempre paper did show that MtE is not *generically*
secure.  However, there's also http://eprint.iacr.org/2001/045 =
http://www.iacr.org/archive/crypto2001/21390309.pdf, showing (sort of) that
MtE *is* secure if E specifically is, for example, CBC encryption.  Well,
we all know how well *that* went [*][**] ... but the various problems with
CBC ciphersuites are not implied by the Bellare/Namprempre paper.

[*] See Paterson/Watson, "Authenticated-Encryption with Padding: A Formal
Security Treatment", 2011, for a more complete truth.  That article is
behind a paywall, but Kenny conveniently provided this pointer to Gaven's
thesis: http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf

[**] I must have my hand-written slides somewhere ...
http://www.iacr.org/conferences/crypto2002/rump-prog.html

Bodo

--047d7b5d474a641bbc04eb769889
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-family:arial,sans-ser=
if;font-size:13px">Yeah, I didn&#39;t mean to imply so much that HMAC is th=
e One True MAC or that integrated AE modes can never be defensible. Just th=
at MAC-(then|and)-Encrypt are broken while Encrypt-then-HMAC is a very cons=
ervative design which has stood the test of time and emerged victorious.</s=
pan></blockquote>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">=A0</blockquote><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
See: <a href=3D"https://twitter.com/elwoz/status/401135814307889152" target=
=3D"_blank">https://twitter.com/elwoz/status/401135814307889152</a><br>
Figure 2 from <a href=3D"http://eprint.iacr.org/2000/025" target=3D"_blank"=
>http://eprint.iacr.org/2000/025</a><br>
<div><br></div></blockquote><div><br></div><div>While you are right, <a hre=
f=3D"http://eprint.iacr.org/2000/025" target=3D"_blank">http://eprint.iacr.=
org/2000/025</a> alone isn&#39;t why MtE is broken (and <a href=3D"https://=
twitter.com/marshray/status/401147046767239169/photo/1" target=3D"_blank">h=
ttps://twitter.com/marshray/status/401147046767239169/photo/1</a> thus is a=
 gross over-simplification -- not that there&#39;s anything wrong with that=
, per se ...).</div>

<div><br></div><div>That Bellare/Namprempre paper did show that MtE is not =
*generically* secure. =A0However, there&#39;s also <a href=3D"http://eprint=
.iacr.org/2001/045" target=3D"_blank">http://eprint.iacr.org/2001/045</a> =
=3D <a href=3D"http://www.iacr.org/archive/crypto2001/21390309.pdf" target=
=3D"_blank">http://www.iacr.org/archive/crypto2001/21390309.pdf</a>, showin=
g (sort of) that MtE *is* secure if E specifically is, for example, CBC enc=
ryption. =A0Well, we all know how well *that* went [*][**] ... but the vari=
ous problems with CBC ciphersuites are not implied by the Bellare/Namprempr=
e paper.</div>
<div><br></div><div>[*] See Paterson/Watson, &quot;Authenticated-Encryption=
 with Padding: A Formal Security Treatment&quot;, 2011, for a more complete=
 truth. =A0That article is behind a paywall, but Kenny conveniently provide=
d this pointer to Gaven&#39;s thesis: <a href=3D"http://www.isg.rhul.ac.uk/=
~kp/theses/GWthesis.pdf">http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf<=
/a></div>
<div><br></div><div>[**] I must have my hand-written slides somewhere ... <=
a href=3D"http://www.iacr.org/conferences/crypto2002/rump-prog.html" target=
=3D"_blank">http://www.iacr.org/conferences/crypto2002/rump-prog.html</a>=
=A0</div>

<div><br></div><div>Bodo</div><div><br></div></div></div></div>

--047d7b5d474a641bbc04eb769889--

From Andrei.Popov@microsoft.com  Mon Nov 18 11:04:32 2013
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828D01ACCDA for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level: 
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouo4A8wcjv9f for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:04:30 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4300B1ADFB6 for <tls@ietf.org>; Mon, 18 Nov 2013 11:02:10 -0800 (PST)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB195.namprd03.prod.outlook.com (10.255.230.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 19:02:03 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.47]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.47]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 19:02:03 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Yoav Nir <ynir@checkpoint.com>
Thread-Topic: [TLS] Deployment ... Re:  This working group has failed
Thread-Index: AQHO4rSlvcE/bUSuv06ARL36VO/SBpooKLUAgAESAICAAAvPgIACDiBQ
Date: Mon, 18 Nov 2013 19:02:02 +0000
Message-ID: <06a3c2e5ba2b451a80cd05b18e8f4f72@BL2PR03MB194.namprd03.prod.outlook.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <5287B4F6.1060102@defuse.ca> <52889ACF.3050302@gmx.net> <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
In-Reply-To: <11586138-5410-404B-905F-CEA1DEBF6DE1@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
x-forefront-prvs: 00342DD5BC
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(199002)(189002)(24454002)(51704005)(13464003)(59766001)(77982001)(74366001)(2656002)(56816003)(87266001)(63696002)(77096001)(79102001)(76576001)(87936001)(76786001)(76796001)(31966008)(83072001)(33646001)(56776001)(54316002)(74316001)(74662001)(74502001)(47446002)(51856001)(81542001)(15975445006)(19580395003)(19580405001)(46102001)(74706001)(54356001)(69226001)(83322001)(53806001)(4396001)(47736001)(50986001)(49866001)(80976001)(47976001)(81686001)(80022001)(85306002)(81816001)(65816001)(81342001)(76482001)(74876001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB195; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org list" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re:  This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 19:04:32 -0000

Hi Yoav,

Yes, the percentage if servers that can't handle TLS1.2 or gracefully negot=
iate a lower protocol version is diminishing, but very slowly. From my pers=
pective, enabling TLS1.2 by default is necessitated primarily by security a=
nd performance considerations (e.g. a chance to negotiate AES_GCM instead o=
f RC4). However, for web browsers, enabling TLS1.2 by default means one mor=
e step in the sequence of (insecure) reconnect attempts with lower protocol=
 versions.

Cheers,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Yoav =
Nir
Sent: Sunday, November 17, 2013 3:13 AM
To: Hannes Tschofenig
Cc: tls@ietf.org list
Subject: Re: [TLS] Deployment ... Re: This working group has failed


On Nov 17, 2013, at 12:30 PM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>=
 wrote:

> Hi Taylor,
>=20
> Would be interesting to hear from someone working for Mozilla (like Ekr, =
our TLS WG chair) why things are progressing so slowly and what exactly the=
ir problem is.
>=20

Hi Hannes

We have heard before from people at Google and at Microsoft. Google only ad=
ded TLS 1.2 very recently, and Microsoft added it very early, but disabled =
it by default for a long time.

There were issues with failures of connections attempts using TLS 1.2.  The=
re have been issues with 1.1, but 1.2 produced much more of them.

 1. TLS 1.2 is the first version to require support of extensions. Some ser=
vers broke when extensions existed.
 2. Some servers broke on unrecognized extensions.
 3. Some server break on missing extensions - certain servers will not acce=
pt a TLS 1.2 ClientHello without the SignatureAlgorithm extension

Combining 1 & 3, you can't win. Some servers just won't work.

I don't know what changed. Perhaps the percentage of servers that are broke=
n like that has diminished. But not it looks like the browser vendors have =
deemed it as sufficiently low to allow them to make this on by default.

Yoav

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From mrex@sap.com  Mon Nov 18 11:25:48 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6A41ADFB9 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level: 
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTLKPcNQl-J3 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:25:46 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 316191AE0BC for <tls@ietf.org>; Mon, 18 Nov 2013 11:25:46 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAIJPWEM015597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 20:25:32 +0100 (MET)
In-Reply-To: <06a3c2e5ba2b451a80cd05b18e8f4f72@BL2PR03MB194.namprd03.prod.outlook.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Date: Mon, 18 Nov 2013 20:25:32 +0100 (CET)
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: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org list" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 18 Nov 2013 19:25:48 -0000

Andrei Popov wrote:
> 
> Yes, the percentage if servers that can't handle TLS1.2 or gracefully
> negotiate a lower protocol version is diminishing, but very slowly.

Unfortunately, I've seen a new (government mandated) Web Service usage
scenario deployed in 2013 where the hardware SSL/TLS accellerater that
is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.


We really need to get rid of the dependency on ClientHello.client_version
being { 0x03, 0x03 } to use protocol features that can be implemented
with fairly little effort in TLSv1.0, thereby obviating the need
for reconnect fallbacks in clients -- a "feature" that most programmatic
TLS clients do not have, and that is susceptible to downgrade.


>
> From my perspective, enabling TLS1.2 by default is necessitated
> primarily by security and performance considerations (e.g. a chance
> to negotiate AES_GCM instead of RC4).

The interoperability problems from sending
ClientHello.client_version { 0x03,0x03 } are to serious and significant
to ignore, and the kludges (reconnect fallbacks) are to cumbersome
for most apps.

The _correct_ approach would be to publish how to use GenericAEADCipher
record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and
remove the braindead "must not send this ciphersuite with client_version
less that TLSv1.2" from the AES-CCM and AES-GCM documents.


rfc5746 deployed with significantly less interop problems than both
TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).


>
> However, for web browsers, enabling TLS1.2 by default means one more
> step in the sequence of (insecure) reconnect attempts with lower
> protocol versions.


Rather than bulding such kludges into Browsers, the implementers
should have come to the TLS WG help working on changes to TLS that
will make all desired TLS features work in a more backwards compatible
fashion than through kicking "client_version" / "protocol_version" fields.


-Martin

From mrex@sap.com  Mon Nov 18 11:32:17 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C219F1AE129 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Level: 
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpiBLzCIxNQZ for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 11:32:17 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1131AE128 for <tls@ietf.org>; Mon, 18 Nov 2013 11:32:16 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAIJW7RJ017517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 20:32:07 +0100 (MET)
In-Reply-To: <52889ACF.3050302@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Date: Mon, 18 Nov 2013 20:32:07 +0100 (CET)
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: <20131118193207.57F8A1AAB0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 18 Nov 2013 19:32:18 -0000

Hannes Tschofenig wrote:
> 
> Would be interesting to hear from someone working for Mozilla (like Ekr, 
> our TLS WG chair) why things are progressing so slowly and what exactly 
> their problem is.

The lack of real value in TLSv1.1, the additional weaknesses of TLSv1.2,
and the interoperability problem of sending ClientHello.client_version
with a value higher than { 0x03, 0x01 }.

Did any browser try to ship TLSv1.1 or TLSv1.2 without including
a reconnect fallback facility?  How many browsers did reconnect fallbacks
prior to using TLSv1.1 or TLSv1.2?

The reasons for TLSv1.1/TLSv1.2 not deploying is not very much different
from why IPv6 is not deploying.  Huge complexity and negligible value.

-Martin

From watsonbladd@gmail.com  Mon Nov 18 12:02:25 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D993B1AE1E8 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 12:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG52_r8Mp5dZ for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 12:02:24 -0800 (PST)
Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0078A1AE1C5 for <tls@ietf.org>; Mon, 18 Nov 2013 12:02:23 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id t60so1747831wes.17 for <tls@ietf.org>; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
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=ygYpB0Y1BVocJCis9zp/OLvAK8XMu1n4nTB6u2/B9dM=; b=kk+MNdGNxcOVIG2Dhd7KHpkVtl1ZSeIAf9IalQtHjkeEfwgRpOS3+uUewlsQ8mX/NM 47WwV/B64sE3ZXstfFZvS1bv7X9W2ZAKphKQpjSDzEsVN30mWxxI+R/sB5uPvhCfVlrW 5ZVZOQKdIQ+Gnm5aMdCw3T/kFY1/kojB6wb0fK/LmCyxEH1YT++OdR9Rb/7jDefOX95s lX3fP4pIBQsCrMPGo/iEDLNYJBXO52NaHjZReQw+mkfE4Lq0pvd6o2j/duQKRMg/qCJq YldP9/FAs9Y8SW2E4CMTfcfnk09A+eqHpt7oRpshn87iDKoIjvmvHzFD9RfPTIHv96n4 0aBA==
MIME-Version: 1.0
X-Received: by 10.194.109.68 with SMTP id hq4mr18451318wjb.12.1384804936597; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 18 Nov 2013 12:02:16 -0800 (PST)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
Date: Mon, 18 Nov 2013 12:02:16 -0800
Message-ID: <CACsn0c=txtnpu6CbDVfRb-DFqyh4NwBv2ehXds-HYh2NR=XTEQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary=089e0102e6da5446ea04eb7906fa
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 20:02:26 -0000

--089e0102e6da5446ea04eb7906fa
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 18, 2013 at 8:41 AM, Salz, Rich <rsalz@akamai.com> wrote:
> These seem contradictory to me:
>
>>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have
the same API.
>> The current APIs have caused lots of security bugs as people don't use
them correctly. The solution: high level APIs that won't change ...
The point is to do it right for both TLS 1.2 and TLS 1.0. If you expose
details you shouldn't you are not going to be able to keep them stable
or used correctly.
>
> The IETF has traditionally avoided API's and doesn't get involved in
high-level language wars (other than ASN.1/DER vs ASCII art :)
I vote ASCII art: it keeps the specs simple by imposing a cost on
complexity. Now, someone try making ASCII art for all of TLS.

As for the API issue, I am not suggesting that we standardize it anymore
than the IPSEC people standardized F/SWAN. Rather I am suggesting that we
view the lamentable state of the OpenSSL and NSS source code as problems
that are keeping RC4 alive.

If the WG wants to ignore the need for reference implementations and
interoperability testing fine. But that is not the way successful standards
have emerged from the IETF.
>
> /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA

-- 
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin

--089e0102e6da5446ea04eb7906fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"></p>
<p dir=3D"ltr">On Mon, Nov 18, 2013 at 8:41 AM, Salz, Rich &lt;<a href=3D"m=
ailto:rsalz@akamai.com">rsalz@akamai.com</a>&gt; wrote:<br>
&gt; These seem contradictory to me:<br>
&gt;<br>
&gt;&gt;&gt; TLS 1.2 solves the same problem as TLS 1.0. It should therefor=
e have the same API.<br>
&gt;&gt; The current APIs have caused lots of security bugs as people don&#=
39;t use them correctly. The solution: high level APIs that won&#39;t chang=
e ...<br>
The point is to do it right for both TLS 1.2 and TLS 1.0. If you expose det=
ails you shouldn&#39;t you are not going to be able to keep them stable<br>
or used correctly.<br>
&gt;<br>
&gt; The IETF has traditionally avoided API&#39;s and doesn&#39;t get invol=
ved in high-level language wars (other than ASN.1/DER vs ASCII art :)<br>
I vote ASCII art: it keeps the specs simple by imposing a cost on complexit=
y. Now, someone try making ASCII art for all of TLS.</p>
<p dir=3D"ltr">As for the API issue, I am not suggesting that we standardiz=
e it anymore than the IPSEC people standardized F/SWAN. Rather I am suggest=
ing that we view the lamentable state of the OpenSSL and NSS source code as=
 problems that are keeping RC4 alive.</p>

<p dir=3D"ltr">If the WG wants to ignore the need for reference implementat=
ions and interoperability testing fine. But that is not the way successful =
standards have emerged from the IETF.<br>
&gt;<br>
&gt; /r$<br>
&gt;<br>
&gt; --<br>
&gt; Principal Security Engineer<br>
&gt; Akamai Technology<br>
&gt; Cambridge, MA<br><br></p>
<p dir=3D"ltr">-- <br>
&quot;Those who would give up Essential Liberty to purchase a little Tempor=
ary Safety deserve neither Liberty nor Safety.&quot;<br>
-- Benjamin Franklin</p>

--089e0102e6da5446ea04eb7906fa--

From zooko@leastauthority.com  Mon Nov 18 13:34:58 2013
Return-Path: <zooko@leastauthority.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A27D1AE53F for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 13:34:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.079
X-Spam-Level: 
X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFbNlZ7zgsRI for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 13:34:56 -0800 (PST)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id E59951AE539 for <tls@ietf.org>; Mon, 18 Nov 2013 13:34:55 -0800 (PST)
Received: by mail-ee0-f41.google.com with SMTP id t10so1551463eei.14 for <tls@ietf.org>; Mon, 18 Nov 2013 13:34:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=F3YyHL5H97+ldySxeteQoc92Xzxiu+PeQzU+i2VrcKg=; b=CgL5rw7pSgpoqC24Nid1QH9xVMw7aTHxdb6/gbWhel0nsvQkoia/XPYk47mgRCV92b I16MKqdqLKgQhQSVVsqPQLGYDFU4+Tt5AoaM0088eVqkcF6Z4aujAQFoUFM4pmfPKRf8 gVBYVMDfMPNfvkqSORstrQWBiM4PVyimwC3okY3zY6IoB3NQFeotmDwGZoAORZ4CF/xg ggdkNuXCwIIIWpiYHZTJ12mLYBo7xyqIavOSfKNR+ArxuJrHuPOnvEtcERuzBm7UBu0z 0ejoxgtzggGDHAYPLQzCuwo/jsYBYoQi6U/vYRP+ghPfngZnt2I3l8klgcWDUG1NDM0I 9QVw==
X-Gm-Message-State: ALoCoQmPqO9P2VKLrIJnf9gkkHKA6aOt+kMTw0wTrPmGIbLiJShEFeB2nLJ0M1vRtMGeetoBxkd7
MIME-Version: 1.0
X-Received: by 10.14.103.69 with SMTP id e45mr6060312eeg.51.1384810489621; Mon, 18 Nov 2013 13:34:49 -0800 (PST)
Received: by 10.223.174.198 with HTTP; Mon, 18 Nov 2013 13:34:49 -0800 (PST)
X-Originating-IP: [67.173.237.98]
Date: Mon, 18 Nov 2013 21:34:49 +0000
Message-ID: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com>
From: Zooko Wilcox-OHearn <zooko@leastauthority.com>
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [TLS] Salsa vs. ChaCha
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 21:34:58 -0000

Folks:

draft-josefsson-salsa20-tls-03 makes it sound as though choosing
ChaCha over Salsa would be trading off security (at least as reflected
by Salsa being an eSTREAM finalist) for performance (at least in
hardware). I don't think this reflects typical beliefs about the
relative merits of these two ciphers.

Instead, I think ChaCha is generally considered to be slightly
stronger than Salsa, in addition to slightly faster (in both software
and hardware).

I hasten to add that in my opinion both Salsa20 and ChaCha20 are very
secure and very efficient and either one would be a fine choice.

However, the best known attacks on ChaCha =C2=B9 are more effective against
Salsa than against ChaCha, breaking 8 rounds (out of 20) of Salsa and
7 rounds (out of 20) of ChaCha.

draft-josefsson-salsa20-tls-03 emphasizes that Salsa was a finalist in
an international competition, and I agree that this is a good point
and a point in Salsa's favor.

It is worth noting that ChaCha serves as the core of the BLAKE hash
function, which was a finalist in the SHA-3 competition. The final
report from NIST stated that BLAKE was studied even more thoroughly
during that competition than the ultimate winner, Keccak, was:

"Gr=C3=B8stl, Skein, and BLAKE have a large number of attack papers
reflecting considerable depth of analysis, and Keccak has somewhat
less, but still received considerable cryptanalytic attention." (see
section 4.2.1 of =C2=B2)

Here's a quick sketch of the relationship between BLAKE and ChaCha, to
show why the cryptanalytic attention lavished on BLAKE during the
SHA-3 competition should increase our confidence in the security of
the ChaCha stream cipher.

ChaCha (and Salsa) have at their core a fixed-input-length hash
function, called "G()". To use ChaCha (or Salsa) as a stream cipher,
you put in your secret key, a nonce, and a counter-value as the input
to G(), take the fixed-length (e.g. 64-byte) output from G() and use
that as a "keystream" by XOR'ing the next 64 bytes of your plaintext
with it to produce the next 64 bytes of your ciphertext.

BLAKE takes the G() function from ChaCha, lets the input to G() be the
"chaining value", and tweaks G by adding-in the words of the next
chunk of the message during the computation of G.

So, unfortunately there is no "provable security" reduction by which
we can show that *any* attack on BLAKE must necessarily lead to an
attack on ChaCha, or vice versa.

However, they are so closely related that in my opinion the copious
cryptanalysis of BLAKE during the SHA-3 contest would probably have
revealed weaknesses in ChaCha at the same time as it revealed any
weaknesses in BLAKE.

Disclosure: I was so impressed with BLAKE when I saw it in the SHA-3
contest, that I later collaborated in the definition of "BLAKE2", a
successor algorithm: https://blake2.net/

=C2=B9 http://eprint.iacr.org/2007/472

=C2=B2 http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.

From geoffk@geoffk.org  Mon Nov 18 13:42:03 2013
Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BA61AE58C for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 13:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiXqmA9d_xK1 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 13:42:02 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id B74E01AE587 for <tls@ietf.org>; Mon, 18 Nov 2013 13:42:01 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 4BB0433D108; Mon, 18 Nov 2013 21:41:56 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: mrex@sap.com
References: <52889ACF.3050302@gmx.net> <20131118193207.57F8A1AAB0@ld9781.wdf.sap.corp>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 18 Nov 2013 13:41:56 -0800
In-Reply-To: <20131118193207.57F8A1AAB0@ld9781.wdf.sap.corp>
Message-ID: <m2y54lz8t7.fsf@localhost.localdomain>
Lines: 9
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 21:42:04 -0000

mrex@sap.com (Martin Rex) writes:

> How many browsers did reconnect fallbacks prior to using TLSv1.1 or
> TLSv1.2?

I believe both Mozilla and Safari did this.  The first problem you hit
is not version number intolerance, but extension intolerance, and/or
SSLv2-only servers (depending on when this was implemented).  For
example, <https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c16>.

From dharkins@lounge.org  Mon Nov 18 13:51:40 2013
Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453561AE5D8 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 13:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bA-JEgZFvcSJ for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 13:51:39 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1E93B1AE5D7 for <tls@ietf.org>; Mon, 18 Nov 2013 13:51:39 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F158C10224008; Mon, 18 Nov 2013 13:51:27 -0800 (PST)
Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 18 Nov 2013 13:51:28 -0800 (PST)
Message-ID: <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net>
In-Reply-To: <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com>
Date: Mon, 18 Nov 2013 13:51:28 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Ralf Skyper Kaiser" <skyper@thc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 21:51:40 -0000

  Hi Ralf,

On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
> Hi,
>
> could not find it in the draft:
>
> the interoperability with draft-ietf-websec-key-pinning-08 should be
> mentioned explicitly to prevent
> an attack scenario. (e.g. user has pinned certificate for google.com.
> Attacker MITM forces
> client to do tls-pwd. Client should not allow this). E.g. once a host is
> pinned no other server-side
> auth mechanism should be allowed.

  If the client doesn't want to do TLS-pwd then it won't include the
mandatory extension in its client hello and it won't include any TLS-pwd
ciphersuites. I don't see how this attack happens.

  Perhaps the necessary requirements to deal with pinning certificates
for websec should be dealt with in the draft you mention.

  regards,

  Dan.




From Michael.Staubermann@webolution.de  Mon Nov 18 14:16:27 2013
Return-Path: <Michael.Staubermann@webolution.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9F1AE5BD for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 14:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.625
X-Spam-Level: *
X-Spam-Status: No, score=1.625 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1, RP_MATCHES_RCVD=-0.525] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXtK_HoSAoJ2 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 14:16:25 -0800 (PST)
Received: from mail.webolution.de (mail.webolution.de [80.152.246.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0FB1AE5A0 for <tls@ietf.org>; Mon, 18 Nov 2013 14:16:24 -0800 (PST)
Received: from staubermann.webolution.de ([192.168.168.32] helo=StaubermannPC) by mail.webolution.de with esmtp (Exim 4.69) (envelope-from <Michael.Staubermann@webolution.de>) id 1ViX74-0007Cr-1q; Mon, 18 Nov 2013 23:16:15 +0100
From: "Michael Staubermann" <Michael.Staubermann@webolution.de>
To: <mrex@sap.com>
References: <06a3c2e5ba2b451a80cd05b18e8f4f72@BL2PR03MB194.namprd03.prod.outlook.com> <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
In-Reply-To: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
Date: Mon, 18 Nov 2013 23:16:21 +0100
Message-ID: <058f01cee4ab$d28316b0$77894410$@Staubermann@webolution.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7klAYpFvLByF2XRT+Wyac4cfa0jQAFcGNg
Content-Language: de
X-SA-Exim-Connect-IP: 192.168.168.32
X-SA-Exim-Mail-From: Michael.Staubermann@webolution.de
X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000)
X-SA-Exim-Scanned: Yes (on mail.webolution.de)
Cc: tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 22:16:27 -0000

Martin Rex wrote: 


> Unfortunately, I've seen a new (government mandated) Web Service usage
scenario deployed in 2013 where the hardware SSL/TLS accellerater that is
being used is TLS version intolerant to TLSv1.1 and TLSv1.2.

On the other hand we have the (government mandated) requirement to use TLS
1.2 for governmental institutions:


https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2013/Mindeststanda
rd_TLS_1_2_Web-Seiten_des_BSI_13112013.html

Which translates into: 
"The Federal Office for Information Security (BSI ) has 8 October 2013 a
minimum standard for the use of a transport encryption using the TLS
protocol published . A minimum standard to be met by the BSI describes the
safety requirements for a product or service category or methods to achieve
a reasonable minimum protection against IT security threats . With the
release of minimum standards for TLS 1.2 , the BSI has formulated in terms
of Internet users in Germany set a target to which the institutions of the
federal government , including the BSI is now able to work towards.

It lies in the nature of a target that this is in the future. To specify a
destination that you have already achieved, makes little sense from the
perspective of the BSI.

Since migrating to TLS 1.2 usually includes not only software but also
hardware products, this can be a time-consuming process , involving not only
technical and organizational aspects are taken into account. In this
respect, even after the reduction of a specific objective for a transitional
period is quite common and useful. The BSI is accompanying this transition
period and is available to authorities in the migration advice. Also in the
BSI itself the migration takes place in a structured and carefully prepared
process. This process has already begun. Together with his hosting service ,
the BSI is currently working diligently to change the web server on which
the BSI own websites are hosted. First, it's about ending the exclusive use
of the RC4 encryption algorithm. This could already be realized in the short
term. The migration to TLS 1.2 is already initiated."

-mst




From mrex@sap.com  Mon Nov 18 14:31:48 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83E41AE609 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 14:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOqh4rh9qmP3 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 14:31:47 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C08571AE5C5 for <tls@ietf.org>; Mon, 18 Nov 2013 14:31:46 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAIMVeWj002200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Nov 2013 23:31:40 +0100 (MET)
In-Reply-To: <058f01cee4ab$d28316b0$77894410$@Staubermann@webolution.de>
To: Michael Staubermann <Michael.Staubermann@webolution.de>
Date: Mon, 18 Nov 2013 23:31:40 +0100 (CET)
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: <20131118223140.04D361AAB0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 18 Nov 2013 22:31:48 -0000

Michael Staubermann wrote:
> Martin Rex wrote: 
> 
>> 
>> Unfortunately, I've seen a new (government mandated) Web Service usage
> scenario deployed in 2013 where the hardware SSL/TLS accellerater that is
> being used is TLS version intolerant to TLSv1.1 and TLSv1.2.
> 
> On the other hand we have the (government mandated) requirement to use TLS
> 1.2 for governmental institutions:
> 
> https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2013/Mindeststandard_TLS_1_2_Web-Seiten_des_BSI_13112013.html

That is a misunderstanding.

This statement by the German BSI is a mere recommendation,
it is _not_ mandatory to use TLSv1.2.

You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?


The Web Service of the Portugal fiscal authority that businesses have
to submit certain data through a WebService _is_ mandatory.

-Martin

From joshua.davies.tx@gmail.com  Mon Nov 18 14:40:11 2013
Return-Path: <joshua.davies.tx@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F491AE69D for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 14:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGCpwU55Ewq6 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 14:40:09 -0800 (PST)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 767481AE681 for <tls@ietf.org>; Mon, 18 Nov 2013 14:40:09 -0800 (PST)
Received: by mail-ob0-f176.google.com with SMTP id wp4so7772113obc.35 for <tls@ietf.org>; Mon, 18 Nov 2013 14:40:03 -0800 (PST)
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=aGdwFE4UNDvMPM2KHMkeatZEC9VfokbtXWqdz+Jz1Ik=; b=ztgtsqh6UdPgMb2AyDosdx0cK3uOAuCutSQ4EZ98YKx1uO65ghivhuCEZjJ22IhsDH mppZjQaCoDTxsxMMn6zHUESXPXKBwXWw1B8oGVWS6NzSnddDX81PShgsaNIDVJsIlrzE rdvhPL/eBvVvFsBqomCRvNm3E6AnT5t9TiGWmPwcVyHwMDxKczrNMCBycMqxDNi7ilui HnoQTu/cpmwyL4Dbfg3QJQuhnML593vZIdNX72E4YH2dwQb5J08DhG8PEla17jMuSYr/ +jaRLtNzmP6fEiqaqVr1Hbmn2du1BuvZPJpB8coLVFCbvvNZkqK0ktX7VT+BO5rXP3Ph grZw==
MIME-Version: 1.0
X-Received: by 10.60.142.8 with SMTP id rs8mr22350468oeb.34.1384814403660; Mon, 18 Nov 2013 14:40:03 -0800 (PST)
Received: by 10.60.52.45 with HTTP; Mon, 18 Nov 2013 14:40:03 -0800 (PST)
In-Reply-To: <20131118223140.04D361AAB0@ld9781.wdf.sap.corp>
References: <20131118223140.04D361AAB0@ld9781.wdf.sap.corp>
Date: Mon, 18 Nov 2013 16:40:03 -0600
Message-ID: <CADwpFrA2cOHupieYN38onBQNNXvjeh0hg0hZgsMcLd-jBrFP_Q@mail.gmail.com>
From: Joshua Davies <joshua.davies.tx@gmail.com>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=047d7b33cd749c31dd04eb7b3a29
Cc: Michael Staubermann <Michael.Staubermann@webolution.de>, tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Mon, 18 Nov 2013 22:40:11 -0000

--047d7b33cd749c31dd04eb7b3a29
Content-Type: text/plain; charset=ISO-8859-1

> You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?

Really?  How so?  The only major difference (besides the new cipher suites
and modes and such) between TLS 1.1 and TLS 1.2 is the PRF - are you saying
that the TLS 1.1 PRF is stronger than SHA 256?  Has this been proven or is
that just conjecture?


On Mon, Nov 18, 2013 at 4:31 PM, Martin Rex <mrex@sap.com> wrote:

> Michael Staubermann wrote:
> > Martin Rex wrote:
> >
> >>
> >> Unfortunately, I've seen a new (government mandated) Web Service usage
> > scenario deployed in 2013 where the hardware SSL/TLS accellerater that is
> > being used is TLS version intolerant to TLSv1.1 and TLSv1.2.
> >
> > On the other hand we have the (government mandated) requirement to use
> TLS
> > 1.2 for governmental institutions:
> >
> >
> https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2013/Mindeststandard_TLS_1_2_Web-Seiten_des_BSI_13112013.html
>
> That is a misunderstanding.
>
> This statement by the German BSI is a mere recommendation,
> it is _not_ mandatory to use TLSv1.2.
>
> You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?
>
>
> The Web Service of the Portugal fiscal authority that businesses have
> to submit certain data through a WebService _is_ mandatory.
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b33cd749c31dd04eb7b3a29
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=A0<span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(r=
fc4346)?</span><div><br></div><div><span style=3D"font-family:arial,sans-se=
rif;font-size:13px">Really? =A0How so? =A0The only major difference (beside=
s the new=A0</span><font face=3D"arial, sans-serif">cipher suites and modes=
 and such) between TLS 1.1 and TLS 1.2 is the PRF - are you saying that the=
 TLS 1.1 PRF is stronger than SHA 256? =A0Has this been proven or is that j=
ust conjecture?</font></div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Nov 18, 2013 at 4:31 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:mrex@sap.com" target=3D"_blank">mrex@sap.com</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div class=3D"im">Michael Staubermann wrote:<br>
&gt; Martin Rex wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Unfortunately, I&#39;ve seen a new (government mandated) Web Servi=
ce usage<br>
&gt; scenario deployed in 2013 where the hardware SSL/TLS accellerater that=
 is<br>
&gt; being used is TLS version intolerant to TLSv1.1 and TLSv1.2.<br>
&gt;<br>
&gt; On the other hand we have the (government mandated) requirement to use=
 TLS<br>
&gt; 1.2 for governmental institutions:<br>
&gt;<br>
&gt; <a href=3D"https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2=
013/Mindeststandard_TLS_1_2_Web-Seiten_des_BSI_13112013.html" target=3D"_bl=
ank">https://www.bsi.bund.de/DE/Presse/Kurzmitteilungen/Kurzmit2013/Mindest=
standard_TLS_1_2_Web-Seiten_des_BSI_13112013.html</a><br>

<br>
</div>That is a misunderstanding.<br>
<br>
This statement by the German BSI is a mere recommendation,<br>
it is _not_ mandatory to use TLSv1.2.<br>
<br>
You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?<=
br>
<br>
<br>
The Web Service of the Portugal fiscal authority that businesses have<br>
to submit certain data through a WebService _is_ mandatory.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-Martin<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div>

--047d7b33cd749c31dd04eb7b3a29--

From mrex@sap.com  Mon Nov 18 16:02:38 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1911AE5EC for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 16:02:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjieQFTTRdOZ for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 16:02:36 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 172991AD739 for <tls@ietf.org>; Mon, 18 Nov 2013 16:02:35 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAJ02S3A024667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 01:02:28 +0100 (MET)
In-Reply-To: <CADwpFrA2cOHupieYN38onBQNNXvjeh0hg0hZgsMcLd-jBrFP_Q@mail.gmail.com>
To: Joshua Davies <joshua.davies.tx@gmail.com>
Date: Tue, 19 Nov 2013 01:02:24 +0100 (CET)
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: <20131119000224.D46E41AAB1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: Michael Staubermann <Michael.Staubermann@webolution.de>, tls@ietf.org
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 19 Nov 2013 00:02:38 -0000

Joshua Davies wrote:
> > You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?
> 
> Really?  How so?  The only major difference (besides the new cipher suites
> and modes and such) between TLS 1.1 and TLS 1.2 is the PRF - are you saying
> that the TLS 1.1 PRF is stronger than SHA 256?  Has this been proven or is
> that just conjecture?

The TLSv1.1 PRF should be OK for 128-bit signature.

The weakness of TLSv1.2 is in the RSA signatures (digitally signed).
SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination
for digitally signed, which is stronger than SHA1 alone.

TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5), and
the latter is pretty far from 128-bit security.

-Martin

From mrex@sap.com  Mon Nov 18 16:03:57 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49E1AE64F for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 16:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeRNm-eeAPpv for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 16:03:55 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4E1AE650 for <tls@ietf.org>; Mon, 18 Nov 2013 16:03:55 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAJ03mDh010710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 01:03:48 +0100 (MET)
In-Reply-To: <20131119000224.D46E41AAB1@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Tue, 19 Nov 2013 01:03:48 +0100 (CET)
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: <20131119000348.17FC91AAB1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org, Michael Staubermann <Michael.Staubermann@webolution.de>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 19 Nov 2013 00:03:57 -0000

Resent (with correction) Sorry, I seem to be tired.

Martin Rex wrote:
> Joshua Davies wrote:
> > > You are ware that TLSv1.2 (rfc5246 alone) is weaker than TLSv1.1(rfc4346)?
> > 
> > Really?  How so?  The only major difference (besides the new cipher suites
> > and modes and such) between TLS 1.1 and TLS 1.2 is the PRF - are you saying
> > that the TLS 1.1 PRF is stronger than SHA 256?  Has this been proven or is
> > that just conjecture?
 
The TLSv1.1 PRF should be OK for 128-bit security strength.

The weakness of TLSv1.2 is in the RSA signatures (digitally signed).
SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination
for digitally signed, which is stronger than SHA1 alone.
 
TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5), and
the latter is pretty far from 128-bit security.

-Martin

From mrex@sap.com  Mon Nov 18 17:43:28 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C741AE986 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 17:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPG8tIVMRzPg for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 17:43:25 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3A51AE95B for <tls@ietf.org>; Mon, 18 Nov 2013 17:43:25 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAJ1hFwX022938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 02:43:15 +0100 (MET)
In-Reply-To: <1384400970.2092.7.camel@aspire.lan>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Tue, 19 Nov 2013 02:43:15 +0100 (CET)
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: <20131119014315.7A5831AAB1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 19 Nov 2013 01:43:28 -0000

Nikos Mavrogiannopoulos wrote:
> > > 
> > > http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00
> 
> There are two options. (a) Minor changes to the application protocol
> (for all application protocols), or (b) minor changes to the TLS
> protocol. The draft above takes the latter approach.

Personally, I prefer to seperate true fixes
(such as changing mac-pad-encrypt -> pad-mac-encrypt) from
new features.


> 
> I also don't understand what do you mean by heading TLSv1.2-only. The
> proposal in the above draft works from SSL 3.0 to TLS 1.2. There is
> nothing TLS 1.2-specific there.

The AES-CCM and AES-GCM specs take the extreme position that everything
that refers to GenericAEADCipher PDU must be TLSv1.2 exclusively.

I would very much welcome if we could kill this, and let implementors
use GenericAEADCipher with whatever TLS version they see fit.
Such a relaxation should be negotiated, though, to avoid confusion
(and interop problems) with excessively pedantic implementations
that follow obviously flawed suggestions in immature specifications.


> 
> > You proposal adds the padding at the beginning only.  Since the
> > problem exhibited by RC4 is inherent to any XOR-encryption with
> > a pseudo-random-pad, AES-CCM, AES-GCM, etc. I would make such an
> > extension use random fraction, random content, authenticated padding
> > on both sides of the plaintext, with a combined minimum padding length of
> > at least 16 bytes, in order to mitigate statistical attacks on
> > any bias that may be found in the pseudo-random-pad.
> 
> The above draft does:
> 1. prevent padding oracle attacks
> 2. hide the length of the plaintext
> 
> What you propose there is having the plaintext appear and finish in an
> unpredictable position. That's an interesting approach, not handled by
> the draft above.
> 
> In simple terms you're asking for more bells and whistles :)

If you can't be good, at least be good at it.  :)

If you want to retrofit random padding into TLS (and into the stream and
aead cipher PDUs specifically), then you could at least try to mitigate
the most obvious problems with XOR-encryption schemes: the problems with
biases/patterns in the pseudo-random-pad and the possibility to accurately
flip individual bits in the plaintext.


-Martin

From luto@amacapital.net  Mon Nov 18 18:49:02 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7256E1AEAE4 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWzJjkSr1FMB for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:49:00 -0800 (PST)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id F07881AEADF for <tls@ietf.org>; Mon, 18 Nov 2013 18:48:59 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id kp14so6080951pab.9 for <tls@ietf.org>; Mon, 18 Nov 2013 18:48:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zvPTjRODGcJ1dOlS8CWdMSgKv5qzcFNojy/tZ9Thrj0=; b=O4/wB3fGYrHKe5ycmtGn7kxdNm4PosA2qEg42xukhAmmMCLuJ8cJfJ+RQvv9s0S86c 9f6oOkYkFyKVXVCwCKcyudeg/EyHff9EW47KqF453HGCGHrDHeFhxblK7VlHZFcHpxNP AxM7ZMH7JJVMYAD0ORUuh9X9aqzO+Rnri8JNjanT0+WUZLFzBtdMeVfnhWw94iNNrXRP 2rF2m/l02mahehqnUmrBf3Gtyw1oYUlM18nXvheqdrM97xuv6dN8GgHNjoF7GApji+7M Ix7LsMt6gTGFIay+7thhI6759s6mE/0HkogsvP+8FxM9ex9pGtwSoquDztBCm5PNefnD MrRw==
X-Gm-Message-State: ALoCoQnAgUg2LHOIyW4VTnSf4ljU2h3NLNOndJVv06sT/lN9Dmteu7bDCTVcIs8ra8wqJGSCi7Eu
X-Received: by 10.68.235.72 with SMTP id uk8mr16588742pbc.93.1384829334061; Mon, 18 Nov 2013 18:48:54 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id ha10sm26700673pbd.17.2013.11.18.18.48.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 18:48:53 -0800 (PST)
Message-ID: <528AD194.9060003@amacapital.net>
Date: Mon, 18 Nov 2013 18:48:52 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Salz, Rich" <rsalz@akamai.com>, Watson Ladd <watsonbladd@gmail.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>	<52874576.9000708@gmx.net>	<CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>	<44D7624E-75D8-47D3-93BF-97427206E800@iki.fi>	<CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 02:49:02 -0000

On 11/18/2013 07:02 AM, Salz, Rich wrote:
>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.
> 
> Do you really believe this or are you trying to just be provocative?

Watson's right.  OpenSSL is the norm and the OpenSSL API is
fundamentally wrong.  Let's see:

1. Defaults are insane.  (A crypto library should select a reasonable
set of cipher suites, for example.)  To make OpenSSL work decently, you
have to program a large array of poorly documented settings.  Want GCM?
 You have to ask for it.  (To make matters worse, OpenSSL's cipher suite
names don't match the RFC.)

2. New features need silly code in order to work.  Want DHE?  You need
to write code to feed OpenSSL a DH group.  Want ECDHE?  You need to call
a few poorly documented functions.  Want to support ECDHE with more than
one group (since the client can send a list)?  Oh wait, OpenSSL forgot
about that use case.  So, if and when curve25519 gets added to TLS, all
users of OpenSSL will need to start using a new API to support
curve25519 without losing P-256 support.

3. There are no useful diagnostics.  Want decent reports of why a
connection was rejected?  Good luck.  (I think I figured it out as long
as the client speaks SSL3 or higher, but I'm at a loss as to getting a
meaningful diagnostic for SSLv2.)

4. Want to do anything intelligent about certificate validation?  Good
luck understanding that API.

The world needs a good, permissively licensed,
hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
there is, and it has its set of issues, too.

--Andy

From luto@amacapital.net  Mon Nov 18 18:54:03 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3F51AEB18 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn0Ep6RobYDB for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:53:59 -0800 (PST)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9A1AEB0B for <tls@ietf.org>; Mon, 18 Nov 2013 18:53:59 -0800 (PST)
Received: by mail-pa0-f43.google.com with SMTP id fa1so7674201pad.30 for <tls@ietf.org>; Mon, 18 Nov 2013 18:53:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WCQCgchSkfFrUfAavfKEbJnMgF+zrk+0uB8RZTVwWMQ=; b=LMqrnTxp4c3sJzCdcuQOpJiQvKCj8QcggZ6SJtwpzYMtgBVgxfjP73lCS2Q9mJrz5+ EnjgDv6zHBSSy92iGzuJ8KZNoRC/5SnKxOEJtuM+AFRWnY8NC+5cSvpCBCrks9xsBfiI 30hgv0+DO1R0Jqa6d7FwSTDZO6JRvs04x6CwkdWSVi2M9n7Y7IP4IMrVa6fbSbJTmjRD j/hjKQCbhZ2t0XBoFnD1TgsBvzsm2MuFAjmGakrxm2i1cpTAWeCTvpznr4+vHZBMtJmV uGeGjve2gi2t6JbUxof6p7K5hSciZcsWK/KvxkaWXCBTL/5EvHo0ohw2t+kadnQyCPEF TVMQ==
X-Gm-Message-State: ALoCoQkOgP0DtYs9ovBmI4UgWebPKo1k18AoQjYcpb9Z+Sg0Zm8Ho3G2d/QQAj7uL/gZDWWnPLrg
X-Received: by 10.66.197.164 with SMTP id iv4mr20175821pac.18.1384829633895; Mon, 18 Nov 2013 18:53:53 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id tu6sm26700328pbc.41.2013.11.18.18.53.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 18:53:53 -0800 (PST)
Message-ID: <528AD2BF.8070304@amacapital.net>
Date: Mon, 18 Nov 2013 18:53:51 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>, Geoffrey Keating <geoffk@geoffk.org>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>	<m238mv1wkq.fsf@localhost.localdomain> <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
In-Reply-To: <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 02:54:03 -0000

On 11/16/2013 09:29 PM, Eric Rescorla wrote:
> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <geoffk@geoffk.org
> <mailto:geoffk@geoffk.org>> wrote:
> 
>     Then, if people want a key agreement where one side generates a random
>     master key, encrypts it with RSA, and sends it to the other, we can do
>     that.  The RSA key can be ephemeral (or, at least, changed much more
>     often than today's typical "once every two years"), which gives
>     forward secrecy, or the RSA key can be fixed, if forward secrecy is
>     explicitly not wanted
> 
> 
> Oops, yeah, forgot to mention this.
> 
> As you say, it's possible to generate a short-term RSA key and use it
> for multiple connections. This gives some level of forward security.
> 

Except that TLS 1.3 at least doesn't really make this possible with the
way that PKIX works now.  This could be changed.

(For what it's worth, static RSA is faster on the client side than
short-term fixed DH certificates, but fixed DH may result in a cleaner
protocol.  I suspect that fixed ECDH is quite a bit faster than either.)

--Andy

> -Ekr
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From kirils.solovjovs@kirils.com  Mon Nov 18 18:55:45 2013
Return-Path: <kirils.solovjovs@kirils.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248D61AEB31 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_CPILL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwF6l8p3HcKw for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 18:55:42 -0800 (PST)
Received: from ps.id.lv (kirils.org [85.254.196.147]) by ietfa.amsl.com (Postfix) with ESMTP id 80CDE1AEB2F for <tls@ietf.org>; Mon, 18 Nov 2013 18:55:42 -0800 (PST)
Received: from [127.0.0.1] (ps.id.lv [85.254.196.147]) by ps.id.lv (8.14.7/8.12.11) with ESMTP id rAJ2tWbK008786 for <tls@ietf.org>; Tue, 19 Nov 2013 04:55:33 +0200
Message-ID: <528AD326.8080908@kirils.com>
Date: Tue, 19 Nov 2013 02:55:34 +0000
From: Kirils Solovjovs <kirils.solovjovs@kirils.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com>	<52874576.9000708@gmx.net>	<CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com>	<44D7624E-75D8-47D3-93BF-97427206E800@iki.fi>	<CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net>
In-Reply-To: <528AD194.9060003@amacapital.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 02:55:45 -0000

On 2013.11.19. 02:48, Andy Lutomirski wrote:
> On 11/18/2013 07:02 AM, Salz, Rich wrote:
>>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.
>>
>> Do you really believe this or are you trying to just be provocative?
> 
> Watson's right.  OpenSSL is the norm and the OpenSSL API is
> fundamentally wrong.  Let's see:
> 
1..4
> The world needs a good, permissively licensed,
> hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
> there is, and it has its set of issues, too.

Fully seconded, Andy!

Still.. what do you think should be done to alleviate this step by step?

Are you proposing to scrap openssl and start from scratch?

-- 
Kirils Solovjovs

From geoffk@geoffk.org  Mon Nov 18 19:21:07 2013
Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332831AEBB8 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 19:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5EDaJ-FHWUN for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 19:21:05 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 412C01AEBB5 for <tls@ietf.org>; Mon, 18 Nov 2013 19:21:05 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 89E8733D108; Tue, 19 Nov 2013 03:20:59 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Andy Lutomirski <luto@amacapital.net>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <m238mv1wkq.fsf@localhost.localdomain> <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com> <528AD2BF.8070304@amacapital.net>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 18 Nov 2013 19:20:59 -0800
In-Reply-To: <528AD2BF.8070304@amacapital.net>
Message-ID: <m2txf9yt44.fsf@localhost.localdomain>
Lines: 23
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 03:21:07 -0000

Andy Lutomirski <luto@amacapital.net> writes:

> (For what it's worth, static RSA is faster on the client side than
> short-term fixed DH certificates, but fixed DH may result in a cleaner
> protocol.  I suspect that fixed ECDH is quite a bit faster than either.)

I think you'll find fixed ECDH is still slower on the client than
static RSA.  With 'openssl speed' on this system I find that a 256-bit
ECDH takes 0.0013s, and two 2048-bit verify/encrypt operations takes
2*0.000197s=0.000394s, which is 3.3x faster.  (Of course the
signing/decryption operations take 2*0.0074s=0.0148s, which is more
than 10x slower, but that's on the server.)

Of course this changes a lot if you have hardware, but more clients
have RSA in hardware than ECDH in hardware, and if you have to choose
then it's better to have RSA hardware because you'll probably need to
do some more RSA verify operations to check the certificate chain.

Fixed DH and fixed ECDH don't give PFS when used in current TLS.
You could make them do this in a new version of TLS by doing
ephemeral DH or ECDH or RSA, and then using the fixed DH to agree on a
key that is used in a MAC to verify the ephemeral DH public key, but
it's twice as much work (and no-one seems to be using fixed DH anyway).

From luto@amacapital.net  Mon Nov 18 19:42:37 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E117A1AEC46 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 19:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkttBq_h0Puf for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 19:42:36 -0800 (PST)
Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5D1AEC42 for <tls@ietf.org>; Mon, 18 Nov 2013 19:42:34 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so1715241veb.1 for <tls@ietf.org>; Mon, 18 Nov 2013 19:42:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SCkrCLt5HqOJyV5Ch1xyO2h+7HS4GFQxpKumeVTSe+U=; b=ZJBIO9LMCvXd94X6ZIzlHZ1C6HXZcvLR3FSMt22FO/9bdZRs4r1pHtioNvoBv2HivO sghsRq6VqB000Cch7vJyOi3tXm84fM6pQ8lQo3umVkxLsPfOGidL6N65nnx7YNkSAFkU 4YEqvXBFgy5PAVqhx6q8CpCYAg7JFS5Uab6sxHtwueOkZ8JAGTnJumOD8Qr5nLkqKRYV sIyhMHWQci8gzRaRiVmaJYlLa+8RRoFf1gEfU3YnCuXDIbaoWtwfXXzXloJBPa9Y2u8Y jMyxFq27Kq4+W+Sxp4758bw6yrUeQKeINpU5KnMxrMSBVWNrCPyc5zXOZRZHlI3LH6Le /bag==
X-Gm-Message-State: ALoCoQmHoh/0IKt4LrWxHsAV3g3oH47WtvlZ4GLMZKF3FGrNvtBjng5S3J1B+sHB0NZ0q7k24uAX
X-Received: by 10.58.255.233 with SMTP id at9mr6509960ved.20.1384832548708; Mon, 18 Nov 2013 19:42:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Mon, 18 Nov 2013 19:42:08 -0800 (PST)
In-Reply-To: <m2txf9yt44.fsf@localhost.localdomain>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <m238mv1wkq.fsf@localhost.localdomain> <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com> <528AD2BF.8070304@amacapital.net> <m2txf9yt44.fsf@localhost.localdomain>
From: Andy Lutomirski <luto@amacapital.net>
Date: Mon, 18 Nov 2013 19:42:08 -0800
Message-ID: <CALCETrUfYimXRB+wZoYmsffKp8a00=j+XynztSA-sDj6JzJ39g@mail.gmail.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 03:42:38 -0000

On Mon, Nov 18, 2013 at 7:20 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>> (For what it's worth, static RSA is faster on the client side than
>> short-term fixed DH certificates, but fixed DH may result in a cleaner
>> protocol.  I suspect that fixed ECDH is quite a bit faster than either.)
>
> I think you'll find fixed ECDH is still slower on the client than
> static RSA.  With 'openssl speed' on this system I find that a 256-bit
> ECDH takes 0.0013s, and two 2048-bit verify/encrypt operations takes
> 2*0.000197s=0.000394s, which is 3.3x faster.  (Of course the
> signing/decryption operations take 2*0.0074s=0.0148s, which is more
> than 10x slower, but that's on the server.)

I wonder how Curve25519 stacks up.

>
> Of course this changes a lot if you have hardware, but more clients
> have RSA in hardware than ECDH in hardware, and if you have to choose
> then it's better to have RSA hardware because you'll probably need to
> do some more RSA verify operations to check the certificate chain.
>
> Fixed DH and fixed ECDH don't give PFS when used in current TLS.
> You could make them do this in a new version of TLS by doing
> ephemeral DH or ECDH or RSA, and then using the fixed DH to agree on a
> key that is used in a MAC to verify the ephemeral DH public key, but
> it's twice as much work (and no-one seems to be using fixed DH anyway).

Google's QUIC almost has PFS -- they achieve it by signing a very
short-lived set of ECDH parameters using their X.509 certificate and
presenting those ECDH parameters, with signature, to the client.  The
client verifies the signature and does one ECDH calculation.

If those parameters are generated at server startup, flushed every
hour or two, and never hit disk, then it works pretty well.  (Whether
it's better than short-lived RSA keys is debatable.)

--Andy

From andrewgwilson@gmail.com  Mon Nov 18 20:15:20 2013
Return-Path: <andrewgwilson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113221AE344 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 20:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FUZZY_CPILL=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoBzwGXDcSNU for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 20:15:18 -0800 (PST)
Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AF54C1AE8FA for <tls@ietf.org>; Mon, 18 Nov 2013 20:15:17 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id mx12so1202084bkb.20 for <tls@ietf.org>; Mon, 18 Nov 2013 20:15:11 -0800 (PST)
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 :content-type; bh=hgq5mfc3zhVMsBzg49/KdkppjmxqSlBZCtMV/gNdgYQ=; b=Sssc0fEhQAqkE224bGhh5uQF3s+EBGuXdDo71rabrYV5Je7ZrbWCdJuU4QgL0+TLm4 82vpEffWWXEjXrkyNxCR4S3T2zQKtDpelDArSBU2WnAWa0cnlwE+t6ONwWJ1221MR/62 kxdyaNGlKMYQ7qqN9TSG1gupwULXLoJHT2naBmgAqa7vaAz/gdSeBB7cQPfg1A2Drzts ptZlbVl102UeZXcN6vEWRZDbR3fAu7E1vKFDtkvE/YIWBexrtCaSFaQxxTYxkSbDR41S yXNh7bCniXTY7u3u5C2xiVE1TBmbnWHCqWSW/3fRVMFow0gWdZ81BNIV4Z0Z3BKQRwUv dOPA==
MIME-Version: 1.0
X-Received: by 10.204.232.78 with SMTP id jt14mr14686152bkb.3.1384834511213; Mon, 18 Nov 2013 20:15:11 -0800 (PST)
Received: by 10.205.18.193 with HTTP; Mon, 18 Nov 2013 20:15:11 -0800 (PST)
In-Reply-To: <528AD326.8080908@kirils.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com>
Date: Tue, 19 Nov 2013 17:15:11 +1300
Message-ID: <CAL2p+8SU5tXB0pB5NK0KbrFgJ_PB0BdSdRkcKi5nA4CDRJ0fMQ@mail.gmail.com>
From: Andy Wilson <andrewgwilson@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=485b3979d9261d467b04eb7fe90d
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 04:15:20 -0000

--485b3979d9261d467b04eb7fe90d
Content-Type: text/plain; charset=UTF-8

What about PolarSSL?

Surely there's discussions on the OpenSSL mailing lists about some of these
concerns


On 19 November 2013 15:55, Kirils Solovjovs <kirils.solovjovs@kirils.com>wrote:

>
>
> On 2013.11.19. 02:48, Andy Lutomirski wrote:
> > On 11/18/2013 07:02 AM, Salz, Rich wrote:
> >>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have
> the same API.
> >>
> >> Do you really believe this or are you trying to just be provocative?
> >
> > Watson's right.  OpenSSL is the norm and the OpenSSL API is
> > fundamentally wrong.  Let's see:
> >
> 1..4
> > The world needs a good, permissively licensed,
> > hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
> > there is, and it has its set of issues, too.
>
> Fully seconded, Andy!
>
> Still.. what do you think should be done to alleviate this step by step?
>
> Are you proposing to scrap openssl and start from scratch?
>
> --
> Kirils Solovjovs
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Regards

Andy

--485b3979d9261d467b04eb7fe90d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What about PolarSSL?<div><br></div><div>Surely there&#39;s=
 discussions on the OpenSSL mailing lists about some of these concerns</div=
></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On 19 =
November 2013 15:55, Kirils Solovjovs <span dir=3D"ltr">&lt;<a href=3D"mail=
to:kirils.solovjovs@kirils.com" target=3D"_blank">kirils.solovjovs@kirils.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
<br>
On <a href=3D"tel:2013.11.19.%2002" value=3D"+12013111902">2013.11.19. 02</=
a>:48, Andy Lutomirski wrote:<br>
&gt; On 11/18/2013 07:02 AM, Salz, Rich wrote:<br>
&gt;&gt;&gt; TLS 1.2 solves the same problem as TLS 1.0. It should therefor=
e have the same API.<br>
&gt;&gt;<br>
&gt;&gt; Do you really believe this or are you trying to just be provocativ=
e?<br>
&gt;<br>
&gt; Watson&#39;s right. =C2=A0OpenSSL is the norm and the OpenSSL API is<b=
r>
&gt; fundamentally wrong. =C2=A0Let&#39;s see:<br>
&gt;<br>
</div>1..4<br>
<div class=3D"im">&gt; The world needs a good, permissively licensed,<br>
&gt; hard-or-impossible-to-misuse TLS API. =C2=A0GnuTLS is probably the clo=
sest<br>
&gt; there is, and it has its set of issues, too.<br>
<br>
</div>Fully seconded, Andy!<br>
<br>
Still.. what do you think should be done to alleviate this step by step?<br=
>
<br>
Are you proposing to scrap openssl and start from scratch?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Kirils Solovjovs<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Regards<br><br>Andy
</div>

--485b3979d9261d467b04eb7fe90d--

From maray@microsoft.com  Mon Nov 18 21:15:26 2013
Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909EF1AED90 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level: 
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4YuADhI7G3L for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:15:23 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB8F1AED85 for <tls@ietf.org>; Mon, 18 Nov 2013 21:15:23 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB076.namprd03.prod.outlook.com (10.255.241.156) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 05:15:15 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.133]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 05:15:15 +0000
From: Marsh Ray <maray@microsoft.com>
To: Bodo Moeller <bmoeller@acm.org>
Thread-Topic: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
Thread-Index: Ac7he9XegiaaCPP0QGGxMFjRjJVXTgAvwiuAAANTVBAAjidLAAALI2vg
Date: Tue, 19 Nov 2013 05:15:14 +0000
Message-ID: <249d828ed6a743bfabe881e4dfa3d864@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com> <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com> <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com> <CADMpkcKWNEw-LaMG7dXS50S0Gikxa5HnYp2m-O5o_fJKXSOk9Q@mail.gmail.com>
In-Reply-To: <CADMpkcKWNEw-LaMG7dXS50S0Gikxa5HnYp2m-O5o_fJKXSOk9Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [76.121.57.187]
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(199002)(189002)(51704005)(243025003)(83072001)(69226001)(76576001)(15975445006)(15202345003)(63696002)(76786001)(33646001)(77982001)(76796001)(74876001)(74706001)(74366001)(56816003)(54316002)(81816001)(56776001)(77096001)(19300405004)(85306002)(74316001)(59766001)(19580395003)(81686001)(81342001)(50986001)(47976001)(2656002)(74662001)(49866001)(47736001)(81542001)(65816001)(83322001)(80022001)(31966008)(87266001)(4396001)(47446002)(80976001)(74502001)(79102001)(66066001)(87936001)(54356001)(53806001)(51856001)(76482001)(46102001)(24736002)(562404015); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB076; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:76.121.57.187; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 05:15:26 -0000

From: Bodo Moeller
>=20
> While you are right, http://eprint.iacr.org/2000/025 alone
> isn't why MtE is broken (and https://twitter.com/marshray/status/40114704=
6767239169/photo/1
> thus is a gross over-simplification -- not that there's anything
> wrong with that, per se ...).

Gross over-simplification tends to be what Twitter's best at.

AES-GCM good! RC4 bad! :-)

> That Bellare/Namprempre paper did show that MtE is not
> *generically* secure.  However, there's also
> http://eprint.iacr.org/2001/045 =3D
> http://www.iacr.org/archive/crypto2001/21390309.pdf , showing
> (sort of) that MtE *is* secure if E specifically is, for example,
> CBC encryption.  Well, we all know how well *that* went [*][**]
> ... but the various problems with CBC ciphersuites are not implied
> by the Bellare/Namprempre paper.

I feel the world of end users, admins, and other RPs shaking their
collective heads in wonder at these security proofs when they see
a giant flame-shooting robot at a party in Argentina:

http://www.youtube.com/watch?v=3DMxm8JEUXOuQ

... then the presenter proceeds to decrypt traffic to a tier 1
ecommerce website ...

http://www.youtube.com/watch?v=3D4clpbJEWCzE

... and steal the login session cookie using attacks enabled
by CBC A-t-E mode.

All I can figure is that proving A-[at]-E CBC modes are
secure is cryptographers' equivalent of what (Down South where
I come from) we refer to as "Hey Y'all watch this!" E.g.,

http://www.youtube.com/results?search_query=3Dhey+y%27all+watch+this

We have a long, sad, bibliography of *practical* attacks on A-[at]-E,
especially in conjunction with CBC modes. Bellovin, Rogaway, Wei
Dei, Vaudenay (many I missed) . IPsec, SSH, SSL, TLS .
all broken to various degrees. Too many operations where
attacker-supplied data interacts with must-be-kept-secret data.
Straightforward implementations result in side channels. Minor
info leaks turn into oracles. Oracles turn into practical attacks.

Has there ever been a serious attack on HMAC<hashfn> ?

Here's what I found for HMAC<MD4>

Practical Electromagnetic Template Attack on HMAC
by Pierre-alain Fouque, Ga=EBtan Leurent, Denis R=E9al, Fr=E9d=E9ric Valett=
e
(2007?)
> In this paper, we show a very efficient side channel attack against
> HMAC. Our attack assumes the presence of a side channel that
> reveals the Hamming distance of some registers
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.156.4969

But wait, HMAC<MD4> is worse. Again, *MD4*. IIRC TLS has only
ever supported HMAC<MD5> and later.

Full Key-Recovery Attacks on. HMAC/NMAC-MD4 and NMAC-MD5.
Pierre-Alain Fouque, Ga=EBtan Leurent, Phong Q. Nguyen.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=3D10.1.1.98.7316
http://www.di.ens.fr/~fouque/pub/crypto07b.pdf

So if, say, TLS had supported HMAC<MD4> and the adversary had
the ability to make 2^88 record integrity queries, then with
2^95 time he could possibly (in 2007) insert a forged record
in that connection. But he'd better be careful, because if
he breaks it he'll have to start all over.

This technique seems unlikely to be of any use attacking the TLS PRF
"back through" the record MAC, because the PRF operates upon
completely new data with every handshake.

But it looks like SSLv2 used a bare hash rather than HMAC and even had
an option for MD2! Still, it would likely have been the 512 bit RSA certs
that were the weakest link.

Regards,

- Marsh

Unless stated otherwise, these are my own personal opinions.


From maray@microsoft.com  Mon Nov 18 21:44:52 2013
Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F6F1AC4A3 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VA-4zmtTBbb5 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:44:50 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) by ietfa.amsl.com (Postfix) with ESMTP id F3BC31AD9B7 for <tls@ietf.org>; Mon, 18 Nov 2013 21:44:49 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB073.namprd03.prod.outlook.com (10.255.241.153) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 05:44:42 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.133]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 05:44:42 +0000
From: Marsh Ray <maray@microsoft.com>
To: "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: AQHO5JP/WVAZL/KMwUmZ2rNHZIm1mporjnaAgAAESACAAAJXgIAAFwMAgAAAZACAAFnG8A==
Date: Tue, 19 Nov 2013 05:44:41 +0000
Message-ID: <e2d8b5d7303349d1be3d2f2b43cfdb30@BY2PR03MB074.namprd03.prod.outlook.com>
References: <20131119000224.D46E41AAB1@ld9781.wdf.sap.corp> <20131119000348.17FC91AAB1@ld9781.wdf.sap.corp>
In-Reply-To: <20131119000348.17FC91AAB1@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [76.121.57.187]
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(189002)(199002)(87266001)(31966008)(74662001)(2656002)(63696002)(74502001)(74706001)(81686001)(46102001)(81342001)(81542001)(74876001)(85306002)(69226001)(54316002)(56776001)(47446002)(59766001)(51856001)(77982001)(76482001)(83322001)(83072001)(56816003)(54356001)(19580395003)(49866001)(47736001)(4396001)(53806001)(47976001)(50986001)(66066001)(79102001)(15975445006)(80022001)(77096001)(81816001)(76576001)(76786001)(76796001)(87936001)(19580405001)(65816001)(80976001)(33646001)(74316001)(74366001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB073; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:76.121.57.187; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>, Michael Staubermann <Michael.Staubermann@webolution.de>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 05:44:52 -0000

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
>=20
> Resent (with correction) Sorry, I seem to be tired.
>=20
> The TLSv1.1 PRF should be OK for 128-bit security strength.

TLS 1.1 https://tools.ietf.org/html/rfc4346#page-13
"   TLS's PRF is created by splitting the secret into two halves and
   using one half to generate data with P_MD5 and the other half to
   generate data with P_SHA-1, then exclusive-ORing the outputs of these
   two expansion functions together."

Good for 160 bits I figure?

TLS 1.2  https://tools.ietf.org/html/rfc5246#page-14
"   In this section, we define one PRF, based on HMAC.  This PRF with the
   SHA-256 hash function is used for all cipher suites defined in this
   document and in TLS documents published prior to this document when
   TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
   PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
   stronger standard hash function.
"
Sounds stronger to me.

> The weakness of TLSv1.2 is in the RSA signatures (digitally signed).
> SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination for digital=
ly
> signed, which is stronger than SHA1 alone.
>=20
> TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5), and the lat=
ter is
> pretty far from 128-bit security.

But if the attacker can break MD5, he can exploit an MD5 cert chain, right?=
 (e.g., Flamer)
If not, he can't negotiate the use of MD5 for signing the TLS handshake.

If the attacker can break SHA-1, he can exploit a SHA-1 trusted root, right=
?
If not, he can't negotiate the use of SHA-1 for signing the TLS handshake.

So TLS 1.2 just follows the convention established by the available trusted=
 root CA. No configuration that could be stronger than SHA-1 can be weakene=
d to SHA-1. Furthermore, no configuration that could be stronger than SHA-1=
+MD5 can be weakened to SHA-1+MD5.

Or am I missing something?

Are you saying that TLS 1.2 clients in practice MUST send md5 and sha1 in s=
upported_signature_algorithms, even if they trust no MD5 or SHA-1 roots?

- Marsh


From brian@briansmith.org  Mon Nov 18 21:59:05 2013
Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4397D1A1F72 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnZVrDm45-z6 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 21:59:02 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id A5B6F1A1F61 for <tls@ietf.org>; Mon, 18 Nov 2013 21:59:02 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id s19so4473712qcw.21 for <tls@ietf.org>; Mon, 18 Nov 2013 21:58:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZWOa+qPQPSejuxoaK+hzk9aoGD3gDgrFN8qsdfIIxzY=; b=LfaRKzDIzcajGyrSZObVij4UAEIbaUeHXmwDVQGdttGNLh2VsOBFr2pJIYOVb6N1mS VJfA8vZEq4/unpwwKSPVEOAqMprmRqF3ebOSkjfr4nZoxxWXEvdv/aYrxF01bl/1zd5o +NbZvRmMptqzjy0yQZc8dnk3G62IvimP7AtU1co1gjT2zWYu5C4/xV8miwqZJJKBYrWg JUeWUEBiKdIH1Wl+nRiThrmVsPsMOFI+2VAN7PO9A166MxUxOakUrsudKoVPOyO8KC7m YlAqYaharN3V4ftjxt6Bs0iwiH8t2Wm+w8p1xhr9PZJbVZ1qPLVMj8AJGVvAkym8K0n4 f6Tg==
X-Gm-Message-State: ALoCoQkNPmlKdY/zg7pGn/JlDdsanujgepTT5ROKmB17DLbpXHZGg3nq23zJYPQytS9KEKXj6uI3
MIME-Version: 1.0
X-Received: by 10.224.115.146 with SMTP id i18mr40352865qaq.23.1384840736529;  Mon, 18 Nov 2013 21:58:56 -0800 (PST)
Received: by 10.224.38.5 with HTTP; Mon, 18 Nov 2013 21:58:56 -0800 (PST)
X-Originating-IP: [63.245.219.53]
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
Date: Mon, 18 Nov 2013 21:58:56 -0800
Message-ID: <CAFewVt5K07p4UTzpkaXMxscbUuBo-jNB=VGF_cscGY3ZhPss-Q@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Xiaoyong Wu <X.Wu@f5.com>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 05:59:05 -0000

On Wed, Nov 6, 2013 at 10:00 AM, Xiaoyong Wu <X.Wu@f5.com> wrote:
> As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.

Xiaoyong, thank you very much for sharing that with us! That is
incredibly useful.

In the thread "Final nail in the coffin for cleartext SNI/ALPN in TLS
1.3," Yoav Nir <ynir@checkpoint.com> wrote:
> I think it would actually be worse than that. Browsers don't want
> reconnect fallback. So whatever TLS 1.3 looks like, the ClientHello
> that browsers send will be such that it can be accepted by at least
> TLS 1.0 servers (and there are plenty of those around). And as
> others have mentioned, SNI is needed in many cases. Without it,
> https://www.gmail.com will give you a certificate error.
>
> So you might have a clientHello that leads to super-duper TLS 1.3,
> but to avoid the need for fallback, you include the SNI (and
> presumably ALPN) in the ClientHello.

This is exactly right for SNI. Even if we define a new replacement for
SNI, browsers will still be sending SNI in the clear for the next 10
years. We should still try to work toward a long-term solution to that
problem, but it isn't something that can be solved in the short term.

During the TLS WG session at IETF88, somebody commented that TLS 1.3
is supposed to solve the problem of encrypting information in the
ClientHello, so the plaintext vs. cleartext issue shouldn't be a
concern for ALPN. But, for the same reason we can't have any near-term
solution for encrypting SNI in the ClientHello, we won't have any
near-term solution for encrypting ALPN in the ClientHello that would
meet browsers needs.

Again, I want to emphasize that Firefox ALREADY solves this problem,
even without TLS 1.3, by implementing NPN and avoiding ALPN. If other
browsers just turned off ALPN then the problem of how to hide the
protocol negotiation information would be solved. As far as I've been
led to believe, ALPN exists primarily to allow MitM to more easily
inspect what protocol the application is speaking and possibly block
the application, with as low of a cost to the MitM as possible--i.e.
exactly the opposite goal of everything we discussed at IETF88 in
perpass and in other discussions. I still have a lot of trouble
understanding how we can agree in the IETF as a whole that we should
be trying to make attacks more difficult, even if we can't make them
impossible, but here in the TLS WG, we are literally going out of our
way to leak information in the clear unnecessarily.

I think that in many cases, traffic analysis that relies on timing
information will be able to tell with a high degree of accuracy which
protocol has been selected for use on the connection. However, traffic
analysis cannot tell us what protocols were offered but *not*
selected. Further, traffic analysis based on timing is more expensive
and less reliable than having the information given on a silver
platter. In some cases, traffic analysis vs. explicit plaintext
leakage might be the difference between reasonable doubt or not. In
other cases, the difficulty of discerning two protocols--whether you
are sending email (SMTP) or pinging the server to retrieve email
(IMAP) vs loading the login page (HTTP)--may increase the storage and
processing cost by an order of magnitude or more, if we can get it to
work. Personally, I'm disappointed to hear the arguments that it is
not worthwhile to consider trying to solve that problem in the context
of the design of ALPN, because we worry it is unsolvable. I feel like
we haven't even started trying to solve it yet, so I don't understand
why we're giving up so easily.

Further, I don't see a need to rush to a conclusion on ALPN for HTTP/2
given this chart:
https://github.com/http2/http2-spec/wiki/Implementations

At the time I write this, 11/13 support NPN. 6/13 support ALPN, and
there are plenty of implementations that can interoperate. Literally,
a higher number of products would have to do extra work to reduce the
privacy of their protocol and settings negotiation than the number of
products that would need to flip a single bit (or less) to have a
higher level of privacy protection for the protocol and settings
negotiation. (Note that it isn't even clear what settings negotiation
HTTP/2 may add to the protocol negotiation step, so we cannot even
debate how sensitive the information in that settings negotiation is
when trying to determine if leaking application data in the ALPN
extension is acceptable.)

Also note that the Mozilla line in the chart is a little misleading.
Patrick added ALPN support to a private copy of Firefox for the
purpose of the interop testing, which is I support. However, Firefox
doesn't actually support ALPN in our shipping product, only in
Patrick's special build. And, I would very much like to keep it that
way.

FWIW, I am working on an experiment for adding NPN support to
Thunderbird (an email client based on Gecko, like Firefox), so that
Thunderbird can speak SMTP, IMAP, POP, LDAP, and HTTP to a single
server on a single port, https://example.org:443/. One purpose of this
experiment is to demonstrate how we can get through networks that
block, or charge extra money for, email protocols while still allowing
HTTPS, without needing separate hostnames for each server. A second
purpose is to evaluate whether there are effective ways of making side
channel analysis for distinguishing the user's activity--sending email
vs retrieving email, for example--or even what product the user is
using--Thunderbird vs. Firefox--more difficult than we might first
suspect. I would appreciate it if the working group could give me some
more time to complete this experiment and/or help me with it, before
completely giving up on trying to protect the protocol negotiation
information in the handshake.

Also, if we can build a reliable 1-RTT handshake in TLS 1.3, then
there may be a design that allows us to remove protocol negotiation
from TLS completely, putting it back in the application layer. I will
be sharing a write-up of how this would work shortly. IMO, it is much
better to have the long-term solution for protocol and settings
negotiation be in the application layer, if it is reasonable to do so.
I am not one of those people that yell "layer violation" at
everything, but if we can avoid later violations in the long term,
then we should do so.

All that said, I am very grateful to the F5 team for sharing the
information to work around the interop issue that I originally
complained about in my ALPN Concerns email during IETF88. Xiaoyong set
a great example for us all and I hope that that kind of openness in
sharing information continues here on this list.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From nmav@redhat.com  Tue Nov 19 00:36:16 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA7A1A802B for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 00:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.427
X-Spam-Level: 
X-Spam-Status: No, score=-7.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fsziBOlm1h3 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 00:36:14 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 76AC71ACCDA for <tls@ietf.org>; Tue, 19 Nov 2013 00:36:14 -0800 (PST)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAJ8a7k9008919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 03:36:07 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAJ8a59q027460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Nov 2013 03:36:06 -0500
Message-ID: <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Zooko Wilcox-OHearn <zooko@leastauthority.com>
Date: Tue, 19 Nov 2013 09:36:05 +0100
In-Reply-To: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com>
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: tls@ietf.org
Subject: Re: [TLS] Salsa vs. ChaCha
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 08:36:16 -0000

On Mon, 2013-11-18 at 21:34 +0000, Zooko Wilcox-OHearn wrote:
> Folks:
> 
> draft-josefsson-salsa20-tls-03 makes it sound as though choosing
> ChaCha over Salsa would be trading off security (at least as reflected
> by Salsa being an eSTREAM finalist) for performance (at least in
> hardware). I don't think this reflects typical beliefs about the
> relative merits of these two ciphers.
> Instead, I think ChaCha is generally considered to be slightly
> stronger than Salsa, in addition to slightly faster (in both software
> and hardware).

Hello Zooko,
 This was not our intention (and if there is some text that needs to be
changed to prevent that, please let us know). Mainly what we want to say
there, is that we do not want to evaluate any new cipher (we are not
experts in cipher design). We select what is considered secure from the
existing cryptographic competitions in order to replace RC4. 

If we follow the path to chacha, which is not the outcome of a cipher
competition there can be arguments why not consider some other XXX
stream cipher as well which could be better than ChaCha in some aspect.
Such arguments would then be hard to confront.

> So, unfortunately there is no "provable security" reduction by which
> we can show that *any* attack on BLAKE must necessarily lead to an
> attack on ChaCha, or vice versa.
> 
> However, they are so closely related that in my opinion the copious
> cryptanalysis of BLAKE during the SHA-3 contest would probably have
> revealed weaknesses in ChaCha at the same time as it revealed any
> weaknesses in BLAKE.

You provide some good arguments in favor of chacha, although as you say
the results cannot be directly related to Chacha as a cipher. In any
case our decision for the cipher is not written in stone.

regards,
Nikos



From skyper@thc.org  Tue Nov 19 01:17:50 2013
Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120671AD694 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 01:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuQ5CtH87LTh for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 01:17:48 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E6D211A1F5F for <tls@ietf.org>; Tue, 19 Nov 2013 01:17:47 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id e14so3963198iej.12 for <tls@ietf.org>; Tue, 19 Nov 2013 01:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=diWytiYBV39TIrMJCAZW+XfnEEgVCQ2AsJVGAd2jBi0=; b=U4n8O9A9OYdlD1nBLI0wB/HJhbmVsqUgBJBNDyDjg6a9MmettThIxnVGHUzUylCEjq XvrVry6iIfwVdIE6N3JK+uETvAe0b/4xs/tGJKa3eAbDJplqOJ696VMkbg5fkOsHKSWh Nu9x1VVpg17KTeKfr3IQqmo+R8vATe9dIDquY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=diWytiYBV39TIrMJCAZW+XfnEEgVCQ2AsJVGAd2jBi0=; b=VNVdM99sjxT3F2YQmizlH9SAECD6X/kGeIAtTvrlsY9mg3b5ORAgvJJnFtGurT8uYf W7M6ufaWcdsjOJlm8/ax0EMlcEbtfRuZzqBYH4MequiVccvatlicrvdZR7NYuHYkJt8q 2CAMRpPijo7EvqF4gMDZJ9GV5F8B+f5y1dJ+Y6y5/Krza7/Vj3nGxo4SRFTAKXH0+zvD 24yE8uFD/UirzsuUFryNvIFSDC1COLocA6IhpGd8scdobI0Cr47cvfxD7B3PQbas/xjg +G/PrybPcd9sY4E0/Fp41kozGjo7vTNxsfMaAsGqYHPCqdjEnXkF2Az22J5o8S3gsSC5 H4Lg==
X-Gm-Message-State: ALoCoQlTGF1nobJNh3AI7yyLLptUZZ7emhlr4osIVstl5w6MiBugyeErI53yAtfE7o5jKCpFbuwD
MIME-Version: 1.0
X-Received: by 10.50.128.137 with SMTP id no9mr18301865igb.36.1384852661887; Tue, 19 Nov 2013 01:17:41 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 01:17:41 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE432@USMBX1.msg.corp.akamai.com>
Date: Tue, 19 Nov 2013 09:17:41 +0000
Message-ID: <CA+BZK2rv+KYWVhchUj_AnyNFBc_ryUZGY4Q9SovJ7Q--4fV54w@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: multipart/alternative; boundary=047d7b10cf0dfa7f4d04eb842217
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 09:17:50 -0000

--047d7b10cf0dfa7f4d04eb842217
Content-Type: text/plain; charset=ISO-8859-1

I agree with Watson (high level API is needed. Desperately).

Whenever I do a source code audit I almost always find an implementation
bug, something where the developer just did not know how to use openssl
correctly and kind of guessed or googled the solution (and google is so
often wrong...).

A high level API that takes care of always the best settings and takes care
of certificates, revocation and pinning would fix a significant number of
security problems out there and lower the bar for other application to
start using TLS.

This is the wrong mailinglist to discuss it but it should be mentioned on
the openssl/gnutls mailinglist.


regards,

ralf


On Mon, Nov 18, 2013 at 4:41 PM, Salz, Rich <rsalz@akamai.com> wrote:

> These seem contradictory to me:
>
> >> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have
> the same API.
> > The current APIs have caused lots of security bugs as people don't use
> them correctly. The solution: high level APIs that won't change ...
>
> The IETF has traditionally avoided API's and doesn't get involved in
> high-level language wars (other than ASN.1/DER vs ASCII art :)
>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b10cf0dfa7f4d04eb842217
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I agree with Watson (high level API is needed. Desper=
ately).<br><br>Whenever I do a source code audit I almost always find an im=
plementation bug, something where the developer just did not know how to us=
e openssl correctly and kind of guessed or googled the solution (and google=
 is so often wrong...).<br>
<br>A high level API that takes care of always the best settings and takes =
care of certificates, revocation and pinning would fix a significant number=
 of security problems out there and lower the bar for other application to =
start using TLS.<br>
<br>This is the wrong mailinglist to discuss it but it should be mentioned =
on the openssl/gnutls mailinglist.<br><br><br></div>regards,<br><br>ralf<br=
></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon=
, Nov 18, 2013 at 4:41 PM, Salz, Rich <span dir=3D"ltr">&lt;<a href=3D"mail=
to:rsalz@akamai.com" target=3D"_blank">rsalz@akamai.com</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">These seem contradictory to me:<br>
<div class=3D"im"><br>
&gt;&gt; TLS 1.2 solves the same problem as TLS 1.0. It should therefore ha=
ve the same API.<br>
</div>&gt; The current APIs have caused lots of security bugs as people don=
&#39;t use them correctly. The solution: high level APIs that won&#39;t cha=
nge ...<br>
<br>
The IETF has traditionally avoided API&#39;s and doesn&#39;t get involved i=
n high-level language wars (other than ASN.1/DER vs ASCII art :)<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=A0 =A0 =A0 =A0 /r$<br>
</font></span><div class=3D"im HOEnZb"><br>
--<br>
Principal Security Engineer<br>
Akamai Technology<br>
Cambridge, MA<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div>

--047d7b10cf0dfa7f4d04eb842217--

From SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de  Tue Nov 19 01:36:50 2013
Return-Path: <SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F2A1AD8D5 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 01:36:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.454
X-Spam-Level: 
X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3zN6atYWoM7 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 01:36:49 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3E1AD7C5 for <tls@ietf.org>; Tue, 19 Nov 2013 01:36:48 -0800 (PST)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MNzQd-1Vk4W21cV9-007QZG; Tue, 19 Nov 2013 10:36:41 +0100
Received: by mail-oa0-f41.google.com with SMTP id g12so8606126oah.14 for <tls@ietf.org>; Tue, 19 Nov 2013 01:36:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tpEdLXSzsC1yfIROgFH9z8YZPkNxVq6MpzysI3qfeHA=; b=IH9c6+YhKkRHZygvYJhYr4vddlf7HUP6cd97I8aEUtQWAKxHRyrZWOV7YEVqEZQJpC +AAFqkydP0su1qFW3aMkZzAGk4Y+JyfQ9Ky3zn3AI4qeJZaTp9q3MZ5erXIImcC1ShaR S5iwkHduRtiH53MESVfrgcZehYCX+AuDphwNVRha7UC0XHpN8VjBmcOCeGUH8SzRh8PX 5JKCvyduRUw1aXh7GqeRRU7s1ru8D/fm9ynxU9e+Xy7qAlEyrlVyx8cGuAXew7uBdc6r /UobIquHh/V6edbFMlqFIr0MVAVFPy9DdjdESeKNDL9JCMNLztwXIy8u4xnGeWM2cPJM IXfQ==
MIME-Version: 1.0
X-Received: by 10.182.129.42 with SMTP id nt10mr23962403obb.19.1384853800165;  Tue, 19 Nov 2013 01:36:40 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Tue, 19 Nov 2013 01:36:40 -0800 (PST)
In-Reply-To: <249d828ed6a743bfabe881e4dfa3d864@BY2PR03MB074.namprd03.prod.outlook.com>
References: <c8943847aecd44c29540bd198794746b@BY2PR03MB074.namprd03.prod.outlook.com> <CABqy+spWjsgAbc+s7BsEcwJ9hd=qZ2SVO55e9mnW1z1ECTjf=w@mail.gmail.com> <d7fafaf0af044123876e43f1f1ef603e@BY2PR03MB074.namprd03.prod.outlook.com> <CADMpkcKWNEw-LaMG7dXS50S0Gikxa5HnYp2m-O5o_fJKXSOk9Q@mail.gmail.com> <249d828ed6a743bfabe881e4dfa3d864@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Tue, 19 Nov 2013 10:36:40 +0100
Message-ID: <CADMpkcKP+wzaqbb8guUH-4qo6rLz_prR8mtLVsYpObgGmOjDEw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Marsh Ray <maray@microsoft.com>
Content-Type: multipart/alternative; boundary=e89a8fb1fbfed329fe04eb846607
X-Provags-ID: V02:K0:AewJte2KfsBvs1aFH+0+fG4XG7xL/F90tS08oAL02HW qUxtrRDeuSnBVhA1jirxjc8IUABDD+ZYIJrq9DeYJgFSZ6znly CfJBx7YUGciSsUwYx0qoK3+OVi68f389/IjvKfUOeFcIFfmP1u sZrM2NH+EJilTKIWVGMOlr92lEZaNpnkv9sZsI9XVB8ZCMi9qJ 60FpjBNelIv8V9tAogtvRHG2mSKlB2s0raykE3UNCL2bWLHm3w DVbmCHp0VJGCoZb0vbkcY+oJEaPaCEz+dPYMFnlS0vOejE/9vQ uW5zq0dhLl2tKFVLSzzJomgssP0wSYJ+n6E8p8FHIfTBEQwQ81 x4NIW/30XwoVoY+JjVa9vZ1ShWfSHVM9gE08Hk9NwpKTMZnwmP kICuUZz/KMVlBLJZ+yOlthXW6l6b0h/hHSMOrbfT6nYZPZSm3Z m3CqC
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-HMAC is the only credible choice. Here's why:
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 09:37:49 -0000

--e89a8fb1fbfed329fe04eb846607
Content-Type: text/plain; charset=ISO-8859-1

Marsh, as I said, you *are* right [*], it's just that there's a lot more to
it than Bellare/Namprempre (which doesn't consider side-channel attacks,
for example).


[*] Another gross over-simplification :-)

--e89a8fb1fbfed329fe04eb846607
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><div>Marsh, as I said, you *are* right [*], it&#39;s just that there&#39;s a lot more to it than Bellare/Namprempre (which doesn&#39;t consider side-channel attacks, for example).</div><div><br></div><div><br>
</div><div>[*] Another gross over-simplification :-)</div><div><br></div></div>

--e89a8fb1fbfed329fe04eb846607--

From benl@google.com  Tue Nov 19 01:38:19 2013
Return-Path: <benl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498051AD8EA for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 01:38:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AfahS-uaWjm for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 01:38:18 -0800 (PST)
Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id CF5B21AD8D5 for <tls@ietf.org>; Tue, 19 Nov 2013 01:38:17 -0800 (PST)
Received: by mail-vb0-f48.google.com with SMTP id x16so1246149vbf.21 for <tls@ietf.org>; Tue, 19 Nov 2013 01:38:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g2/wkznMTOxCIYZMyVrBuc5lq45vMHgBv7daSE7VMuU=; b=ginTF2skV+8iktxmPSRvGIS3CE9pRlCzW7eQco6DcZC6bOJagfeowHLQSOcnCa1Wl3 bxdDc/ddVOt0dGFZjwuuEWl45I4pR7WcOMhK+okbpNFUbHgsrSqduyvCEOZ3TfzGn04+ LNvjA6SbSwTqd/LEbdfeK/QMjYNZ6TFiuXfyCSWMdcq7EKTlkpZTQnK9cRvYNzHpvNbx /oF5ua2F2yS9B5+3ivuRQ1/BZvIbSIM72kIZZP2s0kkd6ToxbXflNcIDHUtA2/iZV8xs uZQi97xcBk9TgNbOZbRKEGb1TxIrxmr1Thp8IO7YT4LiTV8brFF3GiEzuAx9bdHGbXSd 5s8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g2/wkznMTOxCIYZMyVrBuc5lq45vMHgBv7daSE7VMuU=; b=L90ZyhXSMahbED5ZK1tnmY8s4DFG6BsNfrxQ5jD+mN9Bal6tdsKVphHGr/acpucgQX ahd0a/8FD3KBVRjIZDgNsgPCtVfSrsZjmU6KpMamtKrFjnIrAnPfC1m9X384EVOx51yt ludUNSDPUnbl0cM46Vl+f61iHxyStnZ4j7ZfIlGaHgg63VEdp4d91LyouKnTGGDPSPx5 FiWdmR0HmVHJwZ8GU4NV5vCekU2DSKUDHnHRG12BDJLGS71YeCjr4R8g9rbvsq7CNw3N BzU1EAN7bQGkIU5PEZAdyfijhOnEPw29Rc6XZNzfHKx5S1zSKyeubPp++iwHoJpKZtbh N6Bg==
X-Gm-Message-State: ALoCoQmZmhc/AzNG9p7lgT0hdgeHMVOz1ZfvrxfkJ/Z5mFKNioQdqYUxB8X90tfLXji96kpptjTAIgRmh2yTXFf0Hia7i88n7bRdNBbLfQl5uKnWOgrigfiPopCMphQkf3AFCyxnS3AQlhMeUyrcMYOOtkny4zc+ypsPNWqi6weTemmFQRfSxQlEBdlsrp3UvUvPGz2Kr5Mh
MIME-Version: 1.0
X-Received: by 10.52.245.9 with SMTP id xk9mr4373740vdc.8.1384853891652; Tue, 19 Nov 2013 01:38:11 -0800 (PST)
Received: by 10.52.183.65 with HTTP; Tue, 19 Nov 2013 01:38:11 -0800 (PST)
In-Reply-To: <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <CACsn0cnRUDZp=_iOy+J4Ur1PFtkJgfFcHzhVFviSYUG9mh_t4w@mail.gmail.com>
Date: Tue, 19 Nov 2013 09:38:11 +0000
Message-ID: <CABrd9SQsrG2xCWQrtcLzAyvhBZ_Fz=S8bG8QxfiNuCBk1W7j0w@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 09:38:19 -0000

On 18 November 2013 16:34, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Mon, Nov 18, 2013 at 7:02 AM, Salz, Rich <rsalz@akamai.com> wrote:
>>> TLS 1.2 solves the same problem as TLS 1.0. It should therefore have the same API.
>>
>> Do you really believe this or are you trying to just be provocative?
> Do you really believe that backwards compatibility at the source level
> had to be sacrificed?
> Stable interfaces are the norm, unstable ones are remarkable. How many
> prongs does a ground-fault detecting electricity socket have?
> BLAS has multiple implementations, all with the same API. MPI looks
> the same on a bunch of Xboxes wired together with Ethernet as it does
> on a several million dollar supercomputer. GMP doesn't gratuitously
> change its interface with every performance enhancement, and to this
> day "Hello World" works unchanged on my machine, some 40 years after
> it first ran on a PDP-11. Everything about the environment it runs on
> is different, from the word size, to the endianness, to the output
> mechanism, to the interface I am using. And yet it works with only a
> recompile.
>
> TCP has undergone many changes to the implementation, yet the BSD
> sockets API still works. Why exactly does an application need to care
> about which ciphersuite is used? Why does it need to do more than hand
> over some trusted PKI roots, and a server certificate?
>
> The current APIs have caused lots of security bugs as people don't use
> them correctly. The solution: high level APIs that won't change when
> the implementation is upgraded. Is this really too lofty a goal? The
> costs of the current approach are obvious: what are the costs of
> making better APIs?

I won't defend OpenSSL's APIs, because I agree they're pretty sucky,
but I do want to observe that the TLS API did not change between TLS
1.0 and 1.2, so I'm not really sure what you're talking about here.

From skyper@thc.org  Tue Nov 19 02:15:42 2013
Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381A01ADBD0 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 02:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiNQTuXDaKe9 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 02:15:40 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3C96D1ADBCE for <tls@ietf.org>; Tue, 19 Nov 2013 02:15:40 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id ar20so4343795iec.2 for <tls@ietf.org>; Tue, 19 Nov 2013 02:15:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z63hDuZOe8J4w7H5GzF7Ii5QX3ikaDC3inspbj05jrs=; b=Wc4Q46s0DS/Uh8MgiAiM1gVF3sPFvls/n9DqnCLJfTI0ua9BBUpQK3XkoFcEatGz3W kao6/XchRPbsAG6Je32xw3VBDLpb7Z//dus0sQw+ooI4/eZ2NoMQG4HINs6bOA4+ZcJJ iPJI3A33CnjACyl4zc2tMI6LybbSrUOlI+h1Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z63hDuZOe8J4w7H5GzF7Ii5QX3ikaDC3inspbj05jrs=; b=mYcurrnGGve9EPxtbv9m/qb4wOY0GKUbEru1oGNnUz0b2uohpEi5Q6BBTiu2b1dxaF CxV75YOUyvkHTWOSq7NFp/2buWyYbsoXNR+dyA5TwzJx9B1vjDqPDV0l9mYvvePX67Hm o7Nlgx+qoFi4uz2KCRk0M5glnpdPStqLWn0EMf3Halhl/DxNDgGUuoJnPLh4VIyWvvOS T0eYnqnw5/mfwxQICWJNP8GJLMG69UJmJPS57LNOAe/yVcm86Y/UmhKUesmyzdDovUBm Cm+8XJIb0OLNrAQ0NUl4eg9560N0PyAKZkLsNYnBqX3mL603xDirtf1qZbBUrR3uQ7YB tWpw==
X-Gm-Message-State: ALoCoQl3a8XI5N2DEO1wG/PbvSja3u253OLA6Yx55uKgLauL2KnfXGIOjE6yebsNavKvs+woDi84
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr18182522igb.46.1384856134151; Tue, 19 Nov 2013 02:15:34 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 02:15:34 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net>
Date: Tue, 19 Nov 2013 10:15:34 +0000
Message-ID: <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary=047d7b2e0d1ff10fb104eb84f1ec
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 10:15:42 -0000

--047d7b2e0d1ff10fb104eb84f1ec
Content-Type: text/plain; charset=ISO-8859-1

Hi Dan,

The security risk lies within the implementation.

The capable client will always offer TLS-PWD.

Simplified, this is how pinning will be implemented: The client receives
the server's certificate. The client checks if the server's certificate (or
better the SPKI) is already known to the client (e.g. pinned) and if the
server's certificate is different to the pinned certificate then the
connection fails.

The draft assumes that certificate based server authentication is the only
authentication that exists.

The draft does not discuss the scenario where TLS-PWD is used.

In such a case I'm concerned that the part of the client source code that
checks for pinning is not triggered and by-passed. The client goes into the
TLS-PWD mode.

Instead what should be pinned is the SPKI _and_ that certificate based
server-authentication must be used. E.g. once a client has pinned a
certificate for a host it should not allow TLS-PWD.

This is obvious to us but not obvious to the developer and should be
explicitly mentioned.

(It could be mentioned in websec-rfc as you say but that's beyond draft
status and additions are no longer practical). Mentioning it in the TLS-PWD
draft will hopefully prevent an insecure implementation.

regards,

Ralf




On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <dharkins@lounge.org> wrote:

>
>   Hi Ralf,
>
> On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
> > Hi,
> >
> > could not find it in the draft:
> >
> > the interoperability with draft-ietf-websec-key-pinning-08 should be
> > mentioned explicitly to prevent
> > an attack scenario. (e.g. user has pinned certificate for google.com.
> > Attacker MITM forces
> > client to do tls-pwd. Client should not allow this). E.g. once a host is
> > pinned no other server-side
> > auth mechanism should be allowed.
>
>   If the client doesn't want to do TLS-pwd then it won't include the
> mandatory extension in its client hello and it won't include any TLS-pwd
> ciphersuites. I don't see how this attack happens.
>
>   Perhaps the necessary requirements to deal with pinning certificates
> for websec should be dealt with in the draft you mention.
>
>   regards,
>
>   Dan.
>
>
>
>

--047d7b2e0d1ff10fb104eb84f1ec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi Dan,<br><br></div>The security risk lies=
 within the implementation.<br><br>The capable client will always offer TLS=
-PWD. <br><br>Simplified, this is how pinning will be implemented: The clie=
nt receives the server&#39;s certificate. The client checks if the server&#=
39;s certificate (or better the SPKI) is already known to the client (e.g. =
pinned) and if the server&#39;s certificate is different to the pinned cert=
ificate then the connection fails.<br>
<br></div><div>The draft assumes that certificate based server authenticati=
on is the only authentication that exists.<br><br></div>The draft does not =
discuss the scenario where TLS-PWD is used.<br><br></div><div>In such a cas=
e I&#39;m concerned that the part of the client source code that checks for=
 pinning is not triggered and by-passed. The client goes into the TLS-PWD m=
ode.<br>
<br>Instead what should be pinned is the SPKI _and_ that certificate based =
server-authentication must be used. E.g. once a client has pinned a certifi=
cate for a host it should not allow TLS-PWD.<br><br></div><div>This is obvi=
ous to us but not obvious to the developer and should be explicitly mention=
ed.<br>
<br></div><div>(It could be mentioned in websec-rfc as you say but that&#39=
;s beyond draft status and additions are no longer practical). Mentioning i=
t in the TLS-PWD draft will hopefully prevent an insecure implementation.<b=
r>
</div><div><br></div><div>regards,<br><br>Ralf<br><br></div><br></div><div =
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Nov 18, 20=
13 at 9:51 PM, Dan Harkins <span dir=3D"ltr">&lt;<a href=3D"mailto:dharkins=
@lounge.org" target=3D"_blank">dharkins@lounge.org</a>&gt;</span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
=A0 Hi Ralf,<br>
<div class=3D"im"><br>
On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; could not find it in the draft:<br>
&gt;<br>
&gt; the interoperability with draft-ietf-websec-key-pinning-08 should be<b=
r>
&gt; mentioned explicitly to prevent<br>
&gt; an attack scenario. (e.g. user has pinned certificate for <a href=3D"h=
ttp://google.com" target=3D"_blank">google.com</a>.<br>
&gt; Attacker MITM forces<br>
&gt; client to do tls-pwd. Client should not allow this). E.g. once a host =
is<br>
&gt; pinned no other server-side<br>
&gt; auth mechanism should be allowed.<br>
<br>
</div>=A0 If the client doesn&#39;t want to do TLS-pwd then it won&#39;t in=
clude the<br>
mandatory extension in its client hello and it won&#39;t include any TLS-pw=
d<br>
ciphersuites. I don&#39;t see how this attack happens.<br>
<br>
=A0 Perhaps the necessary requirements to deal with pinning certificates<br=
>
for websec should be dealt with in the draft you mention.<br>
<br>
=A0 regards,<br>
<br>
=A0 Dan.<br>
<br>
<br>
<br>
</blockquote></div><br></div>

--047d7b2e0d1ff10fb104eb84f1ec--

From oscar.koeroo@kpn.com  Tue Nov 19 03:26:40 2013
Return-Path: <oscar.koeroo@kpn.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7DD1ADF10 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnt5-MB8SAfg for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:26:37 -0800 (PST)
Received: from Mail3.kpnnet.org (mail3.kpnnet.org [192.58.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5534A1ADF24 for <tls@ietf.org>; Tue, 19 Nov 2013 03:26:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,729,1378850400"; d="scan'208";a="73843850"
Received: from w2006.kpnnl.local ([10.75.81.4]) by Mail3.kpnnet.org with ESMTP; 19 Nov 2013 12:25:25 +0100
Received: from W2053.kpnnl.local ([10.75.81.1]) by W2006.kpnnl.local ([10.75.81.4]) with mapi; Tue, 19 Nov 2013 12:15:14 +0100
From: <oscar.koeroo@kpn.com>
To: <skyper@thc.org>, <dharkins@lounge.org>
Date: Tue, 19 Nov 2013 12:15:13 +0100
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-pwd
Thread-Index: Ac7lEwK2Wn3s649oRYiwCgfqLr7CiAABJtcA
Message-ID: <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net> <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
In-Reply-To: <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
Accept-Language: en-US, nl-NL
Content-Language: nl-NL
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, nl-NL
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 11:26:40 -0000

May I add that it's not clear which elements are to be presented to the use=
r for visual (or automated) inspection and in which form. I can handle long=
 random string for visual inspection, but I wonder if this is to be expecte=
d from all users. If I've understood the spec correctly the fingerprint of =
the public key and the domain names, i.e. the subject alt names, are to be =
presented to the user. This could turn out to be quite a bit of data per ce=
rtificate.

Also, if the fingerprint is tied to public key exclusively I wonder what th=
e UAs are expected to do when subject alt names have changed in the certifi=
cates when the public key is preserved.


Oscar Koeroo
Red Team / Ethical Hacker
Chief Information Security Office
KPN
Tel: +31 6 1217 5278
Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654


Van: TLS [mailto:tls-bounces@ietf.org] Namens Ralf Skyper Kaiser
Verzonden: dinsdag 19 november 2013 11:16
Aan: Dan Harkins
CC: tls@ietf.org
Onderwerp: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

Hi Dan,
The security risk lies within the implementation.

The capable client will always offer TLS-PWD.=20

Simplified, this is how pinning will be implemented: The client receives th=
e server's certificate. The client checks if the server's certificate (or b=
etter the SPKI) is already known to the client (e.g. pinned) and if the ser=
ver's certificate is different to the pinned certificate then the connectio=
n fails.
The draft assumes that certificate based server authentication is the only =
authentication that exists.
The draft does not discuss the scenario where TLS-PWD is used.
In such a case I'm concerned that the part of the client source code that c=
hecks for pinning is not triggered and by-passed. The client goes into the =
TLS-PWD mode.

Instead what should be pinned is the SPKI _and_ that certificate based serv=
er-authentication must be used. E.g. once a client has pinned a certificate=
 for a host it should not allow TLS-PWD.
This is obvious to us but not obvious to the developer and should be explic=
itly mentioned.
(It could be mentioned in websec-rfc as you say but that's beyond draft sta=
tus and additions are no longer practical). Mentioning it in the TLS-PWD dr=
aft will hopefully prevent an insecure implementation.

regards,

Ralf


On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <dharkins@lounge.org> wrote:

=A0 Hi Ralf,

On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
> Hi,
>
> could not find it in the draft:
>
> the interoperability with draft-ietf-websec-key-pinning-08 should be
> mentioned explicitly to prevent
> an attack scenario. (e.g. user has pinned certificate for google.com.
> Attacker MITM forces
> client to do tls-pwd. Client should not allow this). E.g. once a host is
> pinned no other server-side
> auth mechanism should be allowed.
=A0 If the client doesn't want to do TLS-pwd then it won't include the
mandatory extension in its client hello and it won't include any TLS-pwd
ciphersuites. I don't see how this attack happens.

=A0 Perhaps the necessary requirements to deal with pinning certificates
for websec should be dealt with in the draft you mention.

=A0 regards,

=A0 Dan.




From SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de  Tue Nov 19 03:38:39 2013
Return-Path: <SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751691ADEA3 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.454
X-Spam-Level: 
X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmQGf6gCpz7e for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:38:38 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1A65D1AD8D8 for <tls@ietf.org>; Tue, 19 Nov 2013 03:38:38 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LaUDn-1VGZTt3ARL-00lotF; Tue, 19 Nov 2013 12:38:31 +0100
Received: by mail-oa0-f45.google.com with SMTP id o6so2252016oag.32 for <tls@ietf.org>; Tue, 19 Nov 2013 03:38:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4jr6GZmhEs68WRhJWGyphnj6+KfCEKr4NU0zBgnke/Q=; b=FTRmL2dRU7y1c2nAZ0FLutiLLXjiozBoZ5rpfvTNtkxldjasVJILS99GkaqmfwaetT PrPqMDZxaXWMDs4epDxl20rUa3x8XiF8Pu4rk/dkZWqTIUI2Dmq0Z9nG3vf1zmI2OXj1 I65tzJhgniD9s97v7lhRrEILc8LBNksby8TxrwGvqiI6J+P/lM5WpIyr8+6WZN3nqG0r P3VFFM0zm1sSyhWyY3K8Koy0bQlbqworO1q+T4VTYJ5d8v6DO+STbP7rNhkvj+qyMVlB RPJEAsf3GCfnrttOjWRnrYCXigHkD5Ae53GZNC/sO6bYWQfX8iWBqSlaB/XMYqa/4eMY TP8g==
MIME-Version: 1.0
X-Received: by 10.182.247.68 with SMTP id yc4mr329131obc.67.1384861109506; Tue, 19 Nov 2013 03:38:29 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Tue, 19 Nov 2013 03:38:29 -0800 (PST)
In-Reply-To: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au>
Date: Tue, 19 Nov 2013 12:38:29 +0100
Message-ID: <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e015384d67f26af04eb861a28
X-Provags-ID: V02:K0:XvEi0m2EQ1hI6o1WhCEfNmotIjm7qyq0n9v91HuRUQg Ee6ExVEBtKeLzSSWyOxu3eRizkfijSWAiDzRQdEY/bTYRk9ShP aJdmtOcAt7o5FwznNA+g8LkXAaAL3+jKephi1P+cHdzctrX7vg aV7HFfhRYdjg2u6cvCjXKqcNFVXFl9bPCBiAf5AqwnoCQqxmqw OJV3cfy4qVjQ4Mvek104xVkhGYZOeDfEMLwFjkV2y+a6Xqwtpw 33kj2GMPR2e6GyEY0d9PM/MXTfaQu6sp8JyD6Pe700x307oR30 aHo5LjcOkwux3eBtqNb1riZIiVZSLqPTGYRgido3f5JYeRHk4r 5oTlxdCX/Zb/rknyzCYQAAI0PLGgvGYZP+Np9sq7Lje/fOTu2U bJbw5FFxtPa4fHA2YnEqEVMP6Z2pG7BD77mKkK7lOcEKlX0mnE 3dQdb
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 11:38:39 -0000

--089e015384d67f26af04eb861a28
Content-Type: text/plain; charset=ISO-8859-1

2013/11/8 Douglas Stebila <stebila@qut.edu.au>

> I believe that where possible the IETF should aim to standardize
> cryptographic protocols that have provable security results.  Such proofs
> of course don't guarantee the protocol is secure in all scenarios, but at
> least rule out some classes of attacks.  In the field of password
> authenticated key exchange, there are many provably secure protocols, and
> so it would be preferable to see one such protocol adopted.
>

Right.  So there's already an RFC for using SRP in TLS, but it's
Informational.  Many other such protocols can be found in the research
literature (and, sometimes, in Internet-Drafts).  If we're picking a
password-based key exchange for Standards Track, why this one?  What are
the advantages of this specific protocol over the others?

>From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack of
formal security arguments appears to be that it's presumably less efficient
than some other such protocols ("hunt-and-peck" loop).

Bodo

--089e015384d67f26af04eb861a28
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2013/11/8 Douglas Stebila <span dir=3D"ltr">&lt;<a href=3D=
"mailto:stebila@qut.edu.au" target=3D"_blank">stebila@qut.edu.au</a>&gt;</s=
pan><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex">
I believe that where possible the IETF should aim to standardize cryptograp=
hic protocols that have provable security results. =A0Such proofs of course=
 don&#39;t guarantee the protocol is secure in all scenarios, but at least =
rule out some classes of attacks. =A0In the field of password authenticated=
 key exchange, there are many provably secure protocols, and so it would be=
 preferable to see one such protocol adopted.<br>
</blockquote><div><br></div><div>Right. =A0So there&#39;s already an RFC fo=
r using SRP in TLS, but it&#39;s Informational. =A0Many other such protocol=
s can be found in the research literature (and, sometimes, in Internet-Draf=
ts). =A0If we&#39;re picking a password-based key exchange for Standards Tr=
ack, why this one? =A0What are the advantages of this specific protocol ove=
r the others?</div>
<div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px">From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack =
of formal security arguments appears to be that it&#39;s presumably less ef=
ficient than some other such protocols (&quot;hunt-and-peck&quot; loop).</s=
pan></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Bod=
o</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13=
px"><br>
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x"><br></span></div></div></div></div>

--089e015384d67f26af04eb861a28--

From skyper@thc.org  Tue Nov 19 03:46:15 2013
Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F210A1ADAEA for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kexha3JX_iSC for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:46:13 -0800 (PST)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 493F51AD8EA for <tls@ietf.org>; Tue, 19 Nov 2013 03:46:13 -0800 (PST)
Received: by mail-ie0-f170.google.com with SMTP id qd12so1625842ieb.29 for <tls@ietf.org>; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TrhNZmw2LceXbIrCDUe/NCOgVKKOo79C5+8UniFDWXs=; b=dhzO+f97iCjozgv/kNZ44tecIo9cp6Z5LahvGYtlJSJ1w2CWagAle2cRMqi5gE3Hi6 Sz3NOGPqtAGm/sQHW1N2XAsCEROXhVlvXiQ5bj3QaTcber0b8inFWUMw0P1Q+ruPa/Q9 /4x3/9EE281md7ZrAjNVIGTvret+STyyX9o2E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TrhNZmw2LceXbIrCDUe/NCOgVKKOo79C5+8UniFDWXs=; b=ibOTepxORAUbRZj5TyurzgpKTNnc+EBqDRQZNpikzdvCbzZSRdgiP4+ztxQZjN+F2R i7MkhDU62xYTZBzQtB1mrKoF3jA9ukLcMvmiCZEk4EZ24PWaWuFoWt9xaMMCu51bUTgS Tpdu4OVvSv8fj4xObEyiH2Mg3yuzNPLm9EzySiyczU+rXSOryXYaLfAb5ehhwmYODviM rxvbUBJVrjgzVB92IfyBuSfAqyousfjIBDWb19eCLqsYT6CVW6APXUWeJ+ZFPq0zKP03 gC7q82qhRpWH6vIKtToYX5n1Jo99rLBNgaVSluLi0EqQtdEKtpQJJEytZaGyxmw6fdGm mVWw==
X-Gm-Message-State: ALoCoQmH+fhmjsjhIFr/lbzBs4EcAs7SqhEoG2ltqakHSJngV+60Js3y9fWEV+WQm69AMWb3EBo6
MIME-Version: 1.0
X-Received: by 10.42.224.10 with SMTP id im10mr334874icb.46.1384861567283; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Tue, 19 Nov 2013 03:46:07 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <20131112214115.9095A1AA81@ld9781.wdf.sap.corp>
References: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com> <20131112214115.9095A1AA81@ld9781.wdf.sap.corp>
Date: Tue, 19 Nov 2013 11:46:07 +0000
Message-ID: <CA+BZK2pT8wJyLLV1K4B4tq_Ay_06dYLXyu-AM=gtWd2Ax=77qA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: multipart/alternative; boundary=001a11332dbcc8063d04eb8635d6
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 11:46:15 -0000

--001a11332dbcc8063d04eb8635d6
Content-Type: text/plain; charset=ISO-8859-1

Hi Martin,



On Tue, Nov 12, 2013 at 9:41 PM, Martin Rex <mrex@sap.com> wrote:

> Ralf Skyper Kaiser wrote:>
> > 2. The attack that you describe requires active packet injection.  We
> just
> > increased the cost for the attacker from passive recording of data to
> > active packet injection. Active packet injection does not scale and is
> > detectable. The proposed solution solves pervasive surveillance. That's
> the
> > goal.
>
> You're misrepresenting the issue.  For a passive observer, i.e. someone
> watching the media where the connection data travels, inserting a
> fake IP datagram with TCP RST in it is **TRIVIAL**, i.e. the cost is
> infinitesimal close to zero.  A man-in-the-middle requirement would
> be real cost, but we do not have that here.
>

It is technically trivial to insert a TCP RST. It is a whole different
matter in real life. For example does
the US operate under a certain policy that allows for passive monitoring
but would only allow
for active packet injection (TCP RST) under special circumstances.

The claim stands: With encrypted SNI we just raised that bar for pervasive
surveillance. Not just the technically
(doing millions of TCP RST's on every TLS 1.3 connection - undetected - is
not as easy in the real world as you say it
is - especially the undetected part) but also policy wise do we raise the
bar.



> >
> > I hear you loud and clear that you wish for a protocol where the SNI is
> > transmitted encrypted _and_ without the attacker
> > being able to reveal the SNI during an active attack. I'm certain that a
> > proposal by you of how to do this would be highly appreciated and
> > educational to the readers.
>
> I never said that.
>
> What you seem to be looking for is a protocol where an observer does not
> know which parties are talking.  That will either require fully dynamic
> addresses for both communication peers, pre-shared keys and out-of-band
> protected&secure discovery where to find the dynamic address of the
> communication acceptor.  Or require the use of a bunch of third parties
> like a TOR network, which will hide who is talking to whom.
>

No. Not at all. What I'm looking for is encrypted SNI and the browser to
stop advertising
in advance which server I'm connecting to. (On a side note there is a lot
of work
progressing in the DNS community for making DNS confidential. Now is the
time to
fix the last leg that leaks the domain name: SNI).


>
> This is not something you can solve with a few tweaks of the TLS protocol.
> And may get the consumers of TLS in big trouble if you continue boasting
> that you could achieve this, because some might fall for this myth.
>

It fact it can be solved with a tweak in TLS 1.3. See Eric's IETF88
presentation.

regards,

ralf

>
>
> -Martin
>

--001a11332dbcc8063d04eb8635d6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Martin,<br><br></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Tue, Nov 12, 2013 at 9:41 PM, Martin Re=
x <span dir=3D"ltr">&lt;<a href=3D"mailto:mrex@sap.com" target=3D"_blank">m=
rex@sap.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">Ralf Skyper Kaiser wrote:&=
gt;<br>
&gt; 2. The attack that you describe requires active packet injection. =A0W=
e just<br>
&gt; increased the cost for the attacker from passive recording of data to<=
br>
&gt; active packet injection. Active packet injection does not scale and is=
<br>
&gt; detectable. The proposed solution solves pervasive surveillance. That&=
#39;s the<br>
&gt; goal.<br>
<br>
</div>You&#39;re misrepresenting the issue. =A0For a passive observer, i.e.=
 someone<br>
watching the media where the connection data travels, inserting a<br>
fake IP datagram with TCP RST in it is **TRIVIAL**, i.e. the cost is<br>
infinitesimal close to zero. =A0A man-in-the-middle requirement would<br>
be real cost, but we do not have that here.<br></blockquote><div><br></div>=
<div>It is technically trivial to insert a TCP RST. It is a whole different=
 matter in real life. For example does<br>the US operate under a certain po=
licy that allows for passive monitoring but would only allow<br>
for active packet injection (TCP RST) under special circumstances. <br><br>=
</div><div>The claim stands: With encrypted SNI we just raised that bar for=
 pervasive surveillance. Not just the technically<br>(doing millions of TCP=
 RST&#39;s on every TLS 1.3 connection - undetected - is not as easy in the=
 real world as you say it<br>
is - especially the undetected part) but also policy wise do we raise the b=
ar.<br><br></div><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">
<br>
&gt;<br>
&gt; I hear you loud and clear that you wish for a protocol where the SNI i=
s<br>
&gt; transmitted encrypted _and_ without the attacker<br>
&gt; being able to reveal the SNI during an active attack. I&#39;m certain =
that a<br>
&gt; proposal by you of how to do this would be highly appreciated and<br>
&gt; educational to the readers.<br>
<br>
</div>I never said that.<br>
<br>
What you seem to be looking for is a protocol where an observer does not<br=
>
know which parties are talking. =A0That will either require fully dynamic<b=
r>
addresses for both communication peers, pre-shared keys and out-of-band<br>
protected&amp;secure discovery where to find the dynamic address of the<br>
communication acceptor. =A0Or require the use of a bunch of third parties<b=
r>
like a TOR network, which will hide who is talking to whom.<br></blockquote=
><div><br></div><div>No. Not at all. What I&#39;m looking for is encrypted =
SNI and the browser to stop advertising<br>in advance which server I&#39;m =
connecting to. (On a side note there is a lot of work<br>
progressing in the DNS community for making DNS confidential. Now is the ti=
me to<br>fix the last leg that leaks the domain name: SNI).<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<br>
<br>
This is not something you can solve with a few tweaks of the TLS protocol.<=
br>
And may get the consumers of TLS in big trouble if you continue boasting<br=
>
that you could achieve this, because some might fall for this myth.<br></bl=
ockquote><div><br></div><div>It fact it can be solved with a tweak in TLS 1=
.3. See Eric&#39;s IETF88 presentation.<br><br></div><div>regards,<br>
<br>ralf <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-Martin<br>
</font></span></blockquote></div><br></div></div>

--001a11332dbcc8063d04eb8635d6--

From SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de  Tue Nov 19 04:21:16 2013
Return-Path: <SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148171ADF59 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 04:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.454
X-Spam-Level: 
X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swWjzfyfkVsU for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 04:21:14 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 84AD91ADF4E for <tls@ietf.org>; Tue, 19 Nov 2013 04:21:14 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lp8j6-1VFAAx0ejE-00fQ3F; Tue, 19 Nov 2013 13:21:07 +0100
Received: by mail-ob0-f181.google.com with SMTP id uy5so446326obc.12 for <tls@ietf.org>; Tue, 19 Nov 2013 04:21:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RLUhJZIzFB3ZyDDQe6JhgAxCnGJweYPrd0gxAMSL9OY=; b=LC1rAKoz/dyUrhLx/nLAaHowCwYEHQ6IuNS7iubW9gsgwcU6UtGZCLkZXN+8Xb7OvP yBCi4KtBeHLpPiFKNzTga9HODvxtnRMrDTkZVIEC4fhAHqjhJA66krh0QP3y2B54WEeH UDjGG8O/n+dO/ilUIoc3hdpz+rjH7UXR1AIzffdar83YcXITyf5r9yooxJjssLtYRK3t RwgKEC9jrLgo7OPuKJRYD75iQ6OTwBu04CDshfw5aPvqKaZyHU4QdzouKDE+6nvUEcqw 0IgEGIH9XNyrL8Vw9mD4NKFIbiJAw5Xoy9g5sfqASdhPVa1S1aNpRVSSaTs4xepqDhHC Tpcg==
MIME-Version: 1.0
X-Received: by 10.182.18.102 with SMTP id v6mr134746obd.71.1384863665859; Tue, 19 Nov 2013 04:21:05 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Tue, 19 Nov 2013 04:21:05 -0800 (PST)
In-Reply-To: <CACsn0cmoiQph7mSfTxsKs+O-9iRYAVeHcp73tCuVuCyofi5oMg@mail.gmail.com>
References: <CA+BZK2q_f_JrdkdJRC1MirPH2yzRL2Y_28fi4e2MGdc5Uxnksg@mail.gmail.com> <20131107200815.F24AB1AA69@ld9781.wdf.sap.corp> <CA+BZK2o411meJDkLwnwOudrkr-G_eWeFx0tirLhUCoSnKsddEg@mail.gmail.com> <CACsn0cmoiQph7mSfTxsKs+O-9iRYAVeHcp73tCuVuCyofi5oMg@mail.gmail.com>
Date: Tue, 19 Nov 2013 13:21:05 +0100
Message-ID: <CADMpkcKmpLa3TrF4f_=VachFUU5KZDt1haoRggBjheZo0+sBow@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c339e6ddb45604eb86b2b1
X-Provags-ID: V02:K0:YwTyZu6/cSHK7J5aGvMFU93/6ac+El2es1kIGXHBugL naWDMmARkjwC52qTBA5UjIUXqdtn2yCykYmam768vazCrTSNFI W2cvLj2x9KkwQtdcnL273taSM+fUBawe3XiqVGPtB2kL49ewdA 5J0hjcOeHxXAF619Vh447b+5OGNYxY742y/LND/nnt4cOdDVKm RFFu8kaLl624C1P518I6y8rHo5knRq2Eaza8D+fRNwjZo1Yzsb VZHJ1QXKtQtI0tGmhK2YUe6G9PZzSWzeBq12q2gOzYgOQ7al+L PR6U6YSbz65XVnYY/vujiG7XJvTAXvuoSk4kPMt14s1jZ2/CDT erwtnu3NALHBoOhYV/FvtOxAsg/TgzAUj+kOTNtCyk+wMbHzRW PhvMOguWnqQXdU9opDYWmBSLmyDL+mjoNKV/JqtJd7pQOECIKi j+3KA
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 12:21:16 -0000

--001a11c339e6ddb45604eb86b2b1
Content-Type: text/plain; charset=ISO-8859-1

2013/11/8 Watson Ladd <watsonbladd@gmail.com>

 > The downgrade attack to TLS 1.2 is possible and would trigger the SNI to
> be
> > send in clear again.
> > (It requires an active attack).
> Why wasn't this fixed years ago?


This is not an easy question to answer.  (Yes, it certainly *should* have
been fixed years ago.)


> The client should indicate the
> highest offered version when falling back, and the server should
> signal if there is a problem. This was an issue with SSL 3.0 and TLS
> 1.0. It's still an issue today because SSL 3.0 is still out there.


See https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00 for a
proposal intended to be particularly simple.

(This is not the first proposal in this spirit; see, e.g.,
http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt.
 A recurring complaint is that TLS instead should promote interoperability,
which I think is not a valid complaint: While interoperability should be
better than it is, (1) this doesn't extend to interoperability with
attackers, and (2) it's a false dichotomy --
deploying draft-bmoeller-tls-downgrade-scsv-00 would deal with security
problems that arise as implementations work around interoperability
problems, but that I-D won't get in your way in any way, shape or form if
you do in fact manage to avoid those interoperability problems that
currently are often handled by version downgrades.)

Bodo

--001a11c339e6ddb45604eb86b2b1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">2013/11/8 Watson Ladd <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:watsonbladd@gmail.com" target=3D"_blank">watsonbladd@gmail.com</a>&gt;<=
/span><div><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex">

<div>
&gt; The downgrade attack to TLS 1.2 is possible and would trigger the SNI =
to be<br>
&gt; send in clear again.<br>
&gt; (It requires an active attack).<br>
</div>Why wasn&#39;t this fixed years ago?</blockquote><div><br></div><div>=
This is not an easy question to answer. =A0(Yes, it certainly *should* have=
 been fixed years ago.)<br></div><div>=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

 The client should indicate the<br>
highest offered version when falling back, and the server should<br>
signal if there is a problem. This was an issue with SSL 3.0 and TLS<br>
1.0. It&#39;s still an issue today because SSL 3.0 is still out there.</blo=
ckquote><div><br></div><div>See=A0<a href=3D"https://tools.ietf.org/html/dr=
aft-bmoeller-tls-downgrade-scsv-00" target=3D"_blank">https://tools.ietf.or=
g/html/draft-bmoeller-tls-downgrade-scsv-00</a>=A0for a proposal intended t=
o be particularly simple.</div>
<div><br></div><div>(This is not the first proposal in this spirit; see, e.=
g., <a href=3D"http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorl=
a-tls-version-cs.txt">http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-=
rescorla-tls-version-cs.txt</a>. =A0A recurring complaint is that TLS inste=
ad should promote interoperability, which I think is not a valid complaint:=
 While interoperability should be better than it is, (1) this doesn&#39;t e=
xtend to interoperability with attackers, and (2) it&#39;s a false dichotom=
y -- deploying=A0draft-bmoeller-tls-downgrade-scsv-00 would deal with secur=
ity problems that arise as implementations work around interoperability pro=
blems, but that I-D won&#39;t get in your way in any way, shape or form if =
you do in fact manage to avoid those interoperability problems that current=
ly are often handled by version downgrades.)</div>
<div><br></div><div>Bodo</div><div><br></div><div><br></div></div></div></d=
iv></div>

--001a11c339e6ddb45604eb86b2b1--

From ivan.ristic@gmail.com  Tue Nov 19 05:13:11 2013
Return-Path: <ivan.ristic@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3321ADFAA for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 05:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id outewNFvv77M for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 05:13:09 -0800 (PST)
Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 828D41ADFA9 for <tls@ietf.org>; Tue, 19 Nov 2013 05:13:09 -0800 (PST)
Received: by mail-ea0-f179.google.com with SMTP id r15so3125012ead.38 for <tls@ietf.org>; Tue, 19 Nov 2013 05:13:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5SbiIuKTw7lanhlzvE4ZWGzJsS47KL1oeGfseI1yfok=; b=OWrhRzPOCv4ITeY8r6zmIgNJdqkmn9UkVGQzRWyIkEbVdrv/Hej7VX50g2HWAfzt6m cnpzzsOBJBDolpxc7OJVLFtxNX2lO5A3qbOv4ZK6ouIjseDOVCLFNWqniaBVe/tJ1CYX ocXfIx50EjxilumnN9Ak7uwnNJOsvG3NDc/bL68huHuKqfCgE+SPB0HRaIVcqt06ullh 6jBZWBqtKBEH9uFFxFvyXMfCL8fSJAprEYKbYv6u3AKydDZgVOvRrAg5pO0gnrHwLbrD +15nxBoxWd5IU3WpCZzRJNa8Ivy+X38IDNshYvUhKzxReUmosYCw8puGB9EoCHcWOZHO XyEg==
X-Received: by 10.14.88.132 with SMTP id a4mr2906320eef.60.1384866783093; Tue, 19 Nov 2013 05:13:03 -0800 (PST)
Received: from [192.168.0.8] (97e1a0f8.skybroadband.com. [151.225.160.248]) by mx.google.com with ESMTPSA id w6sm48697359eeo.12.2013.11.19.05.13.01 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 05:13:02 -0800 (PST)
Message-ID: <528B63DC.3050207@gmail.com>
Date: Tue, 19 Nov 2013 13:13:00 +0000
From: =?UTF-8?B?SXZhbiBSaXN0acSH?= <ivan.ristic@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: tls@ietf.org
References: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
In-Reply-To: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 13:13:11 -0000

To add to this discussion about protocol version intolerance, I've been
tracking this problem in my SSL Pulse data set (SSL servers from the
Alexa top 1 million).

Here's what I have for November:

  Total servers: 163,587

  TLS 1.0 intolerance        9
  TLS 1.1 intolerance    1,388
  TLS 1.2 intolerance    1,448 (~ 0.9%)
  TLS 1.3 intolerance   17,840 (~10.9%)
  TLS 2.98 intolerance 122,698 (~75.0%)

  Long handshake intolerance: 4,795 (~2.9%)

It seems to me that attempting to deploy TLS 1.3 would be very
difficult, considering how many servers are intolerant to this version
number. And TLS 2.x would be just hopeless.

Disclaimer: I have not spent as much time as I would have liked
validating these, but I don't have a reason to believe they are not correct.


On 18/11/2013 19:25, Martin Rex wrote:
> Andrei Popov wrote:
>>
>> Yes, the percentage if servers that can't handle TLS1.2 or gracefully
>> negotiate a lower protocol version is diminishing, but very slowly.
> 
> Unfortunately, I've seen a new (government mandated) Web Service usage
> scenario deployed in 2013 where the hardware SSL/TLS accellerater that
> is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.
> 
> 
> We really need to get rid of the dependency on ClientHello.client_version
> being { 0x03, 0x03 } to use protocol features that can be implemented
> with fairly little effort in TLSv1.0, thereby obviating the need
> for reconnect fallbacks in clients -- a "feature" that most programmatic
> TLS clients do not have, and that is susceptible to downgrade.
> 
> 
>>
>> From my perspective, enabling TLS1.2 by default is necessitated
>> primarily by security and performance considerations (e.g. a chance
>> to negotiate AES_GCM instead of RC4).
> 
> The interoperability problems from sending
> ClientHello.client_version { 0x03,0x03 } are to serious and significant
> to ignore, and the kludges (reconnect fallbacks) are to cumbersome
> for most apps.
> 
> The _correct_ approach would be to publish how to use GenericAEADCipher
> record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and
> remove the braindead "must not send this ciphersuite with client_version
> less that TLSv1.2" from the AES-CCM and AES-GCM documents.
> 
> 
> rfc5746 deployed with significantly less interop problems than both
> TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).
> 
> 
>>
>> However, for web browsers, enabling TLS1.2 by default means one more
>> step in the sequence of (insecure) reconnect attempts with lower
>> protocol versions.
> 
> 
> Rather than bulding such kludges into Browsers, the implementers
> should have come to the TLS WG help working on changes to TLS that
> will make all desired TLS features work in a more backwards compatible
> fashion than through kicking "client_version" / "protocol_version" fields.
> 
> 
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


-- 
Ivan

From zooko@leastauthority.com  Tue Nov 19 06:44:50 2013
Return-Path: <zooko@leastauthority.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C351ADFF1 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 06:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7FVWxM4MDlH for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 06:44:48 -0800 (PST)
Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by ietfa.amsl.com (Postfix) with ESMTP id 464DF1ADFF0 for <tls@ietf.org>; Tue, 19 Nov 2013 06:44:48 -0800 (PST)
Received: by mail-ea0-f177.google.com with SMTP id n15so1812386ead.36 for <tls@ietf.org>; Tue, 19 Nov 2013 06:44:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=y2lcwPinD5+FO54rgvIx4Ce/2DCpgQhcfGaej73e76w=; b=azqzsf/onIPKXXWSmQGb+xzBhJGpzkNO/ZfB/65JWFfxDLrzl+LjXC+AsBJj7OkcT4 bIuYkmUMfZU1AWEkq2CIFXLANa/E8V489i4ohEmsA8I/V857HTBhna9aSOwQtDPNmSHO /TsjhRA+rzu+rV25rbdV6jrbb+ltqRJ16cMOWBbLv+fZLAA2HrV6d+HfPqnFu8v9uzvE qp5xr15K7f+6uixIGfY7w38qJIYBc3cfRbLB1lNYzgmVQ//DQLdn9Ux7wpG8wRSu2mSp nR/vGLwprbkWn5IHv5Y+Fp4LMOJ5MTgIMr/fxtUkBH8ZnviWM202cidL+ZrOIGZCYQYs T29g==
X-Gm-Message-State: ALoCoQlj+71OgP/B7rTPry7CU9S22q0W7pqKC6R9bnwymWUOME7lIvkX1+d4HdqWUKdE9fWmfu0P
MIME-Version: 1.0
X-Received: by 10.15.86.78 with SMTP id h54mr216883eez.129.1384872281476; Tue, 19 Nov 2013 06:44:41 -0800 (PST)
Received: by 10.223.174.198 with HTTP; Tue, 19 Nov 2013 06:44:41 -0800 (PST)
X-Originating-IP: [97.118.93.210]
In-Reply-To: <528AD326.8080908@kirils.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com>
Date: Tue, 19 Nov 2013 14:44:41 +0000
Message-ID: <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com>
From: Zooko Wilcox-OHearn <zooko@leastauthority.com>
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 14:44:50 -0000

On Tue, Nov 19, 2013 at 2:55 AM, Kirils Solovjovs
<kirils.solovjovs@kirils.com> wrote:
>
>> The world needs a good, permissively licensed,
>> hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
>> there is, and it has its set of issues, too.
>
> Fully seconded, Andy!
>
> Still.. what do you think should be done to alleviate this step by step?
>
> Are you proposing to scrap openssl and start from scratch?

There are many alternatives to openssl. Wikipedia has a table:

https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations

That list is not complete =E2=80=94 for example it omits Botan:

http://botan.randombit.net/tls.html

Oh, you require a permissive licence? Judging from the "Overview"
table on that wikipedia page, that narrows it down to NSS or Botan for
you.

Regards,

Zooko Wilcox-O'Hearn

Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.

From hallam@gmail.com  Tue Nov 19 06:58:35 2013
Return-Path: <hallam@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB6F1ADFE7 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 06:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35SNLDp4Gsqx for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 06:58:33 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id AC51A1ADFF9 for <tls@ietf.org>; Tue, 19 Nov 2013 06:58:32 -0800 (PST)
Received: by mail-lb0-f182.google.com with SMTP id u14so2780198lbd.27 for <tls@ietf.org>; Tue, 19 Nov 2013 06:58:26 -0800 (PST)
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=0aiDHouCwXQi7i0GYH5Ezelz/Cz5cDoHor90YEPnJvY=; b=DWv4Fc4wblkFc8fMsdP5oO+kbRXtsq/kr1MIpUTgLGCqjpUP9Xn8dBTlbS2l8s8RbY DxRg28s3pIOIvHaJqBpsdse3loTO4WJgz0zm6YvVsjQ1/D4juUg8z5L7dhZWAabU8cen 5Eoq3appWKG/afcR3NDPt1fQaFAS9CZK7B059+4sFGZ5cQDctwgJcoHzYU50mDReINJe kVF/FMKgmpxSZ1UcpCUOHF/zzn1IJojkJ6JxZupxP8WpFqfe80g8rrASrqyFNp5+ZdyR BjuLOlBeDzBuvOPKzAc1IjXrm0YUGlXefCe6euAWl7lFB+YF1GJCaJlVtwTEWi1egJIC 0vSQ==
MIME-Version: 1.0
X-Received: by 10.112.136.163 with SMTP id qb3mr18037523lbb.14.1384873105923;  Tue, 19 Nov 2013 06:58:25 -0800 (PST)
Received: by 10.112.46.98 with HTTP; Tue, 19 Nov 2013 06:58:25 -0800 (PST)
In-Reply-To: <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <m238mv1wkq.fsf@localhost.localdomain> <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com>
Date: Tue, 19 Nov 2013 09:58:25 -0500
Message-ID: <CAMm+Lwj4gh+gzwjLiFUsaZgFU5iEuHHLdAjW4ppF5qVDNQKHhg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=089e0112c73c89a43b04eb88e528
Cc: Geoffrey Keating <geoffk@geoffk.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 14:58:35 -0000

--089e0112c73c89a43b04eb88e528
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 17, 2013 at 12:29 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <geoffk@geoffk.org>wrote:
>>
>> Then, if people want a key agreement where one side generates a random
>> master key, encrypts it with RSA, and sends it to the other, we can do
>> that.  The RSA key can be ephemeral (or, at least, changed much more
>> often than today's typical "once every two years"), which gives
>> forward secrecy, or the RSA key can be fixed, if forward secrecy is
>> explicitly not wanted
>>
>
> Oops, yeah, forgot to mention this.
>
> As you say, it's possible to generate a short-term RSA key and use it
> for multiple connections. This gives some level of forward security.
>

Rob Stradling and I were kicking around a scheme that was similar a few
weeks back.

The goal here is not so much forward secrecy as to increase the work factor
for an attacker. We have been considering short lived certs as a mechanism
for addressing the revocation issue for some time. Generating a new cert
with a different key each time does not increase the effort a great deal if
it is thought about at the start.


The precondition for any scheme that involves daily cert issue is that it
be fully automated. And this is the part that needs work. Specifically we
need:

1) Web servers able to switch certificates and keys without a reboot.
2) Automatic generation of key sets and CSRs in advance
3) Automatic issue of certificates.


Note that (2) and (3) are separate because we might well want to use
different tools to do each one. We might even want to do the process in
bulk and generate a whole year's worth of keys at once and the
corresponding CSRs and upload the whole lot to the CA in one go.

It is good to have ephemeral keying AS WELL. But we are currently limited
to only 1024 bits of EK due to the support issues. I would like more.


-- 
Website: http://hallambaker.com/

--089e0112c73c89a43b04eb88e528
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sun, Nov 17, 2013 at 12:29 AM, Eric Rescorla <span dir=3D"ltr">&=
lt;<a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com</a>&gt;</=
span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey K=
eating <span dir=3D"ltr">&lt;<a href=3D"mailto:geoffk@geoffk.org" target=3D=
"_blank">geoffk@geoffk.org</a>&gt;</span> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex">




Then, if people want a key agreement where one side generates a random<br>
master key, encrypts it with RSA, and sends it to the other, we can do<br>
that. =A0The RSA key can be ephemeral (or, at least, changed much more<br>
often than today&#39;s typical &quot;once every two years&quot;), which giv=
es<br>
forward secrecy, or the RSA key can be fixed, if forward secrecy is<br>
explicitly not wanted<br></blockquote><div><br></div></div><div>Oops, yeah,=
 forgot to mention this.</div><div><br></div><div>As you say, it&#39;s poss=
ible to generate a short-term RSA key and use it</div><div>for multiple con=
nections. This gives some level of forward security.</div>

</div></div></div></blockquote><div><br></div><div>Rob Stradling and I were=
 kicking around a scheme that was similar a few weeks back.</div><div><br><=
/div><div>The goal here is not so much forward secrecy as to increase the w=
ork factor for an attacker. We have been considering short lived certs as a=
 mechanism for addressing the revocation issue for some time. Generating a =
new cert with a different key each time does not increase the effort a grea=
t deal if it is thought about at the start.</div>
<div><br></div><div><br></div><div>The precondition for any scheme that inv=
olves daily cert issue is that it be fully automated. And this is the part =
that needs work. Specifically we need:</div><div><br></div><div>1) Web serv=
ers able to switch certificates and keys without a reboot.</div>
<div>2) Automatic generation of key sets and CSRs in advance</div><div>3) A=
utomatic issue of certificates.</div>
<div>=A0</div></div><div><br></div><div>Note that (2) and (3) are separate =
because we might well want to use different tools to do each one. We might =
even want to do the process in bulk and generate a whole year&#39;s worth o=
f keys at once and the corresponding CSRs and upload the whole lot to the C=
A in one go.</div>
<div><br></div><div>It is good to have ephemeral keying AS WELL. But we are=
 currently limited to only 1024 bits of EK due to the support issues. I wou=
ld like more.</div><div><br></div><div><br></div>-- <br>Website: <a href=3D=
"http://hallambaker.com/" target=3D"_blank">http://hallambaker.com/</a><br>

</div></div>

--089e0112c73c89a43b04eb88e528--

From dharkins@lounge.org  Tue Nov 19 07:31:17 2013
Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D820C1AE060 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9virBGm3vzw for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:31:16 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5B99C1AE056 for <tls@ietf.org>; Tue, 19 Nov 2013 07:31:16 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0D3281022400A; Tue, 19 Nov 2013 07:31:10 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 19 Nov 2013 07:31:10 -0800 (PST)
Message-ID: <ab46858e8823b4b08aea11ae1b8b268e.squirrel@www.trepanning.net>
In-Reply-To: <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net> <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com>
Date: Tue, 19 Nov 2013 07:31:10 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Ralf Skyper Kaiser" <skyper@thc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 15:31:18 -0000

  Hi Ralf,

On Tue, November 19, 2013 2:15 am, Ralf Skyper Kaiser wrote:
> Hi Dan,
>
> The security risk lies within the implementation.
>
> The capable client will always offer TLS-PWD.

  Unless it is expressly told not to because of some external event,
like pinning of a certificate for websec.

> Simplified, this is how pinning will be implemented: The client receives
> the server's certificate. The client checks if the server's certificate
> (or
> better the SPKI) is already known to the client (e.g. pinned) and if the
> server's certificate is different to the pinned certificate then the
> connection fails.
>
> The draft assumes that certificate based server authentication is the only
> authentication that exists.
>
> The draft does not discuss the scenario where TLS-PWD is used.
>
> In such a case I'm concerned that the part of the client source code that
> checks for pinning is not triggered and by-passed. The client goes into
> the
> TLS-PWD mode.
>
> Instead what should be pinned is the SPKI _and_ that certificate based
> server-authentication must be used. E.g. once a client has pinned a
> certificate for a host it should not allow TLS-PWD.
>
> This is obvious to us but not obvious to the developer and should be
> explicitly mentioned.
>
> (It could be mentioned in websec-rfc as you say but that's beyond draft
> status and additions are no longer practical). Mentioning it in the
> TLS-PWD
> draft will hopefully prevent an insecure implementation.

  It's a draft. The tracker does not indicate that it has passed IETF LC.
Make the comment. It's the right place to do so. If you want this
event to take precedence then expressly say so in the document
that defines the event.

  regards,

  Dan.

> regards,
>
> Ralf
>
>
>
>
> On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>>   Hi Ralf,
>>
>> On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
>> > Hi,
>> >
>> > could not find it in the draft:
>> >
>> > the interoperability with draft-ietf-websec-key-pinning-08 should be
>> > mentioned explicitly to prevent
>> > an attack scenario. (e.g. user has pinned certificate for google.com.
>> > Attacker MITM forces
>> > client to do tls-pwd. Client should not allow this). E.g. once a host
>> is
>> > pinned no other server-side
>> > auth mechanism should be allowed.
>>
>>   If the client doesn't want to do TLS-pwd then it won't include the
>> mandatory extension in its client hello and it won't include any TLS-pwd
>> ciphersuites. I don't see how this attack happens.
>>
>>   Perhaps the necessary requirements to deal with pinning certificates
>> for websec should be dealt with in the draft you mention.
>>
>>   regards,
>>
>>   Dan.
>>
>>
>>
>>
>



From dharkins@lounge.org  Tue Nov 19 07:33:42 2013
Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBED21AE023 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAHoceIEGRVZ for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:33:41 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75E1AE010 for <tls@ietf.org>; Tue, 19 Nov 2013 07:33:41 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4092210224008; Tue, 19 Nov 2013 07:33:35 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 19 Nov 2013 07:33:35 -0800 (PST)
Message-ID: <de18fa62ba0d8da0b1f618fafe696b30.squirrel@www.trepanning.net>
In-Reply-To: <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <CA+BZK2rQ9-3XYB0sUJA-iWHBEfQrnkeo6q+VMt2jcV16ryupnQ@mail.gmail.com> <cd311295df981e28835cfc44ab95bb3a.squirrel@www.trepanning.net> <CA+BZK2qPEXXK6zGHU3MJ4Z64sQkPLPQp1T6i6AT2k-Odjb8tuQ@mail.gmail.com> <D4318E7AF8480146A18F382CB1E64DBD15A20C0009@W2053.kpnnl.local>
Date: Tue, 19 Nov 2013 07:33:35 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: oscar.koeroo@kpn.com
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 15:33:43 -0000

  Hi Oscar,

On Tue, November 19, 2013 3:15 am, oscar.koeroo@kpn.com wrote:
> May I add that it's not clear which elements are to be presented to the
> user for visual (or automated) inspection and in which form. I can handle
> long random string for visual inspection, but I wonder if this is to be
> expected from all users. If I've understood the spec correctly the
> fingerprint of the public key and the domain names, i.e. the subject alt
> names, are to be presented to the user. This could turn out to be quite a
> bit of data per certificate.
>
> Also, if the fingerprint is tied to public key exclusively I wonder what
> the UAs are expected to do when subject alt names have changed in the
> certificates when the public key is preserved.

  Very interesting questions... for the web sec WG; this is TLS. And this
is a thread dealing with a draft that does certificate-less authentication.

  regards,

  Dan.

> Oscar Koeroo
> Red Team / Ethical Hacker
> Chief Information Security Office
> KPN
> Tel: +31 6 1217 5278
> Fingerprint: 3D5F 5BA5 AF84 BBE1 3D60 8621 0DCD 74C3 A211 B654
>
>
> Van: TLS [mailto:tls-bounces@ietf.org] Namens Ralf Skyper Kaiser
> Verzonden: dinsdag 19 november 2013 11:16
> Aan: Dan Harkins
> CC: tls@ietf.org
> Onderwerp: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
>
> Hi Dan,
> The security risk lies within the implementation.
>
> The capable client will always offer TLS-PWD.
>
> Simplified, this is how pinning will be implemented: The client receives
> the server's certificate. The client checks if the server's certificate
> (or better the SPKI) is already known to the client (e.g. pinned) and if
> the server's certificate is different to the pinned certificate then the
> connection fails.
> The draft assumes that certificate based server authentication is the only
> authentication that exists.
> The draft does not discuss the scenario where TLS-PWD is used.
> In such a case I'm concerned that the part of the client source code that
> checks for pinning is not triggered and by-passed. The client goes into
> the TLS-PWD mode.
>
> Instead what should be pinned is the SPKI _and_ that certificate based
> server-authentication must be used. E.g. once a client has pinned a
> certificate for a host it should not allow TLS-PWD.
> This is obvious to us but not obvious to the developer and should be
> explicitly mentioned.
> (It could be mentioned in websec-rfc as you say but that's beyond draft
> status and additions are no longer practical). Mentioning it in the
> TLS-PWD draft will hopefully prevent an insecure implementation.
>
> regards,
>
> Ralf
>
>
> On Mon, Nov 18, 2013 at 9:51 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>   Hi Ralf,
>
> On Tue, November 12, 2013 2:28 am, Ralf Skyper Kaiser wrote:
>> Hi,
>>
>> could not find it in the draft:
>>
>> the interoperability with draft-ietf-websec-key-pinning-08 should be
>> mentioned explicitly to prevent
>> an attack scenario. (e.g. user has pinned certificate for google.com.
>> Attacker MITM forces
>> client to do tls-pwd. Client should not allow this). E.g. once a host is
>> pinned no other server-side
>> auth mechanism should be allowed.
>   If the client doesn't want to do TLS-pwd then it won't include the
> mandatory extension in its client hello and it won't include any TLS-pwd
> ciphersuites. I don't see how this attack happens.
>
>   Perhaps the necessary requirements to deal with pinning certificates
> for websec should be dealt with in the draft you mention.
>
>   regards,
>
>   Dan.
>
>
>
>



From msweet@apple.com  Tue Nov 19 07:54:54 2013
Return-Path: <msweet@apple.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2FB1ADF47 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:54:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.127
X-Spam-Level: 
X-Spam-Status: No, score=-7.127 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXRH_QxEXtNl for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 07:54:52 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB01ACC8B for <tls@ietf.org>; Tue, 19 Nov 2013 07:54:52 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MWI00124PIUBYA1@mail-out.apple.com> for tls@ietf.org; Tue, 19 Nov 2013 07:54:43 -0800 (PST)
X-AuditID: 11807153-b7f246d000005e2f-40-528b89c2b667
Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate)	by relay3.apple.com (Apple SCV relay) with SMTP id C3.7C.24111.2C98B825; Tue, 19 Nov 2013 07:54:42 -0800 (PST)
Received: from [17.153.62.85] by sesame.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MWI00H1RPJ4ZE50@sesame.apple.com> for tls@ietf.org; Tue, 19 Nov 2013 07:54:42 -0800 (PST)
From: Michael Sweet <msweet@apple.com>
In-reply-to: <528B63DC.3050207@gmail.com>
Date: Tue, 19 Nov 2013 10:54:40 -0500
Content-transfer-encoding: quoted-printable
Message-id: <1BFA59E4-7393-479A-A7C8-FBF2906795F6@apple.com>
References: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp> <528B63DC.3050207@gmail.com>
To: =?utf-8?Q?Ivan_Risti=C4=87?= <ivan.ristic@gmail.com>
X-Mailer: Apple Mail (2.1824)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDcoHuoszvIYO8mcYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXTZT8aCrwoVOy70sDUwXpLqYuTkkBAwkehYOZ8dwhaTuHBv PVsXIxeHkEAfk8SMye/ZIZw/jBIXltwBqxIWKJQ4sWM2M4jNK6An8W7NHaYuRg4OZgF1iSlT ckHCbAJqEr8n9bGC2JwCmhKHVv5nBLFZBFQlvm+eC9bKLCAgce7ZCyhbW+LJuwusECNtJFbc 6mIDsYUEoiQ2rHwCZosIWEgc63/JBrJKQkBW4l1z0ARGgVlIjpiFcMQsJEMXMDKvYhQoSs1J rDTWSywoyEnVS87P3cQIDrrC4B2Mf5ZZHWIU4GBU4uGd4N4VJMSaWFZcmXuIUYKDWUmEt6a+ O0iINyWxsiq1KD++qDQntfgQozQHi5I47yMfoGqB9MSS1OzU1ILUIpgsEwenVAPjxKg1nxYW 7Ys8Evnh1HtbgT9fVx5KnaRvs//Paak5uRIn5F/0mQSoVf7guZ6Xw35jwsuaW+tyT63L+zRX 0c1JRHfGstk7AgOzw36H6omZ/8marCW5ZY6Eh0Cet87pn9avf/burzya92ue27yEObw2Z/Va TV2bTrxcf86K8a/11gWsWQ2/AnsjlFiKMxINtZiLihMBBMv01zYCAAA=
Cc: tls@ietf.org
Subject: Re: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 15:54:54 -0000

Would a practical solution be to do a TLS 1.2.1 update that:

1. Keeps the same TLS version in the ClientHello as 1.2,
2. Adds new mandatory cipher suites (as needed),
3. Adds a fast negotiation extension (as needed/if possible), and
4. Deprecates (but does not remove) any 1.2 cipher suites we know to be =
broken.

The goal would be backwards-compatibility with TLS implementations that =
support (or at least gracefully negotiate down from) 1.2.

(IANAC (I am not a cryptographer), I just use a lot of TLS libraries and =
don=E2=80=99t know whether this is workable=E2=80=A6)


On Nov 19, 2013, at 8:13 AM, Ivan Risti=C4=87 <ivan.ristic@gmail.com> =
wrote:

> To add to this discussion about protocol version intolerance, I've =
been
> tracking this problem in my SSL Pulse data set (SSL servers from the
> Alexa top 1 million).
>=20
> Here's what I have for November:
>=20
>  Total servers: 163,587
>=20
>  TLS 1.0 intolerance        9
>  TLS 1.1 intolerance    1,388
>  TLS 1.2 intolerance    1,448 (~ 0.9%)
>  TLS 1.3 intolerance   17,840 (~10.9%)
>  TLS 2.98 intolerance 122,698 (~75.0%)
>=20
>  Long handshake intolerance: 4,795 (~2.9%)
>=20
> It seems to me that attempting to deploy TLS 1.3 would be very
> difficult, considering how many servers are intolerant to this version
> number. And TLS 2.x would be just hopeless.
>=20
> Disclaimer: I have not spent as much time as I would have liked
> validating these, but I don't have a reason to believe they are not =
correct.
>=20
>=20
> On 18/11/2013 19:25, Martin Rex wrote:
>> Andrei Popov wrote:
>>>=20
>>> Yes, the percentage if servers that can't handle TLS1.2 or =
gracefully
>>> negotiate a lower protocol version is diminishing, but very slowly.
>>=20
>> Unfortunately, I've seen a new (government mandated) Web Service =
usage
>> scenario deployed in 2013 where the hardware SSL/TLS accellerater =
that
>> is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.
>>=20
>>=20
>> We really need to get rid of the dependency on =
ClientHello.client_version
>> being { 0x03, 0x03 } to use protocol features that can be implemented
>> with fairly little effort in TLSv1.0, thereby obviating the need
>> for reconnect fallbacks in clients -- a "feature" that most =
programmatic
>> TLS clients do not have, and that is susceptible to downgrade.
>>=20
>>=20
>>>=20
>>> =46rom my perspective, enabling TLS1.2 by default is necessitated
>>> primarily by security and performance considerations (e.g. a chance
>>> to negotiate AES_GCM instead of RC4).
>>=20
>> The interoperability problems from sending
>> ClientHello.client_version { 0x03,0x03 } are to serious and =
significant
>> to ignore, and the kludges (reconnect fallbacks) are to cumbersome
>> for most apps.
>>=20
>> The _correct_ approach would be to publish how to use =
GenericAEADCipher
>> record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS =
and
>> remove the braindead "must not send this ciphersuite with =
client_version
>> less that TLSv1.2" from the AES-CCM and AES-GCM documents.
>>=20
>>=20
>> rfc5746 deployed with significantly less interop problems than both
>> TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).
>>=20
>>=20
>>>=20
>>> However, for web browsers, enabling TLS1.2 by default means one more
>>> step in the sequence of (insecure) reconnect attempts with lower
>>> protocol versions.
>>=20
>>=20
>> Rather than bulding such kludges into Browsers, the implementers
>> should have come to the TLS WG help working on changes to TLS that
>> will make all desired TLS features work in a more backwards =
compatible
>> fashion than through kicking "client_version" / "protocol_version" =
fields.
>>=20
>>=20
>> -Martin
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>=20
>=20
>=20
> --=20
> Ivan
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


From ekr@rtfm.com  Tue Nov 19 08:07:24 2013
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8101AE031 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BluigPSZRNg4 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:07:21 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9A31AE05C for <tls@ietf.org>; Tue, 19 Nov 2013 08:07:20 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so4141910wes.26 for <tls@ietf.org>; Tue, 19 Nov 2013 08:07:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KUnyxBIbEnoz3HWsifsqJt4G4cMk8PRblDl4Et5orNs=; b=gTPrTD15LoAzjq2GG+3rOfqdVoD0n5ZDby1/yTHFeu0xZ8wuoIE040x/WbtmSXMvra 6ondDkhSejhTV5TZBytXxD8jR8Jiy8XKgrlQHXECBrsJ/wjkZO3oDrRhWcm3q21yNinx g5UUTgcwBjJQS386GH3tEGAzf0sewdV06AiROa01eDEPrETDidcJBV/qSmBsLYvpq2uq r2KN49cq4YwZddLW6YybPFjEmccsAjNdAElA5sG7aa2dz2BXADH0U3Hx1tZDCpNDdBVg uA4YF6n0mJe+2HX3FFCkjKyEeKsbHZl+4Ekew9nBmKe+9Ls8i6xIy4yhP4DnNwd9NDfY yNXg==
X-Gm-Message-State: ALoCoQlkcJz/0pGVRCTB63A+aMqK0ZJOSwle80uYGjLsSSg+hLVa+0brsuVtNdYX7cCSWMk0cSKL
X-Received: by 10.194.23.73 with SMTP id k9mr22813626wjf.24.1384877233928; Tue, 19 Nov 2013 08:07:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Tue, 19 Nov 2013 08:06:33 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <1BFA59E4-7393-479A-A7C8-FBF2906795F6@apple.com>
References: <20131118192532.9CE531AAB0@ld9781.wdf.sap.corp> <528B63DC.3050207@gmail.com> <1BFA59E4-7393-479A-A7C8-FBF2906795F6@apple.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 19 Nov 2013 08:06:33 -0800
Message-ID: <CABcZeBOXsAj7UZqRk50GB4enC_BzeOXe0GDTKx_bQ_G-P4kjQg@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Content-Type: multipart/alternative; boundary=047d7b5d43969612bc04eb89db3f
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS protocol version intolerance [Was: Re: Deployment ... Re: This working group has failed]
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 16:07:24 -0000

--047d7b5d43969612bc04eb89db3f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 19, 2013 at 7:54 AM, Michael Sweet <msweet@apple.com> wrote:

> Would a practical solution be to do a TLS 1.2.1 update that:
>
> 1. Keeps the same TLS version in the ClientHello as 1.2,
> 2. Adds new mandatory cipher suites (as needed),
> 3. Adds a fast negotiation extension (as needed/if possible), and
> 4. Deprecates (but does not remove) any 1.2 cipher suites we know to be
> broken.
>
> The goal would be backwards-compatibility with TLS implementations that
> support (or at least gracefully negotiate down from) 1.2.
>
> (IANAC (I am not a cryptographer), I just use a lot of TLS libraries and
> don=E2=80=99t know whether this is workable=E2=80=A6)


If the version number is the challenge, we may have to do something like
that.

I suggest we hold off on this question until we have a better sense of what
exactly
we want to stuff in TLS 1.3 and which pieces of it are going to be
compatible
versus just switch-hitting.

Best,
-Ekr




> On Nov 19, 2013, at 8:13 AM, Ivan Risti=C4=87 <ivan.ristic@gmail.com> wro=
te:
>
> > To add to this discussion about protocol version intolerance, I've been
> > tracking this problem in my SSL Pulse data set (SSL servers from the
> > Alexa top 1 million).
> >
> > Here's what I have for November:
> >
> >  Total servers: 163,587
> >
> >  TLS 1.0 intolerance        9
> >  TLS 1.1 intolerance    1,388
> >  TLS 1.2 intolerance    1,448 (~ 0.9%)
> >  TLS 1.3 intolerance   17,840 (~10.9%)
> >  TLS 2.98 intolerance 122,698 (~75.0%)
> >
> >  Long handshake intolerance: 4,795 (~2.9%)
> >
> > It seems to me that attempting to deploy TLS 1.3 would be very
> > difficult, considering how many servers are intolerant to this version
> > number. And TLS 2.x would be just hopeless.
> >
> > Disclaimer: I have not spent as much time as I would have liked
> > validating these, but I don't have a reason to believe they are not
> correct.
> >
> >
> > On 18/11/2013 19:25, Martin Rex wrote:
> >> Andrei Popov wrote:
> >>>
> >>> Yes, the percentage if servers that can't handle TLS1.2 or gracefully
> >>> negotiate a lower protocol version is diminishing, but very slowly.
> >>
> >> Unfortunately, I've seen a new (government mandated) Web Service usage
> >> scenario deployed in 2013 where the hardware SSL/TLS accellerater that
> >> is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.
> >>
> >>
> >> We really need to get rid of the dependency on
> ClientHello.client_version
> >> being { 0x03, 0x03 } to use protocol features that can be implemented
> >> with fairly little effort in TLSv1.0, thereby obviating the need
> >> for reconnect fallbacks in clients -- a "feature" that most programmat=
ic
> >> TLS clients do not have, and that is susceptible to downgrade.
> >>
> >>
> >>>
> >>> From my perspective, enabling TLS1.2 by default is necessitated
> >>> primarily by security and performance considerations (e.g. a chance
> >>> to negotiate AES_GCM instead of RC4).
> >>
> >> The interoperability problems from sending
> >> ClientHello.client_version { 0x03,0x03 } are to serious and significan=
t
> >> to ignore, and the kludges (reconnect fallbacks) are to cumbersome
> >> for most apps.
> >>
> >> The _correct_ approach would be to publish how to use GenericAEADCiphe=
r
> >> record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS and
> >> remove the braindead "must not send this ciphersuite with client_versi=
on
> >> less that TLSv1.2" from the AES-CCM and AES-GCM documents.
> >>
> >>
> >> rfc5746 deployed with significantly less interop problems than both
> >> TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).
> >>
> >>
> >>>
> >>> However, for web browsers, enabling TLS1.2 by default means one more
> >>> step in the sequence of (insecure) reconnect attempts with lower
> >>> protocol versions.
> >>
> >>
> >> Rather than bulding such kludges into Browsers, the implementers
> >> should have come to the TLS WG help working on changes to TLS that
> >> will make all desired TLS features work in a more backwards compatible
> >> fashion than through kicking "client_version" / "protocol_version"
> fields.
> >>
> >>
> >> -Martin
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >
> >
> > --
> > Ivan
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--047d7b5d43969612bc04eb89db3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 19, 2013 at 7:54 AM, Michael Sweet <span dir=3D"ltr">&lt;<a href=3D=
"mailto:msweet@apple.com" target=3D"_blank">msweet@apple.com</a>&gt;</span>=
 wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Would a practical solution be to do a TLS 1.=
2.1 update that:<br>
<br>
1. Keeps the same TLS version in the ClientHello as 1.2,<br>
2. Adds new mandatory cipher suites (as needed),<br>
3. Adds a fast negotiation extension (as needed/if possible), and<br>
4. Deprecates (but does not remove) any 1.2 cipher suites we know to be bro=
ken.<br>
<br>
The goal would be backwards-compatibility with TLS implementations that sup=
port (or at least gracefully negotiate down from) 1.2.<br>
<br>
(IANAC (I am not a cryptographer), I just use a lot of TLS libraries and do=
n=E2=80=99t know whether this is workable=E2=80=A6)</blockquote><div><br></=
div><div>If the version number is the challenge, we may have to do somethin=
g like that.</div>

<div><br></div><div>I suggest we hold off on this question until we have a =
better sense of what exactly</div><div>we want to stuff in TLS 1.3 and whic=
h pieces of it are going to be compatible</div><div>versus just switch-hitt=
ing.</div>

<div><br></div><div>Best,</div><div>-Ekr</div><div><br></div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">On =
Nov 19, 2013, at 8:13 AM, Ivan Risti=C4=87 &lt;<a href=3D"mailto:ivan.risti=
c@gmail.com">ivan.ristic@gmail.com</a>&gt; wrote:<br>


<br>
&gt; To add to this discussion about protocol version intolerance, I&#39;ve=
 been<br>
&gt; tracking this problem in my SSL Pulse data set (SSL servers from the<b=
r>
&gt; Alexa top 1 million).<br>
&gt;<br>
&gt; Here&#39;s what I have for November:<br>
&gt;<br>
&gt; =C2=A0Total servers: 163,587<br>
&gt;<br>
&gt; =C2=A0TLS 1.0 intolerance =C2=A0 =C2=A0 =C2=A0 =C2=A09<br>
&gt; =C2=A0TLS 1.1 intolerance =C2=A0 =C2=A01,388<br>
&gt; =C2=A0TLS 1.2 intolerance =C2=A0 =C2=A01,448 (~ 0.9%)<br>
&gt; =C2=A0TLS 1.3 intolerance =C2=A0 17,840 (~10.9%)<br>
&gt; =C2=A0TLS 2.98 intolerance 122,698 (~75.0%)<br>
&gt;<br>
&gt; =C2=A0Long handshake intolerance: 4,795 (~2.9%)<br>
&gt;<br>
&gt; It seems to me that attempting to deploy TLS 1.3 would be very<br>
&gt; difficult, considering how many servers are intolerant to this version=
<br>
&gt; number. And TLS 2.x would be just hopeless.<br>
&gt;<br>
&gt; Disclaimer: I have not spent as much time as I would have liked<br>
&gt; validating these, but I don&#39;t have a reason to believe they are no=
t correct.<br>
&gt;<br>
&gt;<br>
&gt; On 18/11/2013 19:25, Martin Rex wrote:<br>
&gt;&gt; Andrei Popov wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes, the percentage if servers that can&#39;t handle TLS1.2 or=
 gracefully<br>
&gt;&gt;&gt; negotiate a lower protocol version is diminishing, but very sl=
owly.<br>
&gt;&gt;<br>
&gt;&gt; Unfortunately, I&#39;ve seen a new (government mandated) Web Servi=
ce usage<br>
&gt;&gt; scenario deployed in 2013 where the hardware SSL/TLS accellerater =
that<br>
&gt;&gt; is being used is TLS version intolerant to TLSv1.1 and TLSv1.2.<br=
>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; We really need to get rid of the dependency on ClientHello.client_=
version<br>
&gt;&gt; being { 0x03, 0x03 } to use protocol features that can be implemen=
ted<br>
&gt;&gt; with fairly little effort in TLSv1.0, thereby obviating the need<b=
r>
&gt;&gt; for reconnect fallbacks in clients -- a &quot;feature&quot; that m=
ost programmatic<br>
&gt;&gt; TLS clients do not have, and that is susceptible to downgrade.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; From my perspective, enabling TLS1.2 by default is necessitate=
d<br>
&gt;&gt;&gt; primarily by security and performance considerations (e.g. a c=
hance<br>
&gt;&gt;&gt; to negotiate AES_GCM instead of RC4).<br>
&gt;&gt;<br>
&gt;&gt; The interoperability problems from sending<br>
&gt;&gt; ClientHello.client_version { 0x03,0x03 } are to serious and signif=
icant<br>
&gt;&gt; to ignore, and the kludges (reconnect fallbacks) are to cumbersome=
<br>
&gt;&gt; for most apps.<br>
&gt;&gt;<br>
&gt;&gt; The _correct_ approach would be to publish how to use GenericAEADC=
ipher<br>
&gt;&gt; record layer PDU and AES-GCM / AES-CCM with **ANY** version of TLS=
 and<br>
&gt;&gt; remove the braindead &quot;must not send this ciphersuite with cli=
ent_version<br>
&gt;&gt; less that TLSv1.2&quot; from the AES-CCM and AES-GCM documents.<br=
>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; rfc5746 deployed with significantly less interop problems than bot=
h<br>
&gt;&gt; TLSv1.1 (rfc4346) and TLSv1.2 (rfc5246).<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; However, for web browsers, enabling TLS1.2 by default means on=
e more<br>
&gt;&gt;&gt; step in the sequence of (insecure) reconnect attempts with low=
er<br>
&gt;&gt;&gt; protocol versions.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Rather than bulding such kludges into Browsers, the implementers<b=
r>
&gt;&gt; should have come to the TLS WG help working on changes to TLS that=
<br>
&gt;&gt; will make all desired TLS features work in a more backwards compat=
ible<br>
&gt;&gt; fashion than through kicking &quot;client_version&quot; / &quot;pr=
otocol_version&quot; fields.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; -Martin<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; TLS mailing list<br>
&gt;&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/tls</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Ivan<br>
&gt; _______________________________________________<br>
&gt; TLS mailing list<br>
&gt; <a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/tls</a><br>
<br>
</div></div>_______________________________________________________________=
<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br></div></div>

--047d7b5d43969612bc04eb89db3f--

From mrex@sap.com  Tue Nov 19 08:21:12 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F6B1AE082 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:21:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-xz5Q3UH9Ok for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 08:21:10 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E3A341AE081 for <tls@ietf.org>; Tue, 19 Nov 2013 08:21:09 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAJGL22a008276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 17:21:02 +0100 (MET)
In-Reply-To: <e2d8b5d7303349d1be3d2f2b43cfdb30@BY2PR03MB074.namprd03.prod.outlook.com>
To: Marsh Ray <maray@microsoft.com>
Date: Tue, 19 Nov 2013 17:21:02 +0100 (CET)
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: <20131119162102.B351C1AAB6@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Michael Staubermann <Michael.Staubermann@webolution.de>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 19 Nov 2013 16:21:12 -0000

Marsh Ray wrote:
> 
> > The weakness of TLSv1.2 is in the RSA signatures (digitally signed).
> > SSLv3, TLSv1.0 and TLSv1.1 were using an SHA1+MD5 combination for digitally
> > signed, which is stronger than SHA1 alone.
> > 
> > TLSv1.2 substituted this with either (RSA,sha1) or (RSA,md5),
> > and the latter is pretty far from 128-bit security.
> 
> Or am I missing something?

An MitM-Attacker could send an TLS signature algorithms extension
with only (rsa,md5) and (EC)DHE_RSA cipher suites to the server
to obtain large amounts of (rsa,md5) signed (EC)DHE parameters
and then try to have the client accept (rsa,md5) signed (EC)DHE
parameters.  This is entirely independent of the signatures on
the certificates.

> 
> Are you saying that TLS 1.2 clients in practice MUST send md5 and sha1
> in supported_signature_algorithms, even if they trust no MD5 or SHA-1 roots?

This isn't about the highest security level that cooperating TLS peers
might achieve, but the lowest security level that an MitM attacker can
coerce the peers to perform.


The TLS v1.2 signature algorithms extension should have NEVER conflated
"digitally-signed" algorithms with signatures on certs, and it should
have NEVER allowed anything less than SHA1+MD5 with rsa for use in
digitally signed.  We can re-use the digitally-signed TLSv1.2 PDU
changes to make the signalling available in all versions of TLS,
but the TLSv1.2 signature extension in ClientHello is for the trashcan.

-Martin

From luto@amacapital.net  Tue Nov 19 11:35:42 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E47B1AE159 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 11:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHuKq7t9YRgv for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 11:35:40 -0800 (PST)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A11AE1A0 for <tls@ietf.org>; Tue, 19 Nov 2013 11:35:40 -0800 (PST)
Received: by mail-pd0-f173.google.com with SMTP id p10so895439pdj.4 for <tls@ietf.org>; Tue, 19 Nov 2013 11:35:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UgYXcWmh2HUtLn6IUZAvEgMPVMKe1WJ/+/ls0ewn3QM=; b=g8zukDpQ/RGIkIYT2DqP4ckF0BPsXySBBi0mATNVJ0UCKXT6rIMM9fsY6fI8yh+rLn cJD5Po9Vb8IedRxrKt8pn5AIrZ7kAXpvCuoFMxZE3vVZjvT1PBaE8ZK46Dt6NXVbws4D Usx/qRWWnszykfwyt12dQfH0Y18thaumDmbkNHG5IKTj/H4QXNW1+Z2cGNVuVVPNaA7n xgNmG0eC7jVdFnb7SmA27K4ljUSRSorhm4BYJRNZguTkA22nxGWsgyIDKVOKOj9r+gvt 6Scn9IxZAX3Y2oYzGjOHbv+5F26VOjZSCiil5Fyl8cPWZxM1zP59vCm7dvwJAwq+NnRN Yu1Q==
X-Gm-Message-State: ALoCoQkMaz6+gKOigZev2yBNvCEVPbC8fn6icbv+dYhK0wMrI6oUTW66sAtsxMlOajF9NFRWq6Fg
X-Received: by 10.66.129.169 with SMTP id nx9mr9617519pab.130.1384889734449; Tue, 19 Nov 2013 11:35:34 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id er3sm32304928pbb.40.2013.11.19.11.35.33 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 11:35:33 -0800 (PST)
Message-ID: <528BBD84.60700@amacapital.net>
Date: Tue, 19 Nov 2013 11:35:32 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Zooko Wilcox-OHearn <zooko@leastauthority.com>, tls@ietf.org
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com>
In-Reply-To: <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 19:35:42 -0000

On 11/19/2013 06:44 AM, Zooko Wilcox-OHearn wrote:
> On Tue, Nov 19, 2013 at 2:55 AM, Kirils Solovjovs
> <kirils.solovjovs@kirils.com> wrote:
>>
>>> The world needs a good, permissively licensed,
>>> hard-or-impossible-to-misuse TLS API.  GnuTLS is probably the closest
>>> there is, and it has its set of issues, too.
>>
>> Fully seconded, Andy!
>>
>> Still.. what do you think should be done to alleviate this step by step?

There may be some benefit to having a real specification of what an
implementation should provide.  On the other hand, getting this right
may be impossible.

>>
>> Are you proposing to scrap openssl and start from scratch?
> 
> There are many alternatives to openssl. Wikipedia has a table:
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations
> 
> That list is not complete — for example it omits Botan:
> 
> http://botan.randombit.net/tls.html
> 
> Oh, you require a permissive licence? Judging from the "Overview"
> table on that wikipedia page, that narrows it down to NSS or Botan for
> you.

I don't personally require it, but many people probably do.  I think the
real issue is that the world seems to have standardized on an awful
implementation, and that said awful implementation probably gets the
most careful review.

I also doubt that this can be solved by policy.

Perhaps, though, IETF could publish a small list of features that TLS
implementation SHOULD offer.  For example:

 - Support any legal combination of ciphers, key exchange mechanisms,
etc. out of the box, without additional configuration, unless disabled
by the user, for security reasons, or for IP reasons.  For example,
failure to support non-P-256 curves because no curve was selected or
because P-256 was selected should violate this rule (hello, OpenSSL).

 - Support multiple clients in the same process linked against the same
library without causing those clients to interfere with each other
(hello, GnuTLS).

 - When in client mode, implementations MUST refuse to connect to a
server unless an explicitly chosen set of trust roots (or other
mechanism such as DANE) authenticates that server (hello, everything).

 - Standardize on an (abstract) representation of a certificate chain
and standardize an API for doing PKIX verification.  (There's lots of
freedom here, but I guarantee that OpenSSL's approach is wrong.)

There could also be an official (or semi-official) list, updated from
time to time, of what a TLS implementation must do to be considered
secure.  For example, right now I'd want to check that the
implementation I use does 1/n-1 record splitting, uses a true
constant-time CBC MAC implementation, gets GCM right, etc., and I
probably don't know the full list.

Still, creating good software by fiat is hard.

--Andy

From Andrei.Popov@microsoft.com  Tue Nov 19 11:42:20 2013
Return-Path: <Andrei.Popov@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038A01AE1D4 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 11:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGIjo-KVvf8Z for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 11:42:16 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB6A1AE1AF for <tls@ietf.org>; Tue, 19 Nov 2013 11:42:16 -0800 (PST)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB193.namprd03.prod.outlook.com (10.255.230.141) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 19:42:08 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.47]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.145]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 19:42:08 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Brian Smith <brian@briansmith.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2EJNfUuzvrkqBLee9/27ncAAXTtmAAnSaQgAAG44eMA==
Date: Tue, 19 Nov 2013 19:42:08 +0000
Message-ID: <e343ad5e45ac42ad8114ac4ebc09a1ca@BL2PR03MB194.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CAFewVt5K07p4UTzpkaXMxscbUuBo-jNB=VGF_cscGY3ZhPss-Q@mail.gmail.com>
In-Reply-To: <CAFewVt5K07p4UTzpkaXMxscbUuBo-jNB=VGF_cscGY3ZhPss-Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(52544002)(24454002)(377454003)(51704005)(51444003)(164054003)(13464003)(45984002)(199002)(189002)(87936001)(51856001)(74366001)(87266001)(2656002)(33646001)(54356001)(76482001)(85306002)(50986001)(81342001)(81542001)(46102001)(53806001)(77096001)(81816001)(56816003)(76796001)(56776001)(76786001)(54316002)(81686001)(15975445006)(63696002)(79102001)(74706001)(74876001)(4396001)(19580395003)(19580405001)(83322001)(65816001)(80022001)(59766001)(77982001)(80976001)(69226001)(49866001)(47446002)(47736001)(76576001)(74662001)(74502001)(47976001)(83072001)(31966008)(74316001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB193; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 19:42:20 -0000

Hi Brian,

I totally agree that we need to encrypt more information in the TLS handsha=
ke, including the client cert and the contents of various extensions, such =
as SNI and ALPN. Unfortunately, the only way to make this information confi=
dential in the existing versions of TLS is to incur additional round-trips =
(by using renegotiation, or otherwise exchanging messages after the TLS han=
dshake is complete). This is one of the reasons why the TLS WG is pushing h=
ard to make progress on TLS1.3.

> As far as I've been led to believe, ALPN exists primarily to allow MitM t=
o more easily inspect what protocol the application is speaking and possibl=
y block the application, with as low of a cost to the MitM as possible--i.e=
.
> exactly the opposite goal of everything we discussed at IETF88 in perpass=
 and in other discussions.

No, ALPN exists primarily to negotiate an application protocol without incu=
rring extra round-trips, to allow the server to pick the application protoc=
ol and present the corresponding identity, and to align with the existing T=
LS extensions.

>I think that in many cases, traffic analysis that relies on timing informa=
tion will be able to tell with a high degree of accuracy which protocol has=
 been selected for use on the connection. However, traffic analysis cannot =
tell us what protocols were offered but *not* selected.

Correct, and NPN offers the list of the application protocols in clear-text=
, so it does not solve this problem.

> I will be sharing a write-up of how this would work shortly. IMO, it is m=
uch better to have the long-term solution for protocol and settings negotia=
tion be in the application layer, if it is reasonable to do so.
> I am not one of those people that yell "layer violation" at everything, b=
ut if we can avoid later violations in the long term, then we should do so.

If we can avoid application protocol negotiation at the TLS layer without i=
ncurring additional round-trips, I am in full support. Looking forward to t=
he write-up.

Thanks,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Brian Smith
Sent: Monday, November 18, 2013 9:59 PM
To: Xiaoyong Wu
Cc: <tls@ietf.org>; Peter Gutmann
Subject: Re: [TLS] ALPN concerns

On Wed, Nov 6, 2013 at 10:00 AM, Xiaoyong Wu <X.Wu@f5.com> wrote:
> As I am explaining this in detail, I would say that another work around o=
n this would be making a client hello that exceeds 512 in length.

Xiaoyong, thank you very much for sharing that with us! That is incredibly =
useful.

In the thread "Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3,"=
 Yoav Nir <ynir@checkpoint.com> wrote:
> I think it would actually be worse than that. Browsers don't want=20
> reconnect fallback. So whatever TLS 1.3 looks like, the ClientHello=20
> that browsers send will be such that it can be accepted by at least=20
> TLS 1.0 servers (and there are plenty of those around). And as others=20
> have mentioned, SNI is needed in many cases. Without it,=20
> https://www.gmail.com will give you a certificate error.
>
> So you might have a clientHello that leads to super-duper TLS 1.3, but=20
> to avoid the need for fallback, you include the SNI (and presumably=20
> ALPN) in the ClientHello.

This is exactly right for SNI. Even if we define a new replacement for SNI,=
 browsers will still be sending SNI in the clear for the next 10 years. We =
should still try to work toward a long-term solution to that problem, but i=
t isn't something that can be solved in the short term.

During the TLS WG session at IETF88, somebody commented that TLS 1.3 is sup=
posed to solve the problem of encrypting information in the ClientHello, so=
 the plaintext vs. cleartext issue shouldn't be a concern for ALPN. But, fo=
r the same reason we can't have any near-term solution for encrypting SNI i=
n the ClientHello, we won't have any near-term solution for encrypting ALPN=
 in the ClientHello that would meet browsers needs.

Again, I want to emphasize that Firefox ALREADY solves this problem, even w=
ithout TLS 1.3, by implementing NPN and avoiding ALPN. If other browsers ju=
st turned off ALPN then the problem of how to hide the protocol negotiation=
 information would be solved. As far as I've been led to believe, ALPN exis=
ts primarily to allow MitM to more easily inspect what protocol the applica=
tion is speaking and possibly block the application, with as low of a cost =
to the MitM as possible--i.e.
exactly the opposite goal of everything we discussed at IETF88 in perpass a=
nd in other discussions. I still have a lot of trouble understanding how we=
 can agree in the IETF as a whole that we should be trying to make attacks =
more difficult, even if we can't make them impossible, but here in the TLS =
WG, we are literally going out of our way to leak information in the clear =
unnecessarily.

I think that in many cases, traffic analysis that relies on timing informat=
ion will be able to tell with a high degree of accuracy which protocol has =
been selected for use on the connection. However, traffic analysis cannot t=
ell us what protocols were offered but *not* selected. Further, traffic ana=
lysis based on timing is more expensive and less reliable than having the i=
nformation given on a silver platter. In some cases, traffic analysis vs. e=
xplicit plaintext leakage might be the difference between reasonable doubt =
or not. In other cases, the difficulty of discerning two protocols--whether=
 you are sending email (SMTP) or pinging the server to retrieve email
(IMAP) vs loading the login page (HTTP)--may increase the storage and proce=
ssing cost by an order of magnitude or more, if we can get it to work. Pers=
onally, I'm disappointed to hear the arguments that it is not worthwhile to=
 consider trying to solve that problem in the context of the design of ALPN=
, because we worry it is unsolvable. I feel like we haven't even started tr=
ying to solve it yet, so I don't understand why we're giving up so easily.

Further, I don't see a need to rush to a conclusion on ALPN for HTTP/2 give=
n this chart:
https://github.com/http2/http2-spec/wiki/Implementations

At the time I write this, 11/13 support NPN. 6/13 support ALPN, and there a=
re plenty of implementations that can interoperate. Literally, a higher num=
ber of products would have to do extra work to reduce the privacy of their =
protocol and settings negotiation than the number of products that would ne=
ed to flip a single bit (or less) to have a higher level of privacy protect=
ion for the protocol and settings negotiation. (Note that it isn't even cle=
ar what settings negotiation
HTTP/2 may add to the protocol negotiation step, so we cannot even debate h=
ow sensitive the information in that settings negotiation is when trying to=
 determine if leaking application data in the ALPN extension is acceptable.=
)

Also note that the Mozilla line in the chart is a little misleading.
Patrick added ALPN support to a private copy of Firefox for the purpose of =
the interop testing, which is I support. However, Firefox doesn't actually =
support ALPN in our shipping product, only in Patrick's special build. And,=
 I would very much like to keep it that way.

FWIW, I am working on an experiment for adding NPN support to Thunderbird (=
an email client based on Gecko, like Firefox), so that Thunderbird can spea=
k SMTP, IMAP, POP, LDAP, and HTTP to a single server on a single port, http=
s://example.org:443/. One purpose of this experiment is to demonstrate how =
we can get through networks that block, or charge extra money for, email pr=
otocols while still allowing HTTPS, without needing separate hostnames for =
each server. A second purpose is to evaluate whether there are effective wa=
ys of making side channel analysis for distinguishing the user's activity--=
sending email vs retrieving email, for example--or even what product the us=
er is using--Thunderbird vs. Firefox--more difficult than we might first su=
spect. I would appreciate it if the working group could give me some more t=
ime to complete this experiment and/or help me with it, before completely g=
iving up on trying to protect the protocol negotiation information in the h=
andshake.

Also, if we can build a reliable 1-RTT handshake in TLS 1.3, then there may=
 be a design that allows us to remove protocol negotiation from TLS complet=
ely, putting it back in the application layer. I will be sharing a write-up=
 of how this would work shortly. IMO, it is much better to have the long-te=
rm solution for protocol and settings negotiation be in the application lay=
er, if it is reasonable to do so.
I am not one of those people that yell "layer violation" at everything, but=
 if we can avoid later violations in the long term, then we should do so.

All that said, I am very grateful to the F5 team for sharing the informatio=
n to work around the interop issue that I originally complained about in my=
 ALPN Concerns email during IETF88. Xiaoyong set a great example for us all=
 and I hope that that kind of openness in sharing information continues her=
e on this list.

Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ________________________=
_______________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

From mrex@sap.com  Tue Nov 19 11:49:58 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DBB1AE19D for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 11:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47AmEl30Z6y8 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 11:49:56 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2539F1A1F7C for <tls@ietf.org>; Tue, 19 Nov 2013 11:49:55 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAJJnmag016745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Nov 2013 20:49:48 +0100 (MET)
In-Reply-To: <e2d8b5d7303349d1be3d2f2b43cfdb30@BY2PR03MB074.namprd03.prod.outlook.com>
To: Marsh Ray <maray@microsoft.com>
Date: Tue, 19 Nov 2013 20:49:48 +0100 (CET)
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: <20131119194948.C9A1C1AAB7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>, Michael Staubermann <Michael.Staubermann@webolution.de>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 19 Nov 2013 19:49:58 -0000

Marsh Ray wrote:
> Martin Rex wrote:
> > 
> > The TLSv1.1 PRF should be OK for 128-bit security strength.
> 
> TLS 1.1 https://tools.ietf.org/html/rfc4346#page-13
> "   TLS's PRF is created by splitting the secret into two halves and
>    using one half to generate data with P_MD5 and the other half to
>    generate data with P_SHA-1, then exclusive-ORing the outputs of these
>    two expansion functions together."
> 
> Good for 160 bits I figure?
> 
> TLS 1.2  https://tools.ietf.org/html/rfc5246#page-14
> "   In this section, we define one PRF, based on HMAC.  This PRF with the
>    SHA-256 hash function is used for all cipher suites defined in this
>    document and in TLS documents published prior to this document when
>    TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
>    PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
>    stronger standard hash function.
> "
> Sounds stronger to me.

The weakest link in the chain determines the strength, not the
strongest link in the chain.

NIST SP800-57 provides the following guidance on strength:

Bits of   symm.    FFC       IFC     ECC     Hash     Hash     Hash
security cipher  (DSA/DH) (e.g.RSA)         DigSig    HMAC   KeyDeriv

  80     2TDES    1024/160   1024  160-223   SHA-1    SHA-1    SHA-1
 112     3TDES    2048/224   2048  224-255  SHA-224   SHA-1    SHA-1
 128    AES-128   3072/256   3072  256-383  SHA-256   SHA-1    SHA-1
 192    AES-192   7680/384   7680  384-511  SHA-384  SHA-224  SHA-224
 256    AES-256  15360/512  15360   512+    SHA-512  SHA-256  SHA-256

So for use with RSA-2048 certs and AES128 encryption, the
TLSv1.0/v1.1 PRF should be OK.  You may want to look at how
many signatures in certificates, CRLs, OCSP, etc. still use
SHA-1, and where this gets you in the above table.


-Martin

From maray@microsoft.com  Tue Nov 19 15:21:35 2013
Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940EF1AE188 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 15:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEt65vKztQ3a for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 15:21:33 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11C1AE194 for <tls@ietf.org>; Tue, 19 Nov 2013 15:21:33 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 23:21:20 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.139]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 23:21:20 +0000
From: Marsh Ray <maray@microsoft.com>
To: Ralf Skyper Kaiser <skyper@thc.org>, "mrex@sap.com" <mrex@sap.com>
Thread-Topic: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
Thread-Index: AQHO29cN9GE/Nj9G90WztQ6LP+QAWJobvOMAgAAiKQCABcwFgIAABBoAgABJS4CAABO9AIAAG/KAgApaCoCAAL7vcA==
Date: Tue, 19 Nov 2013 23:21:19 +0000
Message-ID: <bf15ecb1612347f9ad4d2f58c4ac3195@BY2PR03MB074.namprd03.prod.outlook.com>
References: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com> <20131112214115.9095A1AA81@ld9781.wdf.sap.corp> <CA+BZK2pT8wJyLLV1K4B4tq_Ay_06dYLXyu-AM=gtWd2Ax=77qA@mail.gmail.com>
In-Reply-To: <CA+BZK2pT8wJyLLV1K4B4tq_Ay_06dYLXyu-AM=gtWd2Ax=77qA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ee31::3]
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(51704005)(81816001)(74366001)(56776001)(47446002)(80022001)(79102001)(63696002)(83072001)(77096001)(46102001)(54316002)(76786001)(74316001)(56816003)(76576001)(76796001)(50986001)(76482001)(47976001)(69226001)(31966008)(4396001)(74502001)(47736001)(81686001)(74662001)(74706001)(59766001)(74876001)(19580395003)(81542001)(51856001)(87936001)(2656002)(81342001)(87266001)(33646001)(15202345003)(85306002)(65816001)(77982001)(49866001)(15975445006)(80976001)(83322001)(54356001)(53806001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
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." <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: Tue, 19 Nov 2013 23:21:35 -0000

From: Ralf Skyper Kaiser
> > > No. Not at all. What I'm looking for is encrypted SNI and the browser=
 to stop advertising
> > > in advance which server I'm connecting to. (On a side note there is a=
 lot of work
> > > progressing in the DNS community for making DNS confidential. Now is =
the time to
> > > fix the last leg that leaks the domain name: SNI).

> > This is not something you can solve with a few tweaks of the TLS protoc=
ol.
> > And may get the consumers of TLS in big trouble if you continue boastin=
g
> > that you could achieve this, because some might fall for this myth.

I think what Martin may be referring to is that to provide this protection =
against
active MitM attackers generally requires an additional round trip.

> It fact it can be solved with a tweak in TLS 1.3. See Eric's IETF88 prese=
ntation.
> regards,

This was my prior suggestion which functions as an extension to 1.0. Postin=
g it here mainly
In case anyone was interested to see how big of a 'tweak' that requires.

http://www.ietf.org/mail-archive/web/tls/current/msg08722.html

- Marsh

Usual disclaimers apply, my own personal opinions, etc.


From maray@microsoft.com  Tue Nov 19 17:50:23 2013
Return-Path: <maray@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D11AE2C2 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 17:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV9VlMf2BI6u for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 17:50:21 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 451CA1AE2C1 for <tls@ietf.org>; Tue, 19 Nov 2013 17:50:21 -0800 (PST)
Received: from BY2PR03MB074.namprd03.prod.outlook.com (10.255.241.154) by BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 01:50:12 +0000
Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.17]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.139]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 01:50:06 +0000
From: Marsh Ray <maray@microsoft.com>
To: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] Should we support static RSA in TLS 1.3?
Thread-Index: AQHO4y6wZB7Ttjlkd0Wj6viVfZ6OoZoo1ZKAgAAIrwCAAALFgIAAA8UAgAR4TGA=
Date: Wed, 20 Nov 2013 01:50:05 +0000
Message-ID: <b80b3e7355224fa0aee303d41870fad1@BY2PR03MB074.namprd03.prod.outlook.com>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <CACsn0cnd58NwPfmXXdH4NsqPa5Mes2H5_9_HsB+jLJ8ViNG6ig@mail.gmail.com> <CABcZeBMESWo9PN7C-aeAmF+GdOGFxvS45FW=8RK1HqEEk2DPPg@mail.gmail.com> <CACsn0ckcPvm4fBB-7YqQ0HbUNcUbG8dVYL0wquOCTcMneM=JJQ@mail.gmail.com> <CABcZeBMwNh8NnzPD-_68etMWdSJqwsyTp2CDxuijSpkswkUWyw@mail.gmail.com>
In-Reply-To: <CABcZeBMwNh8NnzPD-_68etMWdSJqwsyTp2CDxuijSpkswkUWyw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ee31::3]
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(81816001)(74366001)(56776001)(47446002)(80022001)(79102001)(63696002)(83072001)(77096001)(46102001)(54316002)(76786001)(74316001)(56816003)(76576001)(76796001)(50986001)(76482001)(47976001)(69226001)(31966008)(4396001)(74502001)(47736001)(81686001)(74662001)(74706001)(59766001)(74876001)(81542001)(51856001)(87936001)(2656002)(81342001)(87266001)(33646001)(85306002)(65816001)(77982001)(49866001)(80976001)(83322001)(54356001)(53806001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::3; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <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, 20 Nov 2013 01:50:23 -0000

From: Eric Rescorla
> - TLS with False Start is already 1RT, albeit without the client
> being able to verify handshake correctness until he sees the
> server's response.

Might be worth mentioning that False Start on a client was enough
to enable the CRIME attack even if the legitimate server had
compression disabled.

In many ways, common implementations dodged the bullet with
CRIME. But this is an example where aggressive randomized
padding might have saved the day.

Saving every possible half-roundtrip brings huge rewards, and
I'm all for it. But it has its risks too.

- Marsh


From code@funwithsoftware.org  Tue Nov 19 21:06:20 2013
Return-Path: <code@funwithsoftware.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C311AE2FD for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 21:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 084pdwvFMSVN for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 21:06:18 -0800 (PST)
Received: from mail24c25-2209.carrierzone.com (mail223c25.carrierzone.com [64.29.147.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB0D1AE304 for <tls@ietf.org>; Tue, 19 Nov 2013 21:06:18 -0800 (PST)
X-Authenticated-User: ppelleti.speakeasy.net
Received: from WhiteAndNerdy.local (dsl017-096-185.lax1.dsl.speakeasy.net [69.17.96.185]) (authenticated bits=0) by mail24c25-2209.carrierzone.com (8.13.6/8.13.1) with ESMTP id rAK55wIh026426 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 05:06:01 +0000
Message-ID: <528C4332.9060806@funwithsoftware.org>
Date: Tue, 19 Nov 2013 21:05:54 -0800
From: Patrick Pelletier <code@funwithsoftware.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Andy Lutomirski <luto@amacapital.net>, Zooko Wilcox-OHearn <zooko@leastauthority.com>, tls@ietf.org, GnuTLS development list <gnutls-devel@lists.gnutls.org>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com> <528BBD84.60700@amacapital.net>
In-Reply-To: <528BBD84.60700@amacapital.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-CSC: 0
X-CHA: v=2.1 cv=aKDJ99Nm c=1 sm=1 tr=0 a=3bGt9MXpJgS1DxBngKRbCQ==:117 a=3bGt9MXpJgS1DxBngKRbCQ==:17 a=eVbW6KzvAAAA:8 a=g0qM3YM6AAAA:8 a=6UjOdiLZwlsA:10 a=2hBAM-kcgFUA:10 a=rtZ2W72OR7QA:10 a=IkcTkHD0fZMA:10 a=SF9KqDZ7AAAA:8 a=ALWXcttn4-wA:10 a=mzuW33GSGNNL2pXcDewA:9 a=QEXdDO2ut3YA:10
X-CTCH-RefID: str=0001.0A020203.528C433E.005C, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.100
X-CTCH-Rules: 
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
Subject: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-BeenThere: tls@ietf.org
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." <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, 20 Nov 2013 05:06:20 -0000

On 11/19/13, 11:35 AM, Andy Lutomirski wrote:

>   - Support multiple clients in the same process linked against the same
> library without causing those clients to interfere with each other
> (hello, GnuTLS).

What's the issue that GnuTLS has with this?  I'm more familiar with the 
issue OpenSSL has, namely that it requires threading callbacks to be 
set, so each client in the same process is going to be stomping on the 
same set of global callbacks.  I'd thought GnuTLS was better about 
global state, but maybe there's something I've missed.

Also, I thought Botan wasn't good on this point either, since it 
requires a LibraryInitializer object to be created, and (I thought) it 
doesn't support more than one LibraryInitializer existing at once.

--Patrick


From luto@amacapital.net  Tue Nov 19 22:24:31 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6271AE33D for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 22:24:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIXjs6LgnqQk for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 22:24:30 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF701AE339 for <tls@ietf.org>; Tue, 19 Nov 2013 22:24:30 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id ij19so5595650vcb.3 for <tls@ietf.org>; Tue, 19 Nov 2013 22:24:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=x8RuarYNGIpNnuWfg2J77sBFZl+ywCqystank/B3UqE=; b=mTrknqr2dBt/Xwdp6Mte2rSq+x+MEA0EbGsJ3/YFCmV3aRsHA3XhKszfsFOznJUR9w Zs+p7GIOnct1A3Govu2596xzjIA7Cz8wB1OWNmJWm5J+UtNLWV9Fr+mAUsBiemZuodCM usj252MUiSdb//73gcXD7u+PS/8o7+Vl6ar7M4qCsIEQ2lLKS2bFw4TiPxgW3ono3GcP aBZxLJHGctfpr0hWJyxs8Ooq/uPk7GREDlOqCbhpnFKROBdpXdMyA9Us04YF1Kp3lBd8 yUbnpJaW9wkvPO8porDKT0jBGedi848Dn0SGY75Opxf1kHsyCmpbp5v5A3dWt2KdcQ7v UU9g==
X-Gm-Message-State: ALoCoQlDz5oxveN27g/9woZuTmmoYoF0sZAkr2PLIPv8JAGpkjiyqPyEJb9Xrbamgl9fWcZQXQ0B
X-Received: by 10.52.118.98 with SMTP id kl2mr1259998vdb.30.1384928663649; Tue, 19 Nov 2013 22:24:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 19 Nov 2013 22:24:03 -0800 (PST)
In-Reply-To: <528C4332.9060806@funwithsoftware.org>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 19 Nov 2013 22:24:03 -0800
Message-ID: <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com>
To: Patrick Pelletier <code@funwithsoftware.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>, GnuTLS development list <gnutls-devel@lists.gnutls.org>
Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-BeenThere: tls@ietf.org
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." <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, 20 Nov 2013 06:24:31 -0000

On Tue, Nov 19, 2013 at 9:05 PM, Patrick Pelletier
<code@funwithsoftware.org> wrote:
> On 11/19/13, 11:35 AM, Andy Lutomirski wrote:
>
>>   - Support multiple clients in the same process linked against the same
>> library without causing those clients to interfere with each other
>> (hello, GnuTLS).
>
>
> What's the issue that GnuTLS has with this?  I'm more familiar with the
> issue OpenSSL has, namely that it requires threading callbacks to be set, so
> each client in the same process is going to be stomping on the same set of
> global callbacks.  I'd thought GnuTLS was better about global state, but
> maybe there's something I've missed.
>

GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it
manipulates global state, and it sometimes causes things to
malfunction after forking.  gnutls_global_init is documented as being
unsafe if called from multiple threads, which seems silly.

(As an even more off-topic aside, how is there nothing better than
pkcs11 for interfacing with abstract keys?)

> Also, I thought Botan wasn't good on this point either, since it requires a
> LibraryInitializer object to be created, and (I thought) it doesn't support
> more than one LibraryInitializer existing at once.

No clue -- I've never used it.

--Andy


-- 
Andy Lutomirski
AMA Capital Management, LLC

From martin.thomson@gmail.com  Wed Nov 20 09:37:02 2013
Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76ECE1AE4E7 for <tls@ietfa.amsl.com>; Wed, 20 Nov 2013 09:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVzmEtV78ACf for <tls@ietfa.amsl.com>; Wed, 20 Nov 2013 09:37:01 -0800 (PST)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 76D0C1AE4DA for <tls@ietf.org>; Wed, 20 Nov 2013 09:37:01 -0800 (PST)
Received: by mail-wg0-f54.google.com with SMTP id y10so9291363wgg.21 for <tls@ietf.org>; Wed, 20 Nov 2013 09:36:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=t8o5Md4QVAOqEixakYIFyRjHCjbBnyM30+PO05CaPIU=; b=ARqkn7GmhhZU04uqCChokbiVkty55nnhHPK2U43Fug5/R7UNCt1fGwRN3JhUE1VBQG rWtxongWbHEUb1U1K68UUZCJlkinFe/PQl0maO6bo8qJTAUpZXjJqU4G8Tg1YqhdThd8 Epl+WlIQtwlmmnSs4WMWG0Q0zTiuu01MZz9E+H6BGvvxj8AQN+C0DTJFyYLwams5M7XJ nAS7isC2ENG1nJgbNmAxyXurJG2E1p6lm/2Ejnen3puJ0t87qbmv/nWbztc5DKsIgfTB 3u+y540JAHZzbHb/9NKFZ/Pg4kpsv0Nsrlp2c6VDDXGa8u4MC0euvfF6CQrNz4K+fsCE KiRw==
MIME-Version: 1.0
X-Received: by 10.180.77.49 with SMTP id p17mr7937317wiw.30.1384969014649; Wed, 20 Nov 2013 09:36:54 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Wed, 20 Nov 2013 09:36:54 -0800 (PST)
Date: Wed, 20 Nov 2013 09:36:54 -0800
Message-ID: <CABkgnnUhuYbf1i_HWAYdQChvqopjTYa_hRQfozBsBJpAdMUsQw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>, Adam Langley <agl@google.com>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] Padding draft
X-BeenThere: tls@ietf.org
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." <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, 20 Nov 2013 17:37:02 -0000

How did you manage to get that draft published without a security
considerations section?  The covert channel (not side channel) stuff
could go there.

From sajualways@gmail.com  Sat Nov 23 09:28:20 2013
Return-Path: <sajualways@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501EC1AE189 for <tls@ietfa.amsl.com>; Sat, 23 Nov 2013 09:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jITxRKAqcQb1 for <tls@ietfa.amsl.com>; Sat, 23 Nov 2013 09:28:18 -0800 (PST)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 52D5F1AE182 for <tls@ietf.org>; Sat, 23 Nov 2013 09:28:18 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id wp4so2649609obc.27 for <tls@ietf.org>; Sat, 23 Nov 2013 09:28:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=iqJ5Oc1avcFxHGXOzkgwlDaCe60wiH1HA/QF5+PyLV0=; b=b4MARFlouNjl2Rb0VOs3bBuqcpfOUVXKFj4kniW/oOOdu69sA+f0lpD8Nn/ZTYFYsS N4E8H8QEbTiHRAhqHMO6rN0bv53W1wA9FqiAg5N4mjebm4ikVVCRKE+wu86MOoYzg/sm HMPs3eZZ2HfhzEypGGLvWL0yg1RmALOHAiAu06Di/JYm3PxDiQDPI+4dA5xRWSrIVC/h yBlEEaBZYX1bSAcR40xTzFxx9talkrsq087BZ2vdbLwWOt6hMnks5TQQ2Tjz4sZ7LBjW bb8BGap5rj5l83h/SI4vXzQUUD6wfLSwlDffM27U/tGeCD8FA+NLZSksgPTAAP/b+cij MqDA==
MIME-Version: 1.0
X-Received: by 10.60.44.36 with SMTP id b4mr1193846oem.53.1385227690608; Sat, 23 Nov 2013 09:28:10 -0800 (PST)
Received: by 10.76.95.170 with HTTP; Sat, 23 Nov 2013 09:28:10 -0800 (PST)
Date: Sat, 23 Nov 2013 22:58:10 +0530
Message-ID: <CAPWOt+VMUKdEJoDKN6Px6Q355JMut7Q5UHkkr26AOq7+6v3DKg@mail.gmail.com>
From: Sajeev S <sajualways@gmail.com>
To: ekr@rtfm.com
Content-Type: multipart/alternative; boundary=001a11c301866e8eda04ebdb740c
X-Mailman-Approved-At: Sat, 23 Nov 2013 12:16:07 -0800
Cc: tls@ietf.org
Subject: [TLS] TLS 1.3 Wish List Suggestions
X-BeenThere: tls@ietf.org
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." <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: Sat, 23 Nov 2013 17:32:56 -0000

--001a11c301866e8eda04ebdb740c
Content-Type: text/plain; charset=ISO-8859-1

Hi Eric,

My self Sajeev, I have  over 7+ years of expertise in Testing SSL/TLS
protocol and PKI.

I read through the "
https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf"

I have one suggestion for this "TLS 1.3 Wish List"

Can we add an TLS Extension field when we use TLS 1.3 as protocol version,
which will inform the Certificate key size bits to be used in the SSL/TLS
transaction.

As we move forward in the SSL/TLS security,the certificate key size bits
will play an important role.

Proposal----------->
1. Client hello will have extension saying that we will use 1024/2048/4096
public key bit size certificates
2. Server hello will send an extension which will decide which key size to
be used.

The above key size bit extension can be used for deciding both Server
certificates and client certificates.

 It is just an idea........need to analyse more because not only RSA/DSA
certificates will be used.
It also depends on which ciphersuite gets select..........if it is ECC
based or DH based.

we can also have the size for DH key.

For EC based we already have curve and point extensions.

Please let me know if it is feasible to add this functionality?

Regards,
Sajeev

--001a11c301866e8eda04ebdb740c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi=A0Eric,<div><br></div><div>My self Sajeev, I have =A0ov=
er 7+ years of expertise in Testing SSL/TLS protocol and PKI.</div><div><br=
></div><div>I read through the &quot;<a href=3D"https://www.ietf.org/procee=
dings/87/slides/slides-87-tls-5.pdf">https://www.ietf.org/proceedings/87/sl=
ides/slides-87-tls-5.pdf</a>&quot;</div>
<div><br></div><div>I have one suggestion for this &quot;TLS 1.3 Wish List&=
quot;</div><div><br></div><div>Can we add an TLS Extension field when we us=
e TLS 1.3 as protocol version, which will inform the Certificate key size b=
its to be used in the SSL/TLS transaction.<br>
</div><div><br></div><div>As we move forward in the SSL/TLS security,the ce=
rtificate key size bits will play an important role.</div><div><br></div><d=
iv>Proposal-----------&gt;</div><div>1. Client hello will have extension sa=
ying that we will use 1024/2048/4096 public key bit size certificates =A0=
=A0<br>
</div><div>2. Server hello will send an extension which will decide which k=
ey size to be used.</div><div><br></div><div>The above key size bit extensi=
on can be used for deciding both Server certificates and client certificate=
s.</div>
<div><br></div><div>=A0It is just an idea........need to analyse more becau=
se not only RSA/DSA certificates will be used.</div><div>It also depends on=
 which ciphersuite gets select..........if it is ECC based or DH based.</di=
v>
<div><br></div><div>we can also have the size for DH key.=A0</div><div><br>=
</div><div>For EC based we already have curve and point extensions.</div><d=
iv><br></div><div>Please let me know if it is feasible to add this function=
ality?</div>
<div><br></div><div>Regards,</div><div>Sajeev</div><div><br></div><div><br>=
</div><div><br></div></div>

--001a11c301866e8eda04ebdb740c--

From internet-drafts@ietf.org  Sat Nov 23 16:06:08 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D35C1AE34E; Sat, 23 Nov 2013 16:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1n4t3kBdvZ5g; Sat, 23 Nov 2013 16:06:06 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E151AE03A; Sat, 23 Nov 2013 16:06:06 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131124000606.19859.26066.idtracker@ietfa.amsl.com>
Date: Sat, 23 Nov 2013 16:06:06 -0800
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-pwd-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 24 Nov 2013 00:06:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Transport Layer Security Working Group of=
 the IETF.

	Title           : Secure Password Ciphersuites for Transport Layer Securit=
y (TLS)
	Author(s)       : Dan Harkins
                          Dave Halasz
	Filename        : draft-ietf-tls-pwd-02.txt
	Pages           : 29
	Date            : 2013-11-23

Abstract:
   This memo defines several new ciphersuites for the Transport Layer
   Security (TLS) protocol to support certificate-less, secure
   authentication using only a simple, low-entropy, password.  The
   ciphersuites are all based on an authentication and key exchange
   protocol that is resistant to off-line dictionary attack.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-pwd

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-pwd-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-pwd-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From dharkins@lounge.org  Sat Nov 23 16:18:43 2013
Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45541AE34C for <tls@ietfa.amsl.com>; Sat, 23 Nov 2013 16:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgxsitBxrFzu for <tls@ietfa.amsl.com>; Sat, 23 Nov 2013 16:18:42 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63C1AE2EC for <tls@ietf.org>; Sat, 23 Nov 2013 16:18:42 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 053B710224008; Sat, 23 Nov 2013 16:18:33 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 23 Nov 2013 16:18:34 -0800 (PST)
Message-ID: <a39103d81c3077504a5da352d4b95fd6.squirrel@www.trepanning.net>
In-Reply-To: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com>
Date: Sat, 23 Nov 2013 16:18:34 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Sun, 24 Nov 2013 00:18:44 -0000

  Hello,

  I just uploaded -02 of this draft. The only difference is the addition
of an example exchange in an appendix. I thought it would be useful
for evaluation of the exchange as defined in the draft so I elected to
put out this -02 before WGLC closes.

  The exchange uses private use ciphersuites because IANA has not
yet assigned numbers for the TLS-pwd ciphersuites. It negotiates
a private version of TLS_ECCPWD_WITH_AES_128_GCM_SHA25 and
uses the brainpool P256 elliptic curve.

  Please take a look. Regards,

  Dan.

On Thu, November 7, 2013 5:11 pm, Joseph Salowey (jsalowey) wrote:
> This is the beginning of the working group last call for
> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for TLS-PWD
> has been reviewed by the IRTF CFRG group with satisfactory results.  The
> document needs particular attention paid to the integration of this
> mechanism into the TLS protocol.   Please send comments to the TLS list by
> December 2, 2013.
>
> - Joe
> (For the TLS chairs)
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From agl@google.com  Mon Nov 25 15:28:19 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22491AE0CC for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8dn4shUEKEE for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C01AE0BB for <tls@ietf.org>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
Received: by mail-vb0-f53.google.com with SMTP id g10so3222890vbg.26 for <tls@ietf.org>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=pdmMIPEcBqAHMVseXTL03PjbQGYiewTSfajHImFiO5w=; b=jsnQxZvGMiz8/WTv/lHGW5DuBrzNMV0prfRy6K5hbkqOsiFwyrJbzFGP0YPL1VeFE6 HAb6iFtBVIgLojYaKdo8ubKjKGwqhSps6fSbL+Fd773aHzV22ttJP4y9P5m3VnOxiHXX kKaiI9NcI1noVahK+k7ttKJaaxSf/Lv7MZcmqLAXTl1TD4ic8Iw1HFt6U+VX3yO7KPrk iwR/wNRX+La+Wov1gi6aeK8FaF0VjRFkoBAvHe0dvTGa0sylKAtvfLjXcafXlISaokmR NrlTaPLYw/4+l9EtbdrHoj5cveQjSCHk4ykgAfIdfdcovWBxtWfqwE+YC1jxIZNAtMZ2 UfzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=pdmMIPEcBqAHMVseXTL03PjbQGYiewTSfajHImFiO5w=; b=lOJTQt7vvZQQz4e2aNZS2/+kuissaLZFXleIwu58oaw8gPtS1f7SdOk9/7VeC+gNvb hZAqMDw1edrwwJckOIz+HK+o+4sWywNxa3znvg7ZcN40tq3/GYQil7C1BaSFUIKz6AYv qLi2S58FtLctkGg49e2mzpiVWgItXrtLLA8/+FQwNPDNnuJR9qDLSaJbae576KCH60SD g/MlHlWfMCDwbBImDvFo2gYKiQOK+35pmUD0cZGrxjWrBK3JYXRKJ02U9fgr0roPg3Fa lYgZqYz3ZMYWUgFVAJqaWVyltDxg8wALfXzT6AUcJ0/JYf5/rp023FEDzm8DP9lmcpSs BzDA==
X-Gm-Message-State: ALoCoQnJOQ+UFHktYT1IGR9iBMKdXTtyXX2CZarzuAAItom9agbuC7B+i/F6QJ9dCBsy83MeQoZp5lJSnUphCbXYSI11vOsgsw0sfkFMyjhGUZzDZD8+QFi7EcIaj+V1EJK2eDeNI2+0uD/B92wSXDoS6j/s3psi7gaq6zE7CBAPECdUxNYdh+GmjZmhE/bBCZrtBkr8e+s2
X-Received: by 10.52.98.99 with SMTP id eh3mr2807040vdb.29.1385422098224; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Mon, 25 Nov 2013 15:27:58 -0800 (PST)
From: Adam Langley <agl@google.com>
Date: Mon, 25 Nov 2013 18:27:58 -0500
Message-ID: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Mon, 25 Nov 2013 23:28:20 -0000

Sad as it is, in order to work on public Internet all browsers
implement TLS fallback: in the event of a handshake failure they will
retry the connection with a lesser SSL/TLS version.

This means that an active attacker can disable AES-GCM support and,
ultimately, ECDHE if they push the browser back to SSLv3. It would be
good to finally do something about this.

As I've mentioned before, with Chrome 31, we removed support for
falling back to SSLv3 for Google sites. With Chrome 32, we were
planning on removing all fallback for Google sites.

Chrome 31 has been released and saw a fair amount of breakage due to
an anti-virus that (in some configurations) acts as a local MITM and
had bugs. Previously it was depending on browsers falling back to
SSLv3 in order to function at all.

I've since contacted a few other anti-virus and MITM vendors and asked
them about the Chrome 32 change. A couple have informed me that they
will break, at least in some configurations, if Chrome removes all
fallback because they cannot do version negotiation correctly.

I had expected the problems to come in the form of DPI devices sniping
TLS 1.2 connections with injected RSTs rather than MITMs. These
experiments in Chrome 31 and 32 were designed to probe how large a
problem they were. The plan was always to gather information and then
figure out a general solution that avoids having a special case for
Google sites in Chrome.

Since the MITMs are turning out to be the problem, I think the plan
needs rethinking as the general solution need not break MITMs and thus
could be deployed more easily.

Thus I'd like to propose the design of an SCSV with which we can move forward:

  In the event that a client is making a fallback connection, it
includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
current server which sees this cipher suite in a ClientHello SHOULD
return a fatal alert, inappropriate_fallback (86) and abort the
connection.

This will not break MITMs because they will not process the SCSV. Any
vendors that try to support the SCSV while having bugs that need
fallback will find out when things stop working. But that, thankfully,
will be their problem based on the Universal Rule of Users: the last
thing that updated is to blame.

Of course, this doesn't mean that firewalls won't turn out to be a
problem but, at the moment, we can't even figure that out because of
the the broken MITMs. We can't protect MITMed users, but it would be
nice if they didn't ruin it for everyone else.


Cheers

AGL

From watsonbladd@gmail.com  Mon Nov 25 15:49:35 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB621AE0B7 for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf8e_Ark7dim for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:49:33 -0800 (PST)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8521ADF92 for <tls@ietf.org>; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hm4so4412278wib.0 for <tls@ietf.org>; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
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=r+YjU15cweXZJUs29pe1rqRT0TTsWH3IEsk9pbCyw+c=; b=tffKznoLBqJ+vySyUFp2rwL25WENAvgDKmcnDPurlVURPWF+7QxfdfKViYk3DmkxxP XnFxrN2x76pyMw9K6CbbNnq5ItP6ztoPRLZ7H2QwkMmm8Baj85mcaWWB+QMRTSqelkZC KcgHJZujOFwxLkH6z/M8pQnWo91uWvbjmzl2DwbXQw8+mvGm1bZx3CApBbVDAtNw0M6F i3LKsle2jVxNKh5pRkHxREoc3hCw6oxM+21WfX1tykcnDAOTKsKXpuythmXLpMxez8/6 uRbTAhpgf/1pnyOaSpxxoAFAi93ZVBmIKdirT6KLoAwVqfjXRweD528eqLTgXWrByErF 0nDQ==
MIME-Version: 1.0
X-Received: by 10.180.89.68 with SMTP id bm4mr11255842wib.0.1385423372662; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Mon, 25 Nov 2013 15:49:32 -0800 (PST)
In-Reply-To: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
Date: Mon, 25 Nov 2013 15:49:32 -0800
Message-ID: <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Mon, 25 Nov 2013 23:49:35 -0000

On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <agl@google.com> wrote:

>
> Thus I'd like to propose the design of an SCSV with which we can move forward:
>
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.
I enthusiastically support this extension: it will solve a bug as old
as SSL without breaking
anything it seems. Why the hell wasn't this done sooner?
>
> This will not break MITMs because they will not process the SCSV. Any
> vendors that try to support the SCSV while having bugs that need
> fallback will find out when things stop working. But that, thankfully,
> will be their problem based on the Universal Rule of Users: the last
> thing that updated is to blame.
>
> Of course, this doesn't mean that firewalls won't turn out to be a
> problem but, at the moment, we can't even figure that out because of
> the the broken MITMs. We can't protect MITMed users, but it would be
> nice if they didn't ruin it for everyone else.
If firewalls block port 53, it's not the browser's problem. If
firewalls block 80, it's not the browser's problem. Why should
TLS 1.2 be any different?
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From agl@google.com  Mon Nov 25 15:52:57 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732891AE07D for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-XPMBEFPS_z for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:52:56 -0800 (PST)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 164CA1AE024 for <tls@ietf.org>; Mon, 25 Nov 2013 15:52:56 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id 10so3302088vbe.37 for <tls@ietf.org>; Mon, 25 Nov 2013 15:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jJqwopQR7oe90OganCpQr6jTXWwwiI1n+Zx7QO87OIk=; b=Q+0gOyGxei6GCfM3X7KaxZcrCezn8YZgA/0S7fXZcBldhYcYUQ5f0UDcUkJV4GTwO4 BtmzeXslfnzuM6bqvVbIW8Bxoz5dnFd7wbf9gRD2F6u36djhtaoxqLXpndbMPpFzgERC Qxk+1ZOuZh2OezvNIwXxVQBpSNTVPmLRbaQt8JF0bDz8fenEmeujnimocOfBnnTWGZLx U2LxCtBYEruD3OrixBrwPSWh76+6YB9fikaOChWgx44Lr1rH81P1OYfiVE5D1X3+njgr z4gMLtm8qvur/c6sHCCQL/uPLaBfnDgzWyn4TgzydyZMfmBodTS247GioVMhIohNqbzW F6Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jJqwopQR7oe90OganCpQr6jTXWwwiI1n+Zx7QO87OIk=; b=i6lhtbwDVjd1kJDHy09nOcfj/Pru/9CfLeSeXshULI5mUrqSBdIMFmPH99aClSEvDF OLtqUYNFn6tgEc+A0ixd+E6CeiVJuqAuKlHTrtAScRXyJb32jHShW4pRxP3NvtCur5FZ tqmNu8scXybVy6qYKZ0AATXhjS/1KP7DZ9+CzRcLWuQWUo4dzoIeiC1UOvnz/AFFpxFI 8VLoksvXNBTATqw39gBXqNrjrAmbQe55RK2y0awzNqMc4NKnaxcnvURGm7zHNea8REgQ BCfMiM4F+NGVxRq+h8dNhEALg/W4qrUAL8P7HhbJ+tjF3oNVt4bEWPjo8gb5BPEfq9sk mfMA==
X-Gm-Message-State: ALoCoQk9mwek0Mhaps7VK3A7myOYiA14ieGWcp9ac1J+gkmHr5DRnNdoUfQRKOsXqMnuTDw7DSZQsObng0mR1/pZQFPsOz8g/0pGHO4y6e02MBQ8I6JqpojmuoIGRGGgfsYlkJAjdyzjnLNsW4/xlWgndctZp0CasxsE9ecLVWvJKOX8sN2NBRniRjf9lhF/E7jlcWiejwmp
X-Received: by 10.220.169.203 with SMTP id a11mr3200003vcz.26.1385423575965; Mon, 25 Nov 2013 15:52:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Mon, 25 Nov 2013 15:52:35 -0800 (PST)
In-Reply-To: <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Mon, 25 Nov 2013 18:52:35 -0500
Message-ID: <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Mon, 25 Nov 2013 23:52:57 -0000

On Mon, Nov 25, 2013 at 6:49 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> If firewalls block port 53, it's not the browser's problem. If
> firewalls block 80, it's not the browser's problem. Why should
> TLS 1.2 be any different?

Because firewalls that block (by RST injecting) TLS 1.2/1.1/etc
connections currently work and this change would stop them working.
Therefore it would be Chrome's fault. (This is exactly as stupid as it
sounds, yet it is the world I live in.)


Cheers

AGL

From andrewgwilson@gmail.com  Mon Nov 25 16:52:36 2013
Return-Path: <andrewgwilson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6A31AE0DE for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 16:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BqNbr77-gnb for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 16:52:34 -0800 (PST)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3247F1AE0C8 for <tls@ietf.org>; Mon, 25 Nov 2013 16:52:34 -0800 (PST)
Received: by mail-bk0-f51.google.com with SMTP id 6so2265089bkj.38 for <tls@ietf.org>; Mon, 25 Nov 2013 16:52:33 -0800 (PST)
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=QQkiPg8+29ZYxbFEwSWBjZXlZ+DRf7kD3UcmcVkmN7E=; b=epTpmJJcB1kF7FYpyZV7u32PLDwufgeQE0+eR6ks/DWTPe7qMWSQeLLUSB/b53adhA vGQ09sAFndH1A3x2nffZkH/GWgU0+Y/GW6vsj0us/6l5cBBOycZW34mIjpEQdU5QANHZ 6q4TPoW2H0U+qk6Ey39Oah06EyRT9fPrPDY9XL4vzxfzhYmwZHvHmjNxkvcpOvN2XaGg NppW5Wrv8Oqut1BlHOi88RRc5Nkb/Mzoed0B5jBLRpXM0kWJCTGRRl9PvLY4ZQlj4kZo UJv37LAGCDtX3WyORUHhc5lAG7v4JtBKuzDvNugdgTH8/wuW4prLINROaFW3C9UVpTp9 3uqA==
MIME-Version: 1.0
X-Received: by 10.204.103.199 with SMTP id l7mr25799432bko.11.1385427153682; Mon, 25 Nov 2013 16:52:33 -0800 (PST)
Received: by 10.205.18.193 with HTTP; Mon, 25 Nov 2013 16:52:33 -0800 (PST)
In-Reply-To: <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com>
Date: Tue, 26 Nov 2013 13:52:33 +1300
Message-ID: <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com>
From: Andy Wilson <andrewgwilson@gmail.com>
To: Adam Langley <agl@google.com>
Content-Type: multipart/alternative; boundary=001a113351945bb42f04ec09e558
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 00:52:36 -0000

--001a113351945bb42f04ec09e558
Content-Type: text/plain; charset=UTF-8

I take it you're aware of
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00


On 26 November 2013 12:52, Adam Langley <agl@google.com> wrote:

> On Mon, Nov 25, 2013 at 6:49 PM, Watson Ladd <watsonbladd@gmail.com>
> wrote:
> > If firewalls block port 53, it's not the browser's problem. If
> > firewalls block 80, it's not the browser's problem. Why should
> > TLS 1.2 be any different?
>
> Because firewalls that block (by RST injecting) TLS 1.2/1.1/etc
> connections currently work and this change would stop them working.
> Therefore it would be Chrome's fault. (This is exactly as stupid as it
> sounds, yet it is the world I live in.)
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Regards

Andy

--001a113351945bb42f04ec09e558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I take it you&#39;re aware of=C2=A0<a href=3D"http://tools=
.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00">http://tools.ietf.org/=
html/draft-bmoeller-tls-downgrade-scsv-00</a>=C2=A0</div><div class=3D"gmai=
l_extra"><br>
<br><div class=3D"gmail_quote">On 26 November 2013 12:52, Adam Langley <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:agl@google.com" target=3D"_blank">agl@g=
oogle.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Mon, Nov 25, 2013 at 6:49 PM, Watson Ladd &lt;<a href=
=3D"mailto:watsonbladd@gmail.com">watsonbladd@gmail.com</a>&gt; wrote:<br>
&gt; If firewalls block port 53, it&#39;s not the browser&#39;s problem. If=
<br>
&gt; firewalls block 80, it&#39;s not the browser&#39;s problem. Why should=
<br>
&gt; TLS 1.2 be any different?<br>
<br>
</div>Because firewalls that block (by RST injecting) TLS 1.2/1.1/etc<br>
connections currently work and this change would stop them working.<br>
Therefore it would be Chrome&#39;s fault. (This is exactly as stupid as it<=
br>
sounds, yet it is the world I live in.)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
Cheers<br>
<br>
AGL<br>
_______________________________________________<br>
TLS mailing list<br>
<a href=3D"mailto:TLS@ietf.org">TLS@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/tls</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Regards<br><br>Andy
</div>

--001a113351945bb42f04ec09e558--

From yngve@spec-work.net  Mon Nov 25 16:59:30 2013
Return-Path: <yngve@spec-work.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945831AE07D for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 16:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsi7oQWBcx3V for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 16:59:27 -0800 (PST)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 341AB1AE051 for <tls@ietf.org>; Mon, 25 Nov 2013 16:59:27 -0800 (PST)
Received: from 47.70.202.84.customer.cdi.no ([84.202.70.47]:50487 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1Vl6zu-0002tp-L6 for tls@ietf.org; Tue, 26 Nov 2013 01:59:26 +0100
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
Date: Tue, 26 Nov 2013 01:59:09 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.w64s0vig3dfyax@killashandra.invalid.invalid>
In-Reply-To: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 00:59:30 -0000

Adam, a few questions:

  - Are these implementations functioning as proxies or just inspecting the  
encrypted protocol data, without decrypting?

  - Does *any* of these implementations support the Renego patch? If they  
don't, then my suggestion for using the Renego extension support as a  
proxy for version tolerance might still work.

  - Do you know that none of them will not break due to an SCSV? If they  
are breaking due to expectations of what is supposed to be in the  
handshake, some of them they could very well break due to unexpected  
ciphersuites, as well. (while the Renego SCSV seem to have worked well, I  
don't think it can be relied on as a reliable indication as it is only  
used for SSL v3-only hellos, because there are servers that does not  
tolerate the Renego extension in combination with the Renego SCSV)

A pessimistic guess is that, as per Murhpy's Law, there will be both  
broken Renego patched implementations, and implementations that react to  
the proposed SCSV. As far as the SCSVs are concerned, how do you propose  
to handle those cases?

The questions then becomes: How many cases? And, are they are "too many"?  
(If the answer to the last one is "yes, always, one broken connection is  
one too many", then let's just park this entire discussion since it will  
never amount to anything. If there is no will to actually confront the bad  
implementations, the problem will never be fixed.)

Further thoughts:

Personally, I think a line needs to be drawn in the sand (or preferably  
concrete) and version rollback should be blocked in as many cases as  
possible, and as quickly as possibly (and needless to say, I think my  
proposal [1] will work better for both of those goals than SCSVs), and let  
the server, intermediary, and client side MITM vendors fix their products  
if they break other products, like browsers and other SSL/TLS clients.

The clients could include a message directly drawing the attention to (or  
better, putting the blame on) possible incompatible software in the system  
(particularly if other information can be used to make the case that it  
works from other network locations; diagnostic testing might also help).  
As long as incompatible implementations are allowed free reign, and IMO  
that is currently the case, then they will continue to be deployed and  
won't be retired. Only placing the user's security above user experience  
will help change the situation, because when placing the experience before  
security one only gets insecurity and vulnerabilities.

In my TLS Prober sample, 81.95% of servers are now Renego patched, of  
these 0.28% (~1200) are version and/or extension intolerant (mostly  
extension intolerant)

Since the TLS 1.3/2.0/4.0 discussion have raised its head again I'll also  
mention that 1.01% of renego patched servers are intolerant for Client  
hello version signaling v3.4,  and 8.34% are intolerant for Client Hello  
version signaling v4.1 (assumes a 3.1 record version).

The question needs to be asked: Will version rollback be acceptable in the  
next generation TLS client? Particularly considering the potential  
severity of the problems it is supposed to fix?

IMO the answer should be "No", and that means that the process of weeding  
out servers and intermediates that require clients to implement version  
rollback needs to be started now, and it also means that the next  
generation TLS will need to address the problem head on, and not back  
down. If that is not done, then we will be having this discussion again in  
(or for) another 15-20, maybe 30 years.


[1]  
http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/


On Tue, 26 Nov 2013 00:27:58 +0100, Adam Langley <agl@google.com> wrote:

> Sad as it is, in order to work on public Internet all browsers
> implement TLS fallback: in the event of a handshake failure they will
> retry the connection with a lesser SSL/TLS version.
>
> This means that an active attacker can disable AES-GCM support and,
> ultimately, ECDHE if they push the browser back to SSLv3. It would be
> good to finally do something about this.
>
> As I've mentioned before, with Chrome 31, we removed support for
> falling back to SSLv3 for Google sites. With Chrome 32, we were
> planning on removing all fallback for Google sites.
>
> Chrome 31 has been released and saw a fair amount of breakage due to
> an anti-virus that (in some configurations) acts as a local MITM and
> had bugs. Previously it was depending on browsers falling back to
> SSLv3 in order to function at all.
>
> I've since contacted a few other anti-virus and MITM vendors and asked
> them about the Chrome 32 change. A couple have informed me that they
> will break, at least in some configurations, if Chrome removes all
> fallback because they cannot do version negotiation correctly.
>
> I had expected the problems to come in the form of DPI devices sniping
> TLS 1.2 connections with injected RSTs rather than MITMs. These
> experiments in Chrome 31 and 32 were designed to probe how large a
> problem they were. The plan was always to gather information and then
> figure out a general solution that avoids having a special case for
> Google sites in Chrome.
>
> Since the MITMs are turning out to be the problem, I think the plan
> needs rethinking as the general solution need not break MITMs and thus
> could be deployed more easily.
>
> Thus I'd like to propose the design of an SCSV with which we can move  
> forward:
>
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.
>
> This will not break MITMs because they will not process the SCSV. Any
> vendors that try to support the SCSV while having bugs that need
> fallback will find out when things stop working. But that, thankfully,
> will be their problem based on the Universal Rule of Users: the last
> thing that updated is to blame.
>
> Of course, this doesn't mean that firewalls won't turn out to be a
> problem but, at the moment, we can't even figure that out because of
> the the broken MITMs. We can't protect MITMed users, but it would be
> nice if they didn't ruin it for everyone else.
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From mrex@sap.com  Mon Nov 25 18:19:28 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567D31ABD2A for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 18:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBs2Ubg1blsZ for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 18:19:26 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D65011AE122 for <tls@ietf.org>; Mon, 25 Nov 2013 18:19:25 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rAQ2JOc3011775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Nov 2013 03:19:24 +0100 (MET)
In-Reply-To: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
To: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 03:19:23 +0100 (CET)
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: <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 26 Nov 2013 02:19:28 -0000

Adam Langley wrote:
> Sad as it is, in order to work on public Internet all browsers
> implement TLS fallback: in the event of a handshake failure they will
> retry the connection with a lesser SSL/TLS version.
> 
> This means that an active attacker can disable AES-GCM support and,
> ultimately, ECDHE if they push the browser back to SSLv3. It would be
> good to finally do something about this.
> 
> Thus I'd like to propose the design of an SCSV with which we can move forward:
> 
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.


We keep this proposals for newly creating interop problems keep
coming up on this list?

How about instead fixing the negotiation so that AES-GCM&AES-CCM
can be sent in whatever ClientHello there is (including SSLv2)
and an additional SCSV to signal availability of a specific subset of
ECDHE that can be used without a TLS ECC extension, such as the subset
that is supported by Windows 7+?


If there is a problem in negotiating what _we_want_to_do_, because the
installed base does not like the kind of negotiation that was originally
proposed to be used, then the pragmatic engineering approach will be
to define an alternative negotiation of at least a useful subset
that will be compatible with the installed base, and which will not need
to be stripped from a "conservative fallback handshake" -- and therefore
will be resilient to downgrade attacks, and cope with retarded middle boxes.


-Martin

From trevp@trevp.net  Mon Nov 25 18:33:09 2013
Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D45C1AE122 for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 18:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChHmF133uYxK for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 18:33:08 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 00BE11AE0BE for <tls@ietf.org>; Mon, 25 Nov 2013 18:33:07 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ez12so6412008wid.12 for <tls@ietf.org>; Mon, 25 Nov 2013 18:33:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cdt0C3BwB+ILktows7HK0Xsuvg0nguuLYZ9ZyzDwRc8=; b=G/Ign7sSUZ/EDDwWtRxZO30kxGG1yvulhzJx2Xhl/o6jAG6MlvGmz/BKmGeOUdsVph 3nVHlYefYNja8v/yW5AsDF+hG7dU4x0zMBqj2IcRItIKMAJzWgOd6x/U+t4kWKbZdgVE kniJiFL3coN8XSaLk8eCYhQH5dtnhs7NzEsnHgzQKl8/WQdj9+8n8VNKwN0AeqhoQt4l s8+VUNf15CFm4ZzZaT4pcmAW2guvcRAc0iOlJoRTu+Im8AFmRWqb3HMFV6vlfk1aZLgS w6u8lZAOAhse2nGkmRKSjWWXThd4N5WK5dHr7LmfLBroPDz0/4sWarkbEUpugQEcapKo 41UA==
X-Gm-Message-State: ALoCoQnEbMXvvTv/pi8632Hl1sXrn8UIa9Ce1L7utli4ShRpIHuXLwWzH3iSxDqMKMWgUD3ncv81
MIME-Version: 1.0
X-Received: by 10.180.20.102 with SMTP id m6mr16123891wie.22.1385433187399; Mon, 25 Nov 2013 18:33:07 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Mon, 25 Nov 2013 18:33:07 -0800 (PST)
X-Originating-IP: [12.27.66.5]
In-Reply-To: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
Date: Mon, 25 Nov 2013 18:33:07 -0800
Message-ID: <CAGZ8ZG2oBwx_Hb3mM59jWx9rZm4zcm4Sv6AdypK4WdciUtG8Bg@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 02:33:09 -0000

On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <agl@google.com> wrote:
[...]
> Chrome 31 has been released and saw a fair amount of breakage due to
> an anti-virus that (in some configurations) acts as a local MITM and
> had bugs. Previously it was depending on browsers falling back to
> SSLv3 in order to function at all.
>
> I've since contacted a few other anti-virus and MITM vendors and asked
> them about the Chrome 32 change. A couple have informed me that they
> will break, at least in some configurations, if Chrome removes all
> fallback because they cannot do version negotiation correctly.

Hi Adam,

Are these MITM products using special root certs installed in the
browser for MITM purposes?  If so, could the browser simply allow
SSLv3 fallback only when connecting to a cert under such an installed
root, while otherwise rejecting such a fallback?


Trevor

From agl@google.com  Tue Nov 26 09:23:31 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4808E1ADEBA for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:23:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IlX0ZNFmjY8 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:23:30 -0800 (PST)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 134AA1ACCFF for <tls@ietf.org>; Tue, 26 Nov 2013 09:23:29 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id jy13so4386618veb.27 for <tls@ietf.org>; Tue, 26 Nov 2013 09:23:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XCVea3Eo3xdwQCvzJ0NqFqNl/Imejq6X50IVXHPY5v8=; b=FiwuIaOrIfYHU87whGGe4jVN+RTlJdiddxCbRbuIfOT8RKZW+fTGnXDlqA3XEkAKMs IuyqcGso6aQoMPTqjESAZQVhdcfwi2IJ4HRPxGcKozjgyoIytwf6jVQxdKGn3VOkRmG/ E6n5jk9sxNhR2mEiihrPMG8bLBMbiLoa48EGALWVrV0LPjLd0aSS0JGBJW0O4zWi1kpC ad9+MbJeU4MKeAhMDLQruzRHFxgOfSzSzuhQ7G0qP7uVkzm0jiEFaTlD6o3MBeRIt4FX JHu1EGrcXe8yrDsO0ncC4RksjBnMrb3UpjSiW9Ytz5x80JGWpleFHngpWPhD7k8EAqG0 fBVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XCVea3Eo3xdwQCvzJ0NqFqNl/Imejq6X50IVXHPY5v8=; b=cn8Fzgsit0koU6wXNnEL1xV09U6b0jvE65B4U2ypS97JKDaRLA2PpWTYFs8boTMPpC 3MExjkRhrRq8PR+9KA/K0CV8JMvzQWjatL8j+MwEuDEbob6R96DRUJdlEJy695FK+IUl YqLRmRnUw1o5Tifb7YXq6/F+JBRCFu33T9JzY7+ef4J8hEc/LefmP/U52Kamcfd4rg9r g6wp9j+2RgJSGSoj2t8DT5Ib9tVkBFunekI9bomBuDaTJvVTq1N6eI/SmmmMDND5ZgpA PZ95T2OQjBRf1mgN1hjsVxLU4KwBkx2Vj47RqTHFXmBh+CWJmArij6/P0CNJImheIdeq TkgQ==
X-Gm-Message-State: ALoCoQk6qyLsCHaPwa8Xg7mggs1ex7V+qMLVm1FkmEEB3Z/mU3CSDVduWCanpxznQ/WZoKKP2AO3kqt0t3lwd46EaSd3AonOby9BW7AkFkCUVS4QhYgrz88joz3gfy9+YQfxc3D4rfzdARZ1+PFnY/kZ+iG4E29Wz1UfvuG4y/X49cUbvk6+xpEktycS/S+ZO6uqQmezW3td
X-Received: by 10.58.207.76 with SMTP id lu12mr3458489vec.30.1385486608585; Tue, 26 Nov 2013 09:23:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Tue, 26 Nov 2013 09:23:08 -0800 (PST)
In-Reply-To: <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 12:23:08 -0500
Message-ID: <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com>
To: Andy Wilson <andrewgwilson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 17:23:31 -0000

On Mon, Nov 25, 2013 at 7:52 PM, Andy Wilson <andrewgwilson@gmail.com> wrote:
> I take it you're aware of
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00

Yes thanks. My one sentence design is obviously very similar. I don't
understand some of the extra logic for the server in Bodo's draft.


Cheers

AGL

From agl@google.com  Tue Nov 26 09:33:09 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B551ADF71 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoNsLtwoQcot for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:33:08 -0800 (PST)
Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ED92C1ADDDA for <tls@ietf.org>; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
Received: by mail-vb0-f45.google.com with SMTP id p14so4071023vbm.18 for <tls@ietf.org>; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CfuWurCdrFzIbNdZSpwDXPIOFbcj2i+HExajY3W59yQ=; b=V3u5ew3Be0pWcVzs0Hg5EZUJDmHwukFAtlu0XZXbTZi5o2lsAh/gYKB6Z/H52l6mAU wkpaaYXhRp7BQG219VCZYDefOYruEDXG/TdIW81LBZEvvOqkii4s1F1fYuqyCNBXw30l iQCkqjVZPAApjsuf4u5SfryIh6u4RKH7LhtfcBG3UM8BfSAg2laCl8NlnnnLtH++iv86 YrF2nS02H7zZOB8cOOIU3gRt87bEkN1pwEr8nTW3vXzLoTePRkvu0XA8ujs3UoKz/gbe W74EI3rmIPt9c1FFKlj74hAy0l4xA3YMCOCaLrFVt5w7y7P53KyLsCP8dPCLLW9o8GiZ jFdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CfuWurCdrFzIbNdZSpwDXPIOFbcj2i+HExajY3W59yQ=; b=C6it6GGn0fVPN5DFpV8xrZAEuCPofHYyNRWfUw2T9+kalyKVtfjqH1bGu3IbIbe/Zm Ya8EksgxAbsxI0zmZ7W0p9DOJY1HXHcceuhkjW0R4uucBFa5EEzVJyLgFeu5Ow92H9HQ DB2WY2qmdjwPtywJ6UxnCpNEkA857TCW2sjFz9WiRX2Vy1aPjoDhpFnJ8G+z3gWESpYl ZfdHyd56NoXMhFEbczuDdsRaawsAc/x/uEOvdU3MXO0f05POGPPqUa7Z1rnBRuHEiNW7 Rv9bmL68gTsGDxW0tBb/+SJ7NJbUBbEh2QLFsYjDOI1XycEoP7RcsGn4vHmHalfszNil zUoA==
X-Gm-Message-State: ALoCoQkRMtFlS1xRjSJvyQQrtOYC/nNHs3JSJl++IlwUSZXpVRwuybcd6Q9sRf4nUGekrOxRx+BwKUPThHFEXQ+kSMimfelsDEt0OGvIoG4rSH9vT5UuvIzHz5jxX1V2c71vbfq27U7CestWjo43KNLalmMZzvvMRFgiiBPY/1+Zby07fbz5DCEirtcRddWcuRhIMj92RpUf
X-Received: by 10.52.245.9 with SMTP id xk9mr27061903vdc.8.1385487187652; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Tue, 26 Nov 2013 09:32:47 -0800 (PST)
In-Reply-To: <op.w64s0vig3dfyax@killashandra.invalid.invalid>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <op.w64s0vig3dfyax@killashandra.invalid.invalid>
From: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 12:32:47 -0500
Message-ID: <CAL9PXLyZvD+p=abPNZ05vX2SBWXNYyD1XaKsr83aKYov08zMsQ@mail.gmail.com>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 17:33:09 -0000

On Mon, Nov 25, 2013 at 7:59 PM, Yngve N. Pettersen <yngve@spec-work.net> wrote:
>  - Are these implementations functioning as proxies or just inspecting the
> encrypted protocol data, without decrypting?

I think that the problems so far have been with full MITM proxies.

>  - Does *any* of these implementations support the Renego patch? If they
> don't, then my suggestion for using the Renego extension support as a proxy
> for version tolerance might still work.

Unfortunately I've no idea. There seem to be more variants of some of
these products than pips in a pomegranate.

>  - Do you know that none of them will not break due to an SCSV? If they are
> breaking due to expectations of what is supposed to be in the handshake,
> some of them they could very well break due to unexpected ciphersuites, as
> well. (while the Renego SCSV seem to have worked well, I don't think it can
> be relied on as a reliable indication as it is only used for SSL v3-only
> hellos, because there are servers that does not tolerate the Renego
> extension in combination with the Renego SCSV.

It is possible that there could be compat issues with an SCSV but, as
far as I know, it's the least likely to have problems.

> A pessimistic guess is that, as per Murhpy's Law, there will be both broken
> Renego patched implementations, and implementations that react to the
> proposed SCSV. As far as the SCSVs are concerned, how do you propose to
> handle those cases?

Tiny amounts of breakage are acceptable if there are some edge cases.
I don't know yet whether the breakage will be tiny and, as ever, it'll
be a bunch of work to find out. But it seems to be the best way
forward.

You report that 0.3% of sites are expected to fail if we use renego as
an anti-fallback signal. That is not a heart warming number and I'd
like to try to break less, if at all possible.


Cheers

AGL

From agl@google.com  Tue Nov 26 09:34:53 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93081AE213 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rX87nolut8l for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:34:53 -0800 (PST)
Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id B8FFE1ADFAD for <tls@ietf.org>; Tue, 26 Nov 2013 09:34:52 -0800 (PST)
Received: by mail-ve0-f169.google.com with SMTP id c14so4439381vea.28 for <tls@ietf.org>; Tue, 26 Nov 2013 09:34:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uQS86rBzXpsLOvl40UjQlXV2SxOCAQsqGXAS8BwR2Ro=; b=UT8jMnxMqEXuOUDHk5RLIpHW+/AHOyrO/PYyRUp6g60Im/SaV7Dixk267SrGun9cW3 Gj+49qdsfDmCWkFLLvKTIX/o9LLESLq5kuh7egDftJSga4ECVGlMuTRCIK4HDMf9hor9 v2CznR5b5vjm4SfD+OV81XX2pOoHJOlpwUqSW0t07KkGA0m3MzTaa53rkJe9XqUWniur 4trFe45X6cIIr07AMiQWkjvKlTMSVkDwgHZHu0GWO9HBQPF5GfAOLmb1iGmZafsehXoA lYy0vMhBk1qy5GkAYMY5zaDUIt0ntrXaMWcdYapaIcvK46q+xxfxGHwxuwSbWKXgKDcw lP2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uQS86rBzXpsLOvl40UjQlXV2SxOCAQsqGXAS8BwR2Ro=; b=ZKBaf03kl3cjgu7rmj0Qxk78DCbzjDk5S2+5QriPeyMILXTMADFi1D1ICMeZaAYByD 0kDrPgUYfU6wVGyji9MglP8CpUF1YfQ18Pf4LD3E+TdSYyHgpwLedxeAXjsY3Utex6Q1 NB7f7jkDjp0deh2scYZSKEusnTzqo7mGyKQ1ecYrLfMKHWgdscGN5gBp+14Hoy+kP79B cwvBqa2KBmFqJCsF12UWWX4zg0yKHnn5evarVfcqp4kq138DZZXt5TmFK7BIH5vKq2ZV ZK8f9WPrxWXQbpHXvmTGO3lgifgO5yB+fD/nnSk9OqfDypAuitBL1kCRfLT2tmrs+6Ck JNkA==
X-Gm-Message-State: ALoCoQl+vlt2AgpQZ6LHmFfwcD4n+7RLhdumqWR4ud3aucjWlH0B4i0L/VMFBJjuL9ZS7ySxEm78oqzSZj7IFqS2TbT9Fvykat7i1nNeMWBpI0cpB/jezAcx6gHk9Uo7sV+VD51IVpQVypqc58/86ybVDHz8z77gO4DNK77KJhrzOlNNspx8IPaU6EKIXs1Jk7S7ZObbFIGX
X-Received: by 10.52.187.138 with SMTP id fs10mr25535084vdc.10.1385487292397;  Tue, 26 Nov 2013 09:34:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Tue, 26 Nov 2013 09:34:32 -0800 (PST)
In-Reply-To: <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
From: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 12:34:32 -0500
Message-ID: <CAL9PXLyqDbOy7vEwNyJD=jwB_UD+QPn6q8a-WCfni3BwxHZT9w@mail.gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 17:34:54 -0000

On Mon, Nov 25, 2013 at 9:19 PM, Martin Rex <mrex@sap.com> wrote:
> If there is a problem in negotiating what _we_want_to_do_, because the
> installed base does not like the kind of negotiation that was originally
> proposed to be used, then the pragmatic engineering approach will be
> to define an alternative negotiation of at least a useful subset
> that will be compatible with the installed base, and which will not need
> to be stripped from a "conservative fallback handshake" -- and therefore
> will be resilient to downgrade attacks, and cope with retarded middle boxes.

Backporting AES-GCM, ECDHE, etc all the way back to SSLv3 is a
possibility if it comes to it. However, it's a lot more work than the
anti-fallback mechanisms currently under consideration so I'd want to
exclude them first.

I know know of a reason to believe that they would have less
compatibility problems than an SCSV.


Cheers

AGL

From agl@google.com  Tue Nov 26 09:39:09 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0E21ADF4F for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:39:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COvF4zQCeFjT for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:39:08 -0800 (PST)
Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 241931ADE85 for <tls@ietf.org>; Tue, 26 Nov 2013 09:39:08 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so4175918veb.4 for <tls@ietf.org>; Tue, 26 Nov 2013 09:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OsG/ujJ6YtB4Zx996wzCvWUoUqIA4wxRkq+4LJ3coIc=; b=FTVEYig+YzgwshsTCIFYdvnF00epb6c+UM5VY/BHyNIRJ1C5ep/+9+xOIFhgLcxOVD 6nxlbMvFq4v9K4TDfePA2g+zkbUpbDFlboA8mHTrbjiOciltdQiZ7uP9E2MsZY0HfK+3 Z0bAE5nTHB3Og6bFv2k0GVpFFSfp9nPxTjqKoRyULJKOwIoz/1mw38uqartGvmqrO/Fi 9fDFIwMnrrPSuhn8kR04eKVKQ+0Dlhz3d0d+bwcYWaoVKn1A4nLYkGiyUHIuXPDL0l8Z WJ5a+jUXO8SDasSt/CdQyUPYau2cj2BYFiX1udvyRnvnwx0AKIam6sSj/wQvaLfXW+it 1WXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=OsG/ujJ6YtB4Zx996wzCvWUoUqIA4wxRkq+4LJ3coIc=; b=YYmbkeSVuyOYld+tao71+04XuiRns4H0y6rmtwpEiGjokhCli34PfzUwy6T6TAjafo /gnFJan2ijA9I+sdl7ZKoW0ExToFdC3zeguQCrkmdYLW8FopB6LTd4hUbc3xuzF61D5a lTk41p9iAlWwTjlEkUy3Q8xtRUMhVt8JmRQfUDVC8A85xDlPl/+qAMvAIH3O3tigs4Rd 4njb1Rl87Zh2EIXIriNGH/ShMK/XWvp5K67RbYwp7dv47UX3zJHddonmZRs+hdgkhRd8 cqCMiZUqfXzuxHXCMtGE01trP8cm/+gPQEJCTPM8AYLsGKdcKNceNet5sD/BS+vo8SR9 VssQ==
X-Gm-Message-State: ALoCoQn9A3OdURsj41cfm89l0aGsPqXEIaCA8z7AgkF+OKAi6lMta1fSt9EhyzHnIEzwSBC0yvxtRI1GYXFO++05QKDNtiZjgJXTh0Gt80qt/h1ybaNpTisMmUn6KhQKs84Gpx0YXAoCEsSGHZB0I7FQ+VqlOxMFAE01Dr9u1H1elOoQotaazQNhyeHyzqZI8ywO1KkzCJil
X-Received: by 10.220.169.203 with SMTP id a11mr6234509vcz.26.1385487547830; Tue, 26 Nov 2013 09:39:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Tue, 26 Nov 2013 09:38:47 -0800 (PST)
In-Reply-To: <CAGZ8ZG2oBwx_Hb3mM59jWx9rZm4zcm4Sv6AdypK4WdciUtG8Bg@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAGZ8ZG2oBwx_Hb3mM59jWx9rZm4zcm4Sv6AdypK4WdciUtG8Bg@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 12:38:47 -0500
Message-ID: <CAL9PXLzB9GjY80S4WrO6J6QC8+S0Qff8sjw71Ssp_ZtL4Fi9Hw@mail.gmail.com>
To: Trevor Perrin <trevp@trevp.net>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 17:39:09 -0000

On Mon, Nov 25, 2013 at 9:33 PM, Trevor Perrin <trevp@trevp.net> wrote:
> Are these MITM products using special root certs installed in the
> browser for MITM purposes?

Yes.

> If so, could the browser simply allow
> SSLv3 fallback only when connecting to a cert under such an installed
> root, while otherwise rejecting such a fallback?

Yes, but I don't believe that would be viable on the Internet as a
whole. There are certainly many HTTPS servers on the Internet that
need fallback in order to function. We would like not to break them
while stopping them dragging everyone's security down. So we still
need some way to identify non-broken servers. At the moment we're
doing that with an "if (is_google)", but that's just an experiment. We
would need an SCSV or the existing renego signal to deploy this
properly in any case, although a root check would fix the current
experiment.


Cheers

AGL

From mrex@sap.com  Tue Nov 26 12:13:03 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775E41ADF93 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQFH6BU8Zzkv for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:13:01 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 185D81ADF2F for <tls@ietf.org>; Tue, 26 Nov 2013 12:13:00 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAQKCwMg010868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Nov 2013 21:12:58 +0100 (MET)
In-Reply-To: <CAL9PXLyqDbOy7vEwNyJD=jwB_UD+QPn6q8a-WCfni3BwxHZT9w@mail.gmail.com>
To: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 21:12:58 +0100 (CET)
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: <20131126201258.CD1E61AAF8@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Tue, 26 Nov 2013 20:13:03 -0000

Adam Langley wrote:
[ Charset UTF-8 unsupported, converting... ]
> On Mon, Nov 25, 2013 at 9:19 PM, Martin Rex <mrex@sap.com> wrote:
> > If there is a problem in negotiating what _we_want_to_do_, because the
> > installed base does not like the kind of negotiation that was originally
> > proposed to be used, then the pragmatic engineering approach will be
> > to define an alternative negotiation of at least a useful subset
> > that will be compatible with the installed base, and which will not need
> > to be stripped from a "conservative fallback handshake" -- and therefore
> > will be resilient to downgrade attacks, and cope with retarded middle boxes.
> 
> Backporting AES-GCM, ECDHE, etc all the way back to SSLv3 is a
> possibility if it comes to it.

Strictly speaking, there is no need to backport anything, if this
was implemented as an alternative fashion to negotiate the use
of TLSv1.2 protocol PDUs&semantics.

ECDHE is already allowed with TLSv1.0 and TLSv1.1, so the only thing that
is missing is permitting AES-GCM (i.e. the GenericAEADCipher PDU)
with TLSv1.0&TLSv1.1 -- which is an extremely trivial and straightforward
change -- half of the work is removing lines of the kind
  "if ( tls_version<TLS_VERSION_12 ) { goto abort_handshake; }"
in the code that implements the TLS record layer.


>
> However, it's a lot more work than the
> anti-fallback mechanisms currently under consideration so I'd want to
> exclude them first.

No, it should be negligible.  For a reasonably structured implementation
of TLSv1.2, it should be less changes than rfc5746 (renego)


> 
> I know know of a reason to believe that they would have less
> compatibility problems than an SCSV.

You're trying to mitigate the risks of reconnect fallbacks in clients,
and perpetuate the reconnect fallbacks, where as the correct fix is to
obviate the reconnect fallbacks.  Making AES-GCM and ECDHE more
backwards-interop friendly will also allow clients that do not
implement reconnect fallbacks, to use these features (=a reasonable
subset of them).


-Martin

From trevp@trevp.net  Tue Nov 26 12:21:13 2013
Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4B61AE010 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mElVN8HKaUl7 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 12:21:11 -0800 (PST)
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6C81ADF38 for <tls@ietf.org>; Tue, 26 Nov 2013 12:21:11 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so5779470wib.14 for <tls@ietf.org>; Tue, 26 Nov 2013 12:21:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FmzDEaAgOsD+nxAOMtPMkWBhIubs8vxcZ8yVKVludio=; b=kSF3q/4QJNekmdbOXsKOYCsIJVGelp7+OEeGMgZ0dwcvMFs1k9a5f4qcMe5mO6O6C3 26rfgGEiM1MXIOWHmsAph7PTuk65RGB5P/foKdvEsDIRPJi9ig3U+mo9FA9OAmXaIYkz THuLdsQ8lUbnhxwHT9DLWd/thsfHAohMLBK5TMyljMJZDtQZCmATH61JTNZ/I2YOHa6i uEh1Q5YG6tjIUYkfMfY7bF4n8Fa67FZV6aorrgh+Eix+bM3t++PzzZv2gDSbGWsUrvHV maQvhIL6kvIiWePMY0XuiLZoRE66vyamTK2rVtjU4t+t0kuK4BT93jrRfSTMx760QRA3 aKgw==
X-Gm-Message-State: ALoCoQluIrgKxH5fLq/QHFxkMoaak/+V/k6ny4170Gajn4awWfRQuDN11IW7FcwQcQa0RLd4RXBs
MIME-Version: 1.0
X-Received: by 10.180.7.136 with SMTP id j8mr19597941wia.17.1385497270622; Tue, 26 Nov 2013 12:21:10 -0800 (PST)
Received: by 10.216.214.134 with HTTP; Tue, 26 Nov 2013 12:21:10 -0800 (PST)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <CAL9PXLzB9GjY80S4WrO6J6QC8+S0Qff8sjw71Ssp_ZtL4Fi9Hw@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAGZ8ZG2oBwx_Hb3mM59jWx9rZm4zcm4Sv6AdypK4WdciUtG8Bg@mail.gmail.com> <CAL9PXLzB9GjY80S4WrO6J6QC8+S0Qff8sjw71Ssp_ZtL4Fi9Hw@mail.gmail.com>
Date: Tue, 26 Nov 2013 12:21:10 -0800
Message-ID: <CAGZ8ZG10rsysnNijZGRZAsh4h06235xWnFwUKOBAStOEYjnYCQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 20:21:13 -0000

On Tue, Nov 26, 2013 at 9:38 AM, Adam Langley <agl@google.com> wrote:
> On Mon, Nov 25, 2013 at 9:33 PM, Trevor Perrin <trevp@trevp.net> wrote:
>> Are these MITM products using special root certs installed in the
>> browser for MITM purposes?
>
> Yes.
>
>> If so, could the browser simply allow
>> SSLv3 fallback only when connecting to a cert under such an installed
>> root, while otherwise rejecting such a fallback?
>
> Yes, but I don't believe that would be viable on the Internet as a
> whole. There are certainly many HTTPS servers on the Internet that
> need fallback in order to function. We would like not to break them
> while stopping them dragging everyone's security down. So we still
> need some way to identify non-broken servers.

Sure, makes sense.

There was an earlier thread about TLS-intolerant middleboxes and the
problem they pose for TLS enhancements which require TLS Extensions
(like CT, TACK, and OCSP "must-staple") [1].

Are your observations actually good news for that case?  If many of
those intolerant middleboxes that were being observed are actually
*MITM* boxes with installed MITM roots, presumably browsers could
detect when they are connecting to such a MITM middlebox, and relax
their requirements around (CT, TACK, OCSP "must-staple", etc.)?


Trevor

[1]
http://www.ietf.org/mail-archive/web/tls/current/msg09450.html
http://www.ietf.org/mail-archive/web/tls/current/msg09468.html

From p.gutmann@auckland.ac.nz  Tue Nov 26 15:21:27 2013
Return-Path: <p.gutmann@auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF97C1AE04A for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 15:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkV7l80Z3H01 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 15:21:23 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 58D5E1AE052 for <tls@ietf.org>; Tue, 26 Nov 2013 15:21:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1385508083; x=1417044083; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=KmGy/0Leyo0yuEfrd5ymS4YJBw7UD6mxDQxeccQXjng=; b=SV14emqAtGaM+l0A9kVdlaqC6krusX7z1ndtGNHslvQwRQ9I57raWY68 X6yZinS510vmbdiICeE+m6xQBFj2e2lnG6bAuM6vRJE6pds1jqZUlzX/G ZuJ9oP82yYAOqwfDheGbVVsBEpBok+qHVgRBCDL8GD0MhwJnN077fZaD2 8=;
X-IronPort-AV: E=Sophos;i="4.93,778,1378814400"; d="scan'208";a="224227773"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Nov 2013 12:21:20 +1300
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.216]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 12:21:19 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: Phillip Hallam-Baker <hallam@gmail.com>, Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Should we support static RSA in TLS 1.3?
Thread-Index: Ac7q/jW+EoVJ3ZD2RM+RRywywwkWPA==
Date: Tue, 26 Nov 2013 23:21:18 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C736541CBEF@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 23:21:28 -0000

Phillip Hallam-Baker <hallam@gmail.com> writes:=0A=
=0A=
>The goal here is not so much forward secrecy as to increase the work facto=
r=0A=
>for an attacker. We have been considering short lived certs as a mechanism=
=0A=
>for addressing the revocation issue for some time. Generating a new cert w=
ith=0A=
>a different key each time does not increase the effort a great deal if it =
is=0A=
>thought about at the start.=0A=
=0A=
There's been an RFC draft for this around pretty much forever, specifically=
:=0A=
=0A=
  Some years ago I proposed a simple extension to X.509 to allow users to=
=0A=
  issue their own encryption certificates which they could renew and roll o=
ver=0A=
  as required. This means that it's no longer necessary to ask a CA for=0A=
  permission to encrypt data, keys can be rolled over regularly at no cost,=
=0A=
  and if a key is compromised it can be quickly replaced. This proposal was=
=0A=
  rejected by the PKIX working group with the comment that "we don't want t=
o=0A=
  turn X.509 into PGP".=0A=
=0A=
  http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt=0A=
=0A=
So it's pretty straightforward to do, the only thing is that it couldn't be=
=0A=
done by the PKIX working group, or whatever undead zombie form it's current=
ly=0A=
continuing as.=0A=
=0A=
Peter.=0A=

From p.gutmann@auckland.ac.nz  Tue Nov 26 15:28:29 2013
Return-Path: <p.gutmann@auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E6F1AE03B for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 15:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLG_TdQtgfgc for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 15:28:28 -0800 (PST)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id EB36E1AE036 for <tls@ietf.org>; Tue, 26 Nov 2013 15:28:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1385508508; x=1417044508; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=TLSSllojOcH5V++zqvMeFVrMcPVWGKUhQHWhP2obmn4=; b=h39IZoBmRkEW7DIu3nTvDaP/g04OXbVf73J7ZAv6Q80Nnds5kuDSCj5X OzW8J+XExzuuCUdfo1aQDzllerL+jHVyo4nKwKYYjcdy6J/Q+XQnIkUaj G+pSguZfVPtJoTBNUVEPjFZ77Mi2d2Tt4XFL6X/ZYZEPT/BIobLwj5GI8 8=;
X-IronPort-AV: E=Sophos;i="4.93,778,1378814400"; d="scan'208";a="224228492"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Nov 2013 12:28:18 +1300
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.216]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 12:28:18 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: Andy Lutomirski <luto@amacapital.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: Ac7q/y/ihw40evCST4Suv+3m/1v4Fg==
Date: Tue, 26 Nov 2013 23:28:18 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 23:28:29 -0000

Andy Lutomirski <luto@amacapital.net> writes:=0A=
=0A=
>- When in client mode, implementations MUST refuse to connect to a server=
=0A=
>unless an explicitly chosen set of trust roots (or other mechanism such as=
=0A=
>DANE) authenticates that server (hello, everything).=0A=
=0A=
Translated: "TLS implementations MUST refuse to connect to any computer or=
=0A=
device that isn't a public web server with a commercial CA-issued=0A=
certificate".  You may as well mandate that "TLS implementations MUST NOT=
=0A=
allow the tide to come in".=0A=
=0A=
(There's a reason why some of the things are the way they are, and you're=
=0A=
unlikely to be able to change them unless you control both sides of the=0A=
infrastructure.  Sometimes you can't even do that, witness Google's ongoing=
=0A=
problems with trying to get Chrome into a secure-by-default mode with Googl=
e's=0A=
own servers).=0A=
=0A=
Peter.=0A=

From luto@amacapital.net  Tue Nov 26 15:52:20 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179651ADF67 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 15:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxakV1C4pBzO for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 15:52:17 -0800 (PST)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 338681ADED7 for <tls@ietf.org>; Tue, 26 Nov 2013 15:52:17 -0800 (PST)
Received: by mail-vc0-f181.google.com with SMTP id ks9so4451423vcb.12 for <tls@ietf.org>; Tue, 26 Nov 2013 15:52:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4DVlQXablU/wvmWuj2q3UASKHh/0j+5VKrsoWsYb0Bg=; b=X184JcBJF9PXRgX807ZGU0GPxe0sagXBCP4lbAhJxy5XBOcm5Alob0r6rCxGw37ej+ WfACX0omqq9SCe16Xe4S+LTojgfkK3cGSzlMlxfzLRXtM6IU0mkb8pYM1qH3WsAr6JBw mTzQgNugDefid1/lc8CBrgCUwjoTxbEYSSOobzoLd2mN92rolbwYavT0bvHP7Gf3kVX9 wBLG76jNCzAEHwFq/jCggl+a3ebHjIFWKLDVifJqIKl2B2xLEmWVP0vYDjLNW0HsdECq dbjLBPSWdu5Se5RID1kz4AWAwSDjwqJsQkVI/gj/ZT+YGN1j931D/fTteJ5cExCyFFCD TsDg==
X-Gm-Message-State: ALoCoQns1C6SYzlOvev6/pxGk5KB/gtSE2A5H1vDMqKp12Slt6Ik8bNHNGvFkHz0odAA0JwvyKHl
X-Received: by 10.58.217.130 with SMTP id oy2mr7455948vec.24.1385509936691; Tue, 26 Nov 2013 15:52:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 26 Nov 2013 15:51:56 -0800 (PST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 26 Nov 2013 15:51:56 -0800
Message-ID: <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Tue, 26 Nov 2013 23:52:20 -0000

On Tue, Nov 26, 2013 at 3:28 PM, Peter Gutmann <p.gutmann@auckland.ac.nz> wrote:
> Andy Lutomirski <luto@amacapital.net> writes:
>
>>- When in client mode, implementations MUST refuse to connect to a server
>>unless an explicitly chosen set of trust roots (or other mechanism such as
>>DANE) authenticates that server (hello, everything).
>
> Translated: "TLS implementations MUST refuse to connect to any computer or
> device that isn't a public web server with a commercial CA-issued
> certificate".  You may as well mandate that "TLS implementations MUST NOT
> allow the tide to come in".

Not at all.  I didn't say "bundled set of trust roots;" I said
"explicitly chosen".  This would ban, for example:

 - stunnel in client mode with verify = 0 or verify = 1
 - OpenSSL's SSL_VERIFY_NONE mode
 - The default behavior of Python's urllib2 module

etc.  If an implementation wanted to offer a scary opt-in way to say
"make me completely insecure", I have no problem with that.  It's
unacceptable, though, that the default behavior of a lot of libraries
is to skip verification.

I personally use TLS with private trust roots -- lots of people do
this.  The problem is when people use TLS with no trust roots at all.

>
> (There's a reason why some of the things are the way they are, and you're
> unlikely to be able to change them unless you control both sides of the
> infrastructure.  Sometimes you can't even do that, witness Google's ongoing
> problems with trying to get Chrome into a secure-by-default mode with Google's
> own servers).

Do you really think that "completely insecure against active attack"
is a good option?

--Andy

From nico@cryptonector.com  Tue Nov 26 17:00:25 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01791AE0DA for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:00:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESk6oDz-Vug9 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:00:25 -0800 (PST)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id EF37F1AE00A for <tls@ietf.org>; Tue, 26 Nov 2013 17:00:24 -0800 (PST)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id D68945405B for <tls@ietf.org>; Tue, 26 Nov 2013 17:00:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4xwkvQhMlEcSznnpEB5S K/Yu8hk=; b=MvLRtcDGJm61WHVr6CBUf9I+RQc9AUl5b4mu/El7BV89PMy90T4J 0/4u/RG2BHZz5zpyokB/ZWqgBf7WS9590BrMeTmQjlADHwjCkNkXkp+Y8ftna0wk XaVO0YFzbli1279S0kq2rYCC2Llvi/dI015gZVyuVY3kxVkR28Moalw=
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 801AE54057 for <tls@ietf.org>; Tue, 26 Nov 2013 17:00:24 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ey16so1347180wid.0 for <tls@ietf.org>; Tue, 26 Nov 2013 17:00:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yZV9OgbhQoR2i89k+icaHsJLT0zBvfwElNP/qbPX2X4=; b=Uroequ1r76fEZEOYLc/X6nf76qARr6YEopgNr9TwHmwwjHtEqdhz7FtQs+osiPLAy7 RIoC3WUv1B/yv+dv2JZ4fz2O1SlRyO/2UUmhnpS8JKmpTcN8stZijNkQKHdvB6d/zWyS KNGk04tJir5TNJ0rUvsZmQZyd05ilg3Muidm6RlTxkiFT6yZBN580K8MkegIK0q/QyAS MJmJnXBMREvMeTr2BjutFZ425OFMxdRNfUMM+Trf4IcNTOtIfcNh5wpXKpa4DsQsZIom +RVM5p+YBrM+tE52sTlAMx5LPnCcuvqDTmlPojA3BVDhTdZhcDFZeEGfXYu+G2jPnEKI 4u1A==
MIME-Version: 1.0
X-Received: by 10.180.76.171 with SMTP id l11mr20435869wiw.13.1385514022742; Tue, 26 Nov 2013 17:00:22 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Tue, 26 Nov 2013 17:00:22 -0800 (PST)
In-Reply-To: <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com>
Date: Tue, 26 Nov 2013 19:00:22 -0600
Message-ID: <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Andy Lutomirski <luto@amacapital.net>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:00:25 -0000

On Tue, Nov 26, 2013 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> Do you really think that "completely insecure against active attack"
> is a good option?

For some things, yes.  Specifically: SMTP.

Nico
--

From luto@amacapital.net  Tue Nov 26 17:05:35 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33081AE0ED for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWVozluVdoEe for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:05:34 -0800 (PST)
Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6335E1AE0EA for <tls@ietf.org>; Tue, 26 Nov 2013 17:05:34 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so4659886veb.15 for <tls@ietf.org>; Tue, 26 Nov 2013 17:05:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PnS5fW3RcfpcgReWdgsuWw2iozdD8BAuXiCZwrbhMSI=; b=ALz63EeMl8+DeCbhLXG0Kqlsf5fxrSk8jof8tgGuIA9PHDwL2CsFIloazzgs9nBpVx GazQQzw2zAdY/xRZlFHe9v9x3iKYWl4HJhoFEY2AKSPSKyIazMGZUmTcb/GpMUM5l1/E 6MjTLAuFjjwDVlft5jaXQ/SNExQ9fOWVFpRRpnVNYG7pDAAqv0WxTRM+4IUkyuJP1Bkh hdlCYR83OG8EAINFpQZKTW+WRH2lrGTrf8qo4LKDauDfIS9D+ojRjVHcOcc777ngljVj CgoucBOBr+tV35TqBHR9edfIsdfyF/85QoDoTUd7iXu6s7DV/4SD+G4av1lepweA1IJD hRbQ==
X-Gm-Message-State: ALoCoQlJqLiAPlygARXS4IhwnKLaq3ZG4RKYruaNGZ7NoKaANJUcvCsGPP7+IqHimkxl3OMLyofD
X-Received: by 10.52.230.35 with SMTP id sv3mr6614221vdc.27.1385514333976; Tue, 26 Nov 2013 17:05:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 26 Nov 2013 17:05:13 -0800 (PST)
In-Reply-To: <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 26 Nov 2013 17:05:13 -0800
Message-ID: <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:05:35 -0000

On Tue, Nov 26, 2013 at 5:00 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 26, 2013 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> Do you really think that "completely insecure against active attack"
>> is a good option?
>
> For some things, yes.  Specifically: SMTP.

Why?

My .msmtprc contains (excerpted):

tls on
tls_starttls on
tls_certcheck on
tls_min_dh_prime_bits 2048
tls_trust_file /etc/ssl/certs/ca-bundle.crt

host smtp.gmail.com

If msmtp were easier to configure, I'd pin Google's CA.  Sadly it's
not, but nonetheless this was *easy* to set up in such a way that my
SMTP is about as secure as HTTPS.

Why on earth is it considered acceptable that the defaults are
insecure?  If it's really okay to connect, *not verify the server
certificate*, and send a password without using a real PAKE algorithm,
then at least the software that does it should not pretend to offer
any form of security.

--Andy

From watsonbladd@gmail.com  Tue Nov 26 17:13:43 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9FA1ADF7F for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVrMLOLFzhlJ for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:13:41 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id E181B1ADEA1 for <tls@ietf.org>; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so6514409wib.14 for <tls@ietf.org>; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
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=05nR7bDgKzzbRK3HIJr09aYLpqXtn2qhJq1cHJATOto=; b=C/eul6o95ZkHJvA9lrLAlHuHmBUBUN00Fa2mslbXx0CnHFNMj/f3x5w6iPEZxjAkes uW6IMrhzNk5abuDMdxo93Yqrsl+54yEm3UQbOEphldSfHvQx2/agQyvhn9ZLZPREzHBg FyBZ3Xmdj8iUz6XdiscjcCKoMBa7gfdCGcUWqD2ZeY/pyNubkU88LSNSG/TevQ2VWvkN +EKfrknttWRRdM4SHb0mqoYyoiwDqSymi7mrexysicS6+FMtEJy9gcdC1w5oxSbxn3a7 iC+ZkuLbhhG9/aGFlEh5pUbaNgTbmP4bDVbZSXkFKRSlR57A6tsVrHLAJ0pi/SaScuzc jOlQ==
MIME-Version: 1.0
X-Received: by 10.194.1.139 with SMTP id 11mr12420913wjm.33.1385514820222; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 26 Nov 2013 17:13:40 -0800 (PST)
In-Reply-To: <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <20131126021923.E56981AAF0@ld9781.wdf.sap.corp>
Date: Tue, 26 Nov 2013 17:13:40 -0800
Message-ID: <CACsn0cksaErqtDZtfvoPEJtZfPRXrUQsp_YH7tiOsbnOizZs5g@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:13:43 -0000

On Mon, Nov 25, 2013 at 6:19 PM, Martin Rex <mrex@sap.com> wrote:
> Adam Langley wrote:
>> Sad as it is, in order to work on public Internet all browsers
>> implement TLS fallback: in the event of a handshake failure they will
>> retry the connection with a lesser SSL/TLS version.
>>
>> This means that an active attacker can disable AES-GCM support and,
>> ultimately, ECDHE if they push the browser back to SSLv3. It would be
>> good to finally do something about this.
>>
>> Thus I'd like to propose the design of an SCSV with which we can move forward:
>>
>>   In the event that a client is making a fallback connection, it
>> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
>> current server which sees this cipher suite in a ClientHello SHOULD
>> return a fatal alert, inappropriate_fallback (86) and abort the
>> connection.
>
>
> We keep this proposals for newly creating interop problems keep
> coming up on this list?
Why didn't you complain before we had the problems?
How does AGL's proposal introduce interop issues?
I agree this is important to avoid in the future, but I don't think
this proposal
causes any more problems.
>
> How about instead fixing the negotiation so that AES-GCM&AES-CCM
> can be sent in whatever ClientHello there is (including SSLv2)
> and an additional SCSV to signal availability of a specific subset of
> ECDHE that can be used without a TLS ECC extension, such as the subset
> that is supported by Windows 7+?
SSLv2.0 is irredeemably broken.
SSLv3.0 doesn't use HMAC, so the decision was made to go to TLS 1.0, rather than
negotiate an extension. It also only supports SHA1 and MD5. The
allowable key exchanges
also changed. Implementing this in a backwards-compatible manner would be hard.
Why the SSL structure was kept around is beyond me: surely someone in
1999 should have
understood the cryptographic issues inherent in the design. (Actually
someone did, namely Rogaway, and everyone ignored him).
But yes, to the extent we can make future changes backwards compatible
we should.
>
>
> If there is a problem in negotiating what _we_want_to_do_, because the
> installed base does not like the kind of negotiation that was originally
> proposed to be used, then the pragmatic engineering approach will be
> to define an alternative negotiation of at least a useful subset
> that will be compatible with the installed base, and which will not need
> to be stripped from a "conservative fallback handshake" -- and therefore
> will be resilient to downgrade attacks, and cope with retarded middle boxes.
>
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From brian@briansmith.org  Tue Nov 26 17:42:59 2013
Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB21ADFF4 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRHdwhJSQOlN for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:42:58 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 609471ADF7F for <tls@ietf.org>; Tue, 26 Nov 2013 17:42:58 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id 1so4620862qec.37 for <tls@ietf.org>; Tue, 26 Nov 2013 17:42:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=odq5HdgzldFXVadNdgVGg83BtzYXLWVxDxipiTpoFGk=; b=nJ9IzyEuTg4DedBOslANp5KBdm3vrDg/j6X+QhHF6lNbUrs9io0MxoEMuarlLTG/Cb uYJ5rges9fx5AG7xZqgzcS7DLHtmGPJExn5S5qLVYX+TvVUUH4+ZQgXUlSFXqBX81vWr aYkSrPLtpuAj5oF+m4I9p795ohQj8cuWKv9bN3UTB7zhXRYmGU+SAH7vRDfaGfWODi3Q Xrc/hVe39X459HjZh3aQm+vu4/67WaRNBhT4kjb9Uz41S9W9A3eex9WmjUpQl/5FCAXg NKociQJImq9hV/4j+VifZcvaE1fBRfPRxPtj+6eJ3Q68BYSXVQ/bChHpSbwkrnbCy+dO HB/Q==
X-Gm-Message-State: ALoCoQmBQf06b9j9YuUJlaZxjZkOhoSf1Zerwq0pTFBxcrtHzQs46jFiXfsmL8CQb+brLnd+ivJi
MIME-Version: 1.0
X-Received: by 10.224.167.193 with SMTP id r1mr9706632qay.30.1385516577881; Tue, 26 Nov 2013 17:42:57 -0800 (PST)
Received: by 10.224.40.11 with HTTP; Tue, 26 Nov 2013 17:42:57 -0800 (PST)
X-Originating-IP: [12.216.141.3]
In-Reply-To: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
Date: Tue, 26 Nov 2013 17:42:57 -0800
Message-ID: <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:42:59 -0000

On Mon, Nov 25, 2013 at 3:27 PM, Adam Langley <agl@google.com> wrote:
>   In the event that a client is making a fallback connection, it
> includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
> current server which sees this cipher suite in a ClientHello SHOULD
> return a fatal alert, inappropriate_fallback (86) and abort the
> connection.

Adam, I think what you propose makes sense. However, I think it might
not be ideal if there are any circumstances where the browser could
accidentally fall back to a lower version--e.g. falling back after a
timeout or falling back in response to the connection being reset.
AFAICT, we currently have to do fallback from TLS 1.2 -> TLS 1.1 and
from TLS 1.1 -> TLS 1.0 in response to connection resets. There will
be some false positives here. In addition to potentially reducing the
security of the connection, these fallback connections add a lot of
latency. If we attempt a fallback connection in response to a
connection reset, and we receive an inappropriate_fallback alert, then
we'd have to make yet *another* connection without the fallback. All
other things being equal, it would be better if the server could
respond respond exactly as it would with a TLS 1.2 ClientHello,
without downgrading the cipher suite or any other feature, more like
what Martin Rex suggested.

However, I don't think it is realistic to backport features all the
way to SSL 3.0. The information in the TLS extensions is too
important, and trying to define good defaults for missing extensions
that make sense long-term seems like it will just bind our hands too
much in the future.

So, we should could consider backporting TLS 1.2 cipher suites to TLS
1.1 and TLS 1.0, but then using your suggested inappropriate_fallback
for for SSL 3.0 handshakes only.

Whether this complication is justified depends on how frequently we
receive false-positive connection resets (and anything else that can
be a false positive) and how much we care about optimizing performance
for that case.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

From nico@cryptonector.com  Tue Nov 26 17:46:06 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDA21AE02A for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BS10XSSmJTtz for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:46:05 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id CA5AD1ADF7F for <tls@ietf.org>; Tue, 26 Nov 2013 17:46:05 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 4EB0E594059 for <tls@ietf.org>; Tue, 26 Nov 2013 17:46:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FAmv1RWs18oxZyn+rwp9 BSGl2e8=; b=YiOeTRTHn27NVcYF9HGvQjXar5IIZnHAH4L1wcbJwRg5mZex0MZy +VtbczL17Lt9ZKYe3wabYt2HOgLB+wzciK4bREmBd5ewURIlb+OL8A8nJ1hlXplG /e6QSGVFWHADXbTVTxKmM6PpaH3fBVHh9Da+Vb8OFy2lPKMLUK2viB8=
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id EC149594058 for <tls@ietf.org>; Tue, 26 Nov 2013 17:46:04 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so493159wes.9 for <tls@ietf.org>; Tue, 26 Nov 2013 17:46:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/DooquxcKR+DlTEU/cQs4eLbPylh1YFfOlP+JAaE9PY=; b=PFHG5ppTBd3lzTAZBWvVvkFZeEyjMeBgOrRSJF2uBKY28dCMFyCpkiBHZ5Lobh75/Y wEgdamMQYmEZ39ybNvGpH7GEPjYycWMcw07uGwc+ka8kY/B9BGlbABCPBH1DK8oBHH9J NePY8sHRZdFmxakEHxOMNSAYmt2UQV80Za8q43mygu43CmcHqPkrYKiBth7RAUdHC9NB mtomxzCHtOWDfo1Shhe426q3y3ppUD60u7AQYke5Z1ejyAYM81MvTfP0x1Ok2Zbb4KmW 7moVG+r0UXvr4qahtceXAVGns47r/laHIGtCs+T6GGZCMEanAFAthBh0qQYDvsF9iOR/ ieig==
MIME-Version: 1.0
X-Received: by 10.180.20.15 with SMTP id j15mr13428246wie.4.1385516762785; Tue, 26 Nov 2013 17:46:02 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Tue, 26 Nov 2013 17:46:02 -0800 (PST)
In-Reply-To: <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com>
Date: Tue, 26 Nov 2013 19:46:02 -0600
Message-ID: <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Andy Lutomirski <luto@amacapital.net>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:46:06 -0000

On Tue, Nov 26, 2013 at 7:05 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Nov 26, 2013 at 5:00 PM, Nico Williams <nico@cryptonector.com> wrote:
>> On Tue, Nov 26, 2013 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> Do you really think that "completely insecure against active attack"
>>> is a good option?
>>
>> For some things, yes.  Specifically: SMTP.
>
> Why?

I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
and MSAs).  With that clarification:

Because it's more important that e-mail flow and be delivered than
that it be hop-by-hop secure.

> My .msmtprc contains (excerpted):

You're talking about mail submission.  This part needs to use TLS
securely, of course, though mostly only because your MSA wants to
authenticate you using a plain username and password authentication
method.

Nico
--

From watsonbladd@gmail.com  Tue Nov 26 17:50:34 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5831AC3DA for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br9kgCBAQxPj for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:50:33 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B00241A8026 for <tls@ietf.org>; Tue, 26 Nov 2013 17:50:32 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id en1so6093026wid.17 for <tls@ietf.org>; Tue, 26 Nov 2013 17:50:31 -0800 (PST)
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=WLEjxXi6bzDeT3AizxF5OkCQoKyrf/ZxxZfXmHOPaLg=; b=AokpfDIXXUfHdmoic39czYQoga2wuNYHvy3LtSrszDLzgm0vWxG+wo4sGYG8FmRqn/ jy2UNOmXzNmAEwvWcO9TGC6UdtWpj+OSJK6Bct9dFbLBB0p46Bz8zc3N0zWUvjx635zo 6dEjSydcX6B0hT5v/hUUBcAKSLQl4+rP+mU7dDJ9RxQ0yZ9vj+aQPr+EPHkYn6PoZHDa +T3cpg3+B9GlmPe3joPv6fo09zpnT7wZ/FFEM9DpCASpP4rfbVVwgsAWJeOCWr1uSrLB gNThRJtXQPxm99X5koVcFXv4JkZOF9+2ep2yaZhT0WtBj3g6TRl7IFbyixm2fuLfRk6H 4sQg==
MIME-Version: 1.0
X-Received: by 10.194.240.41 with SMTP id vx9mr121427wjc.70.1385517031918; Tue, 26 Nov 2013 17:50:31 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 26 Nov 2013 17:50:31 -0800 (PST)
In-Reply-To: <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com>
Date: Tue, 26 Nov 2013 17:50:31 -0800
Message-ID: <CACsn0cm5nAUnUx-P8J=y-fDyaFpgHhUXrCeeW0c1-wH3QmNtNA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=UTF-8
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:50:35 -0000

On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 26, 2013 at 7:05 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Tue, Nov 26, 2013 at 5:00 PM, Nico Williams <nico@cryptonector.com> wrote:
>>> On Tue, Nov 26, 2013 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> Do you really think that "completely insecure against active attack"
>>>> is a good option?
>>>
>>> For some things, yes.  Specifically: SMTP.
>>
>> Why?
>
> I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
> and MSAs).  With that clarification:
>
> Because it's more important that e-mail flow and be delivered than
> that it be hop-by-hop secure.
>
>> My .msmtprc contains (excerpted):
>
> You're talking about mail submission.  This part needs to use TLS
> securely, of course, though mostly only because your MSA wants to
> authenticate you using a plain username and password authentication
> method.
Please explain how any authentication method is any help at all when
working over
an insecure channel. Authentication only makes sense when you can link
the authorized
person to the data over the channel.
>
> Nico
> --
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From luto@amacapital.net  Tue Nov 26 17:51:36 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE61E1ADFC4 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75YKI4DtY-mq for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:51:35 -0800 (PST)
Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB991A8026 for <tls@ietf.org>; Tue, 26 Nov 2013 17:51:35 -0800 (PST)
Received: by mail-vc0-f178.google.com with SMTP id lh4so4350340vcb.23 for <tls@ietf.org>; Tue, 26 Nov 2013 17:51:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CoGI56uLhmkxa+0+CXkJEuqbEMVLDxDL34xv//uh42g=; b=FheDfdcOi0C5R3B5L3EwPRaIlVsscSt7wx+ms0mLpThv0JIOXsBeOgBXKWO5FNMvsK lgJ29raDRIUYBTQ4hIVFMb19UBlQ8AHjsYhhyvA18scldYNQ8lCiY+EpFqwyvmsXqY+q Dn1TM7d6hZJcRQfPIUA5Zd98tYxBJH6kSXko5mKlRT5tpJASjzzI2Mo1scGwGecgi7+8 AHIYTEzsaXz6CRK4S2iyv0ngAdIiv/gzqK1pCM5616ZpenfcNn+Mt2jv3GRdfnvAoiyR MJ0J8JhT3/lT/zC2Gw+PVX7Rht5h+kcKhe/wEMbCWyD/+y+H4MKIoldFwS/5NcMwngsv +MnQ==
X-Gm-Message-State: ALoCoQkzDILqsmT/p443ca3Y9v1h/bw26tSAuvRIhdO/MsSS8pUMNMRxi0U0espVc1vuWpjJLEku
X-Received: by 10.58.117.199 with SMTP id kg7mr150523veb.31.1385517094749; Tue, 26 Nov 2013 17:51:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 26 Nov 2013 17:51:14 -0800 (PST)
In-Reply-To: <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 26 Nov 2013 17:51:14 -0800
Message-ID: <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:51:37 -0000

On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 26, 2013 at 7:05 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Tue, Nov 26, 2013 at 5:00 PM, Nico Williams <nico@cryptonector.com> wrote:
>>> On Tue, Nov 26, 2013 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>>> Do you really think that "completely insecure against active attack"
>>>> is a good option?
>>>
>>> For some things, yes.  Specifically: SMTP.
>>
>> Why?
>
> I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
> and MSAs).  With that clarification:
>
> Because it's more important that e-mail flow and be delivered than
> that it be hop-by-hop secure.

Then let those programs use some kind of hack to turn off
authentication if they really know what they're doing.  (SMTP isn't
hop-by-hop secure, regardless of TLS.)

>
>> My .msmtprc contains (excerpted):
>
> You're talking about mail submission.  This part needs to use TLS
> securely, of course, though mostly only because your MSA wants to
> authenticate you using a plain username and password authentication
> method.

Nearly the entire web works by sending plain usernames and passwords
over TLS, for better or for worse.

--Andy

From nico@cryptonector.com  Tue Nov 26 17:57:19 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7C31ADF7F for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlevXViBUNUU for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 17:57:18 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 696EF1AC3DA for <tls@ietf.org>; Tue, 26 Nov 2013 17:57:18 -0800 (PST)
Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 209032005D906; Tue, 26 Nov 2013 17:57:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yauNrwO/l4HzSJ ES6N1KgkZgnNg=; b=yBduSLpd9vBWvKFHkSc4NObEYpVU4efkiOHMOZQihd56s8 xOZC6/8pvAJL3fxhRwk0jzJYP/2BxE4KKn32nyQyM2EXB8jgYvMM44xrIY6eugp/ w0RQosRxm8PQxG8C6QU26whteICrS56Uad9WivgHf/7b18gKOnZeSF/ODRQ9Y=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id B25DD2005D904; Tue, 26 Nov 2013 17:57:17 -0800 (PST)
Date: Tue, 26 Nov 2013 19:57:17 -0600
From: Nico Williams <nico@cryptonector.com>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20131127015714.GN21240@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com> <CACsn0cm5nAUnUx-P8J=y-fDyaFpgHhUXrCeeW0c1-wH3QmNtNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACsn0cm5nAUnUx-P8J=y-fDyaFpgHhUXrCeeW0c1-wH3QmNtNA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 01:57:19 -0000

On Tue, Nov 26, 2013 at 05:50:31PM -0800, Watson Ladd wrote:
> On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
> > You're talking about mail submission.  This part needs to use TLS
> > securely, of course, though mostly only because your MSA wants to
> > authenticate you using a plain username and password authentication
> > method.
>
> Please explain how any authentication method is any help at all when
> working over an insecure channel. Authentication only makes sense when
> you can link the authorized person to the data over the channel.

Please re-read.

MTAs generally fallback on not using TLS when using TLS fails when
talking to other MTAs.  Clearly it is an improvement over plain TCP to
use TLS in a way that is vulnerable to active attacks, particularly
considering that e-mail by itself has never been secure.

For *submission* (from your mail client to your outgoing mail server)
it's clear that you want TLS with protection against active attackers.

Nico
-- 

From nico@cryptonector.com  Tue Nov 26 18:01:21 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440461AE02A for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVmgO6RMcRu3 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:01:20 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB071AC3DA for <tls@ietf.org>; Tue, 26 Nov 2013 18:01:20 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id E61D4678057; Tue, 26 Nov 2013 18:01:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=KbjNQzmyrmtR+5 0yv0BDjRzRz/o=; b=byUatNkW0WSrIwM4VzkE9JpJxFQFL6bVD81Wulq9GUUw1h K8pCofwqYO00qxqbjUjVhz8VvCbWAdYLeHSWaplMJKfYWumYT/umJP8rKXc2Ci/k ld//sMWlMmlNG8WdqXjR+7AG8iO90J0GwSB84yGpEoLnmYQcOxPEuxrMenGAY=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 92B47678063; Tue, 26 Nov 2013 18:01:19 -0800 (PST)
Date: Tue, 26 Nov 2013 20:01:18 -0600
From: Nico Williams <nico@cryptonector.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20131127020116.GO21240@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com> <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 02:01:21 -0000

On Tue, Nov 26, 2013 at 05:51:14PM -0800, Andy Lutomirski wrote:
> On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
> > I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
> > and MSAs).  With that clarification:
> >
> > Because it's more important that e-mail flow and be delivered than
> > that it be hop-by-hop secure.
> 
> Then let those programs use some kind of hack to turn off
> authentication if they really know what they're doing.  (SMTP isn't
> hop-by-hop secure, regardless of TLS.)

Exactly.  It has to be possible to turn off what you said must not be
possible to turn off.

> Nearly the entire web works by sending plain usernames and passwords
> over TLS, for better or for worse.

I'm aware, as aware as anybody else.  But here we were talking about
your outgoing mail server... that happens to use the same credentials
for mail submission as for all related web services, which is why it's
so critical that for *submission* TLS be used properly.  But for mail
*transfer* (between MTAs) it's generally more critical that mail get
through than that it do so securely.

Nico
-- 

From luto@amacapital.net  Tue Nov 26 18:28:45 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B841AE0DB for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:28:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvmTP0r12_Gc for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 18:28:44 -0800 (PST)
Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2EE1A1F08 for <tls@ietf.org>; Tue, 26 Nov 2013 18:28:44 -0800 (PST)
Received: by mail-vc0-f179.google.com with SMTP id ie18so4374246vcb.38 for <tls@ietf.org>; Tue, 26 Nov 2013 18:28:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nZ7vt5Tvn78pOBLlUM7DTeqWRnItpCFc875ufrcgN3g=; b=MPuof2HFiGoeznQKEa6wTRhKbwqCOK5rmLmQY5UZKUJDm0IPp1iqAm+DXw2swEeoLj 6DeHIOXRucEifxXJMN6CqLk7VqlF0BMzBaJDIRqmqnLk283+Md01ZHiJwI/14zrlW1Rz RtUVCTpKJWJffEK5AB3nKKhiXeD0rP1TrcSaswnSeFWx04OzwrpYmWRxGUtBR1puePs4 inF0+o7Dd2DU1fLsYgLE7uop2vWTzG+uqpcP3+VuJ4kJ1mmoGGB0Dokn+AcrFHarKX3x /Varweh3bP51cMQqyzVqWd4GbaowqteQ7QwRFZa2CEV7ra1FpjfEB/Xj5xMxPNfThUkV JTfg==
X-Gm-Message-State: ALoCoQlZr5btdAbGfoqE+0ii6IBBswUHHvAtwUJQtfS6Q/QlXhbLwN7gb8zXd+cDqhXVBLxbXN8M
X-Received: by 10.52.98.99 with SMTP id eh3mr6292597vdb.29.1385519323832; Tue, 26 Nov 2013 18:28:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Tue, 26 Nov 2013 18:28:23 -0800 (PST)
In-Reply-To: <20131127020116.GO21240@localhost>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <CAK3OfOh05SMBJNQ-Spd-K9kYGQuriagayskOzJmQm27nZfdpow@mail.gmail.com> <CALCETrV-6nQfq_yMU5QSNw4coY3hbziUipE8xwLKn5R_xE6t0w@mail.gmail.com> <CAK3OfOgGtLtwfsPxLAsBE1sMB8gH4BOEfHAocgBK7WVALWnpTQ@mail.gmail.com> <CALCETrXC=MSUYaRb4C1OuFBLHkwfUiftntBpw7sO5ZBGUzvqqA@mail.gmail.com> <20131127020116.GO21240@localhost>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 26 Nov 2013 18:28:23 -0800
Message-ID: <CALCETrVdgQUz1mVG=o7mu9Lz1wTxOKtMJGNniOitP9CkMjpktA@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 02:28:46 -0000

On Tue, Nov 26, 2013 at 6:01 PM, Nico Williams <nico@cryptonector.com> wrote:
> On Tue, Nov 26, 2013 at 05:51:14PM -0800, Andy Lutomirski wrote:
>> On Tue, Nov 26, 2013 at 5:46 PM, Nico Williams <nico@cryptonector.com> wrote:
>> > I'm  talking about SMTP between MTAs, not SUBMIT (SMTP between MUAs
>> > and MSAs).  With that clarification:
>> >
>> > Because it's more important that e-mail flow and be delivered than
>> > that it be hop-by-hop secure.
>>
>> Then let those programs use some kind of hack to turn off
>> authentication if they really know what they're doing.  (SMTP isn't
>> hop-by-hop secure, regardless of TLS.)
>
> Exactly.  It has to be possible to turn off what you said must not be
> possible to turn off.

Then I'll propose a rephrased straw-man version:

When in client mode, implementations MUST refuse to connect to a
server unless an explicitly chosen set of trust roots (or other
mechanism such as DANE) authenticates that server (hello, everything).
 As an exception, an implementation may support an explicit "insecure
mode" in which it is possible to disable peer authentication.

In any case, this is moot unless people think it's actually a good
idea to publish something like this.

--Andy

From synp71@live.com  Tue Nov 26 22:59:13 2013
Return-Path: <synp71@live.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2B21AE115 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 22:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEYoC8poPXHo for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 22:59:11 -0800 (PST)
Received: from blu0-omc1-s33.blu0.hotmail.com (blu0-omc1-s33.blu0.hotmail.com [65.55.116.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFF21AE180 for <tls@ietf.org>; Tue, 26 Nov 2013 22:59:11 -0800 (PST)
Received: from BLU0-SMTP203 ([65.55.116.8]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Nov 2013 22:59:11 -0800
X-TMN: [qAq2gExcsCSU0kxBvLZs972CvzL7yWd8]
X-Originating-Email: [synp71@live.com]
Message-ID: <BLU0-SMTP2032BA7A56EA05E1C2679F7B1EF0@phx.gbl>
Received: from ynir-MBA.local ([80.179.9.115]) by BLU0-SMTP203.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 26 Nov 2013 22:58:07 -0800
Date: Wed, 27 Nov 2013 08:56:55 +0200
From: Yoav Nir <synp71@live.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Andy Lutomirski <luto@amacapital.net>,  Peter Gutmann <p.gutmann@auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com>
In-Reply-To: <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080602060903000707090309"
X-OriginalArrivalTime: 27 Nov 2013 06:59:00.0871 (UTC) FILETIME=[269DF970:01CEEB3E]
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 06:59:13 -0000

--------------ms080602060903000707090309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

On 27/11/13 1:51 AM, Andy Lutomirski wrote:
> On Tue, Nov 26, 2013 at 3:28 PM, Peter Gutmann <p.gutmann@auckland.ac.n=
z> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>
>>> - When in client mode, implementations MUST refuse to connect to a se=
rver
>>> unless an explicitly chosen set of trust roots (or other mechanism su=
ch as
>>> DANE) authenticates that server (hello, everything).
>> Translated: "TLS implementations MUST refuse to connect to any compute=
r or
>> device that isn't a public web server with a commercial CA-issued
>> certificate".  You may as well mandate that "TLS implementations MUST =
NOT
>> allow the tide to come in".
> Not at all.  I didn't say "bundled set of trust roots;" I said
> "explicitly chosen".  This would ban, for example:
>
>   - stunnel in client mode with verify =3D 0 or verify =3D 1
>   - OpenSSL's SSL_VERIFY_NONE mode
>   - The default behavior of Python's urllib2 module
>
> etc.  If an implementation wanted to offer a scary opt-in way to say
> "make me completely insecure", I have no problem with that.  It's
> unacceptable, though, that the default behavior of a lot of libraries
> is to skip verification.
>
> I personally use TLS with private trust roots -- lots of people do
> this.  The problem is when people use TLS with no trust roots at all.
If by "lots" you mean too many to get them all together for beer night=20
-- yes. But the kind of technical know-how is in short supply, and=20
caring about this even among those with technical know-how is also thin=20
on the ground.

I'm sure there are thousands of people who use TLS with private trust=20
roots, as well as thousands of companies. But that's a small portion of=20
people and companies, and the rest of us also need stuff that works.

Yoav



--------------ms080602060903000707090309
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO4zCC
BJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE
BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w
NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC
VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l
dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO
LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN
NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy
lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq
vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6
hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu
9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G
A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/
BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2Ny
bC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEB
BCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QWuZGH
kfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLRzIlf
sXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7LmrmdlMa5
lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg7sJx
ggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCCBRow
ggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT
AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRo
ZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t
MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1h
aWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRp
b24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFAGpDM
J1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq1Gdv
IBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg7SQf
Oq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWSD//g
sWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUswggFH
MB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvGeGNk
J8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAE
CjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3QuY29t
L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYIKwYB
BQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVROQWRk
VHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3Qu
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/avQUn1
G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo2rHA
8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjrP0OD
8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIaXXxH
maWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7qpeeU
0rD+83X5f27nMIIFIDCCBAigAwIBAgIRAJLy3rLPGBD9qh6TW+ZG9DowDQYJKoZIhvcNAQEF
BQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P
RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTMxMTE3
MDAwMDAwWhcNMTQxMTE3MjM1OTU5WjAgMR4wHAYJKoZIhvcNAQkBFg9zeW5wNzFAbGl2ZS5j
b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCow0TXP0M95fIMY0Fsd3xpZj55
m1mkkKhUWLjVtQcd57MyVmBZNQkAmxp9PrzqdHw5eIIBn1EI9foIoynEnUSZzv6pIEXAqdYu
xBH0AdvjoPCzWb9uYrqBtbmxnLh9k9ox1pVJG4hit6WEpK+LZ7uvLj5GUWMdmzghC/+fVEZS
W8U62xlhd8Hq8ded9bfqjM4psDgqUubjcCkMIUnkD9yuXhzfzwF0wwtD66vXrUe8T4/m6XHO
iIqvvVMjzYyKrdLE7zuPyDcDjkxLCCdi2j4c44anq8Pj/yEh5JGU0XSKSfwm2m0UDHj7P/6u
B74JwiAyMtqWzdQBHVOphHKDI0ZTAgMBAAGjggHfMIIB2zAfBgNVHSMEGDAWgBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUq+f5Y55gheJJpWtJDEPf6j2uzhQwDgYDVR0PAQH/
BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUC
MBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsG
AQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI
hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6
Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJl
RW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAaBgNV
HREEEzARgQ9zeW5wNzFAbGl2ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBACRvTZSZMhI7HrJr
jTpnm5FZXyYwJYVhhc643/94hv8pxAQzIY6vH+BlVwmG4Z0Dt6vWYwaUUYdGmvlH0bti8aql
JPe4fUgTxbDlTldhOYfISl3ky9+4CEPg4QvX6tOGIusOrvaIszGUIdvKHzvYM4ZapdTxyFCt
oe1RXq/17ifvIklgmuh+QcB1xNBmE3lBNj+Vy8xLvsAQlqf9ZAIcBNL2yQGCaBcr6XoR24/D
oCNCTAOCR/J2nN/okuGsEF+kvxP/BCPBnDph9coFLNOEwR4ZataT6H4vq0fwGxm5SROTDYis
SUTKc+YYKY2RllEwOxX1NZUSmISuGKrGhr2aCaUxggQcMIIEGAIBATCBqTCBkzELMAkGA1UE
BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEa
MBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0
aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAJLy3rLPGBD9qh6TW+ZG9DowCQYF
Kw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTMxMTI3MDY1NjU1WjAjBgkqhkiG9w0BCQQxFgQUiYWivm9KD+UH4U8fszW+6C020RwwbAYJ
KoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB
ugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN
YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkvLess8YEP2qHpNb5kb0OjCBvAYLKoZIhvcNAQkQAgsxgayggakwgZMxCzAJ
BgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50
IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCS8t6yzxgQ/aoek1vmRvQ6
MA0GCSqGSIb3DQEBAQUABIIBAIJBTZ9PJ3zPPIc+yS2rZaAWnCZ9dT5Nbos89wzHnhumXtcm
Ej76TF4FYwiZ3ktYMaVXM6llwEqjLUNwFONgowkmQdLhibVgzGTC4AnVNUgxhZjXgb6CjFmn
CVuQrcCuiCpggoEYP9pU7g61SlFW572iozzr4DI0vxRFkS51WWDiBYLWyPNEerQ42QhXBRP+
fu7A4r5pjCEdfjYe6C2Fj7KoGuvjh3Pr2Nazp5A2bgKks6/gHZTjVR/xv/9Y3mkMjlMxMele
qIj8asJZRRaGL3mEWEb1jDWIJS1dLfDo/d64Yasass02Jz2NReNIEN8wq5MaxZ1HjUJDtIWe
toUVi2MAAAAAAAA=
--------------ms080602060903000707090309--

From SRS0=e3ap=VE=acm.org=bmoeller@srs.kundenserver.de  Wed Nov 27 03:40:09 2013
Return-Path: <SRS0=e3ap=VE=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B741AE141 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 03:40:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbFw-41zeABU for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 03:40:07 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 760421AE135 for <tls@ietf.org>; Wed, 27 Nov 2013 03:40:07 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MYvSd-1W7rC21IXr-00V80a; Wed, 27 Nov 2013 12:40:05 +0100
Received: by mail-oa0-f44.google.com with SMTP id m1so7527559oag.17 for <tls@ietf.org>; Wed, 27 Nov 2013 03:40:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tUTklapNk9T+zk/NkzLDHFLWtU1QDFeJD1B50upBi9M=; b=F6K+2TxFx7nwo7sXDoHaxCuLnnTAJ36mmRqoQs9gZWaBBQy0dQmCHdyj8Uo4vEByBV 2dLkvgow0D2C6ljdDNrocixGpBV+I4pdLAYO2BKmrsWJmt4k0JBJSv/5lokyd6/1bgkf VIOLUCVbZ7jp+aH+g07LNPFXzkumiRLAp5zv4gmOhLODVsMU+yK4SLJZa9pM2n7CGGNP 4BZPeoZxWW5BrnGES3hGnyGoQP7hqkTMiWtlLT8LpnWKBWav2csOIG0KcNIemi99CNjR lXdqFVmxSOYiZ+gnfsurjIsRVEmyUx+MfXlDdUogy2qDlR5T0LbCXvh2B0u0fOe0faXn NTjw==
MIME-Version: 1.0
X-Received: by 10.60.76.72 with SMTP id i8mr33508637oew.11.1385552404019; Wed, 27 Nov 2013 03:40:04 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Wed, 27 Nov 2013 03:40:03 -0800 (PST)
In-Reply-To: <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com>
Date: Wed, 27 Nov 2013 12:40:03 +0100
Message-ID: <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b33d548dc02c404ec270ec2
X-Provags-ID: V02:K0:8GRzv47Eb6pkXmdU6GQC5XMVqrJ0WS+UgA9N3PpySCD F0vGJuUMKW3NOc42WD5+SDWg/YyoGJyWFCpy/eF0zWvT00h5Jo Y1V53q13aODrEB+z9rldoTqsx5RgbziPHeb1409/c0TwUxu1vS sZMFZaFGhwdckH9VwbQODxurHLEAi3m79VqHuW9DJYzbe+smt1 M7UB39azNaOwy382Q0Q5oOVjUH/PbFAd1MbyFMt4hM9ZpIieNa IJWbXvqJ4Ja9DwuFUFSv1qV3tyCgka8a00FeI2cl8svOLNdhzF nGFCJsd2eLE/hfms9fdPxuVTi9B1fZcN3aTvo20B6JAw3cvsd0 oyP/MSNHMLmk9YBOtRF4hHd7DKVwpUfZhjSIf12VgqTTY+FRVP QjxxFe4gO2xBVQpArbddYXwdhQXp4nHNprYm3nTnqh0iSgW9W7 dc38O
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 11:42:21 -0000

--047d7b33d548dc02c404ec270ec2
Content-Type: text/plain; charset=ISO-8859-1

Adam Langley <agl@google.com>:

> On Mon, Nov 25, 2013 at 7:52 PM, Andy Wilson <andrewgwilson@gmail.com>
> wrote:
>


>  > I take it you're aware of
> > http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00
>

 Yes thanks. My one sentence design is obviously very similar. I don't
> understand some of the extra logic for the server in Bodo's draft.


I think your new proposal corresponds to my original sketch for the SCSV's
semantics ("If you can read this, tear down the connection"), before I
actually wrote that Internet-Draft.

Writing the I-D, I realized that it would be a pity if, in case a need came
up to implement similar fallback strategies when deploying future protocol
versions, you'd have to wait for *another* document to specify *another*
SCSV to be able to prevent new protocol downgrade attacks, such as from TLS
1.3 to TLS 1.2.  Ideally all servers
implementing TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version
tolerant, but obviously tolerance for *future* protocol versions is not a
server feature normally exercised in practice -- so to cope with the "Universal
Rule of Users", we'll have to assume that some servers may be around that
aren't fully version tolerant, while working perfectly as far as said Users
are concerned.  Hence the server logic to compare the client's protocol
version to the server's supported protocol version: if the client is
falling back to the server's highest supported protocol, that's not a
malicious protocol downgrade.

Similarly, implemented in TLS 1.2-intolerant servers,
draft-bmoeller-tls-downgrade-scsv-00 could prevent a rollback from TLS 1.1
to TLS 1.0 without breaking interoperability with clients employing a
fallback strategy (and using the SCSV); in TLS 1.1-intolerant servers, it
could prevent a rollback from TLS 1.0 with TLS extensions to TLS 1.0
without TLS extensions without breaking interoperability.  As you've noted,
if the SCSV is used by widely deployed clients first, we won't have to
worry about interoperability with such servers (because the vendors will
notice that their servers are broken before they get deployed).

So in that case, the special logic for client_hello_extension_list can be
removed from the specification (yay!); only the version comparison needs to
remain.

Bodo



PS: Needless to say ...

1. None of the above is meant to imply that I think of TLS version fallback
as a protocol feature meant to stay.  Rollback connections *are*
an abomination -- the I-D is all about what to do *if* we find ourselves in
the sad situation of having to reconnect for interoperability.  If we
manage to get rid of the need for that, all the better.

2. None of the above is meant to imply that we shouldn't retrofit secure
ciphersuites to older protocol versions.  This, too, seems pretty much
orthogonal to what this I-D is all about.  (A TLS 1.0 client hello
proposing only secure ciphersuites wouldn't need the SCSV.)

--047d7b33d548dc02c404ec270ec2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Adam=
 Langley <span dir=3D"ltr">&lt;<a href=3D"mailto:agl@google.com" target=3D"=
_blank">agl@google.com</a>&gt;:</span><br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:=
rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div>On Mon, Nov 25, 2013 at 7:52 PM, Andy Wilson &lt;<a href=3D"mailto:and=
rewgwilson@gmail.com" target=3D"_blank">andrewgwilson@gmail.com</a>&gt; wro=
te:<br></div></blockquote><div>=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">


<div>
&gt; I take it you&#39;re aware of<br>
&gt; <a href=3D"http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scs=
v-00" target=3D"_blank">http://tools.ietf.org/html/draft-bmoeller-tls-downg=
rade-scsv-00</a></div></blockquote><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div>
</div>Yes thanks. My one sentence design is obviously very similar. I don&#=
39;t<br>
understand some of the extra logic for the server in Bodo&#39;s draft.</blo=
ckquote><div><br></div><div>I think your new proposal corresponds to my ori=
ginal sketch for the SCSV&#39;s semantics (&quot;If you can read this, tear=
 down the connection&quot;), before I actually wrote that Internet-Draft.</=
div>

<div><br></div><div>Writing the I-D, I realized that it would be a pity if,=
 in case a need came up to implement similar fallback strategies when deplo=
ying future protocol versions, you&#39;d have to wait for *another* documen=
t to specify *another* SCSV to be able to prevent new protocol downgrade at=
tacks, such as from TLS 1.3 to TLS 1.2. =A0Ideally all servers implementing=
=A0TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version tolerant, bu=
t obviously tolerance for *future* protocol versions is not a server featur=
e normally exercised in practice -- so to cope with the &quot;<span style=
=3D"font-family:arial,sans-serif;font-size:13px">Universal Rule of Users&qu=
ot;, we&#39;ll have to assume that some servers may be around that aren&#39=
;t fully version tolerant, while working perfectly as far as said Users are=
 concerned. =A0Hence the server logic to compare the client&#39;s protocol =
version to the server&#39;s supported protocol version: if the client is fa=
lling back to the server&#39;s highest supported protocol, that&#39;s not a=
 malicious protocol downgrade.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div>Similarly, implemented in TLS 1.2-intolerant servers, draft-bmo=
eller-tls-downgrade-scsv-00 could prevent a rollback from TLS 1.1 to TLS 1.=
0 without breaking interoperability with clients employing a fallback strat=
egy (and using the SCSV); in TLS 1.1-intolerant servers, it could prevent a=
 rollback from TLS 1.0 with TLS extensions to TLS 1.0 without TLS extension=
s without breaking interoperability. =A0As you&#39;ve noted, if the SCSV is=
 used by widely deployed clients first, we won&#39;t have to worry about in=
teroperability with such servers (because the vendors will notice that thei=
r servers are broken before they get deployed).</div>
<div><br></div><div>So in that case, the special logic for client_hello_ext=
ension_list can be removed from the specification (yay!); only the version =
comparison needs to remain.</div><div><br></div><div>Bodo</div><div><br>
</div><div><br></div><div><br></div><div>PS: Needless to say ...</div><div>=
<br></div><div>1. None of the above is meant to imply that I think of TLS v=
ersion fallback as a protocol feature meant to stay. =A0Rollback connection=
s *are* an=A0abomination -- the I-D is all about what to do *if* we find ou=
rselves in the sad situation of having to reconnect for interoperability. =
=A0If we manage to get rid of the need for that, all the better.</div>
<div><br></div><div>2. None of the above is meant to imply that we shouldn&=
#39;t retrofit secure ciphersuites to older protocol versions. =A0This, too=
, seems pretty much orthogonal to what this I-D is all about. =A0(A TLS 1.0=
 client hello proposing only secure ciphersuites wouldn&#39;t need the SCSV=
.)</div>
<div><br></div>
</div></div></div>

--047d7b33d548dc02c404ec270ec2--

From agl@google.com  Wed Nov 27 07:26:16 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036D91AE076 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4c5Cv4cTwtH for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:26:14 -0800 (PST)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F36A71AE0B3 for <tls@ietf.org>; Wed, 27 Nov 2013 07:25:54 -0800 (PST)
Received: by mail-ve0-f170.google.com with SMTP id oy12so5367827veb.29 for <tls@ietf.org>; Wed, 27 Nov 2013 07:25:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lftnyMcVoQuPPPekpKUcGtqrNyjYUNLX8LD6GFqWPjs=; b=eD9bUbnmtSJBdtYBNEWp9G/b8Ie1ojjZC7rv6AAjarz0I8ZV06irTz6dOGEzV1fjfZ erKW3d/iQwLYRZqIbFuZoSsaTyecxWNiCC6M3rwHFOnDW7Jkm2FxD+sqVoj5+Ym6aJH+ ie9KDrC9nPSxaE2L0Zq/19+Damt7UYwBjx4tAXE+RpUHuPwxC7+lY717+RrqXkpFjf/8 08k3EeqOy8qFeNq7uaHbR07Afh7tNOTU1VigP0m+Ilyin0ndS9OJ53/YWSf68lZAPfHl jTBPhr6RqY19in8Nkdisvn/OW07PpYVUr6c+qGo3Z1zt9notH80x7lfY5Y5h3FLlotrE Cg6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=lftnyMcVoQuPPPekpKUcGtqrNyjYUNLX8LD6GFqWPjs=; b=BdblzqS65gUKQsnOqYxSQX9GAOOAAzMwhQ/MRETw/h8FSFA/7A2oLBuZ0ooKf7c0Hj 0DBUzUNEYPy4QTvaP59IzHTdhwhZfJEGm1kuoTjwBPMf2wY9xMs5nkfRJh2GonFJO0EH ARmdvWuz1rmHZWmxgyruGKEhz6zwEmH+B3CxwdX7O2Ub+OVAIUxmIvJ+PBxRlhyAiN0O GMtMzF0iBk7rvlEg/xvdRtJfGwN/4eiGUhXP1BuKp6wO3SZ7YKVerVzNNdwu7vD+5itx zbin/UTremd5pA5Rv11kNTWlaHNbPahyE3hRu1pVm02hb11YQ0pMwVApVIcyt4i6qc4m IkOw==
X-Gm-Message-State: ALoCoQnCkCi4+Wkh7uXHI4QFalk2JFgeMtZx7e9Rd/jIQPTJyOm/yIt16maKMgaR/fTu4h2B/NRFwtFmJMuxtROGfHg8fVwXy/v+XYOO2sON2fUb4wNkhuycZJQ2I7F9EOwYZj4EMUeI9OMyGnQDA9XOCjoUHXQBn+GxV3iRIooGr3jfqJtcVjF1HkQ+O+LkcI66Xi5Nqsqf
X-Received: by 10.58.246.136 with SMTP id xw8mr390313vec.41.1385565954078; Wed, 27 Nov 2013 07:25:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 27 Nov 2013 07:25:31 -0800 (PST)
In-Reply-To: <CAGZ8ZG10rsysnNijZGRZAsh4h06235xWnFwUKOBAStOEYjnYCQ@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAGZ8ZG2oBwx_Hb3mM59jWx9rZm4zcm4Sv6AdypK4WdciUtG8Bg@mail.gmail.com> <CAL9PXLzB9GjY80S4WrO6J6QC8+S0Qff8sjw71Ssp_ZtL4Fi9Hw@mail.gmail.com> <CAGZ8ZG10rsysnNijZGRZAsh4h06235xWnFwUKOBAStOEYjnYCQ@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Wed, 27 Nov 2013 10:25:31 -0500
Message-ID: <CAL9PXLx3+eRZiR1-iawJ7ZN+heHYFV+yuO6ekn4XA0k25-G+sg@mail.gmail.com>
To: Trevor Perrin <trevp@trevp.net>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 15:26:16 -0000

On Tue, Nov 26, 2013 at 3:21 PM, Trevor Perrin <trevp@trevp.net> wrote:
> There was an earlier thread about TLS-intolerant middleboxes and the
> problem they pose for TLS enhancements which require TLS Extensions
> (like CT, TACK, and OCSP "must-staple") [1].
>
> Are your observations actually good news for that case?  If many of
> those intolerant middleboxes that were being observed are actually
> *MITM* boxes with installed MITM roots, presumably browsers could
> detect when they are connecting to such a MITM middlebox, and relax
> their requirements around (CT, TACK, OCSP "must-staple", etc.)?

We already detect and relax requirements about public key pinning when
a MITM box is detected by a certificate that roots at a user-installed
CA.

The worry has generally always been around "firewall" like devices
that do DPI and "filter" certain TLS versions. They might still be a
problem but MITMs turned out to be so broken that we didn't get as far
as being able to test for them! The SCSV should let us do so.


Cheers

AGL

From agl@google.com  Wed Nov 27 07:28:44 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4D1AE090 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUd2LH9i4AuL for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:28:43 -0800 (PST)
Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1C1AE088 for <tls@ietf.org>; Wed, 27 Nov 2013 07:28:43 -0800 (PST)
Received: by mail-vb0-f43.google.com with SMTP id q12so4907615vbe.2 for <tls@ietf.org>; Wed, 27 Nov 2013 07:28:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7zibGCD3eSToiXYhx9S3wrX1Srp57mzwPh4X6DXeCc0=; b=oRCc/Uvb2auZ79iuTWCojJhcdPbux5S5Y2o0eLC4fy3OhVj62ckM8qK8TSFUthC2FA Vv974b7h2nRqO0T22jJU0ZQcXw3LzpHnWBEGGywOiOr/M1ttIRKVMXYzR8aaLEnAPTIS zCl842uJVksujV+cybiyzi9/qAC3vcqgvXnHx4p4aID7Ora3TuNGc+XbhG7A79ysj97c QWqXDqR81Cy5hJD7Bg8MA2y3tTUgonGK8qNL3REWrQE8/bDVIO0y6aEUPdiQs+zNPQY2 oeSWCzUMyOx1GDE6Ghg0AqXJyGPtqFGmjkbm8fLvH8loakQOi5tJ0Cp4PfieVq22QTM4 2ASg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7zibGCD3eSToiXYhx9S3wrX1Srp57mzwPh4X6DXeCc0=; b=X2v8Lb/9tR/hsRXcNa0J1jrI8zdILENNDFJK9CmC2rQM+5yqWqFx3VbQKfePwK88FM UWCqHf4dAH2HPxI3+dR+dz/poq9PNkn8Q7XGP9AoMeBO+HgKkviJ1QqRGp6v444bd7IN 9Ht+uu8hpeqAvQ6orIstPD7kkeiVCCWm4uBMbAuU6YrLD1mUXpe6ub2kIqbICX5cL1iX DaC6y9C3PB1eEbccp6xPrYhvC1te+ejWdaeFDXxLtQwdiCBcqpjECulRKcKGfXqBTAkH AoRl12xYEH5XLYe+YAZih4g+nRaXmBwOB09rOFcXeZwgEiNjccux6n8Y+EKLMpue/gHl lPSg==
X-Gm-Message-State: ALoCoQnkv6m0TlWCEty9qfwv1tbadTSc+UAmeKeu9qlXgthdKVEA7LNxidq+3sOu6QSaOkRgKa60AnWtReRB3WwDEgcJEvb4k09jngBoUsPv0CdpQQGzwirM9skBEtRPPxTJFEi248JCAVCpyULlLD8GPHbrzovFjGEEJjIwiy6q7wcd0tlUFLM4ks6Gg6otbOA7SCDDJnFB
X-Received: by 10.52.28.78 with SMTP id z14mr81466vdg.54.1385566122614; Wed, 27 Nov 2013 07:28:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 27 Nov 2013 07:28:22 -0800 (PST)
In-Reply-To: <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Wed, 27 Nov 2013 10:28:22 -0500
Message-ID: <CAL9PXLxjFT=QtMj3GNsei=OPJptt=q3M9Ai4arARjE2gfnHMkA@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 15:28:44 -0000

On Tue, Nov 26, 2013 at 8:42 PM, Brian Smith <brian@briansmith.org> wrote:
> these fallback connections add a lot of
> latency. If we attempt a fallback connection in response to a
> connection reset, and we receive an inappropriate_fallback alert, then
> we'd have to make yet *another* connection without the fallback.

I didn't have that in mind. In the code as I currently have it
written, an inappropriate_fallback doesn't trigger an "upgrade".
Rather the original error code that triggered the downgrade is
remembered and returned.

So the connection might go: TLS 1.2, connection reset; fallback to TLS
1.1, inappropriate_fallback; fail the connection with a connection
reset error.

We don't retry HTTP connections, after all.


Cheers

AGL

From dkg@fifthhorseman.net  Wed Nov 27 07:54:28 2013
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA621ACCDC for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfE-HE-wYtCE for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 07:54:22 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 803A31A1F7D for <tls@ietf.org>; Wed, 27 Nov 2013 07:54:14 -0800 (PST)
Received: from fifthhorseman.net (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 98CFBF984 for <tls@ietf.org>; Wed, 27 Nov 2013 10:54:12 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id D206C1FFA0; Wed, 27 Nov 2013 07:54:12 -0800 (PST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: tls@ietf.org
In-Reply-To: <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com>
References: <CACsn0c=i2NX2CZ=Md2X+WM=RM8jAysaenz6oCxmoPt+LC5wvjA@mail.gmail.com> <52874576.9000708@gmx.net> <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com>
User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)
Date: Wed, 27 Nov 2013 10:54:09 -0500
Message-ID: <87txex6dsu.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 15:54:28 -0000

--=-=-=
Content-Type: text/plain

On Wed 2013-11-20 01:24:03 -0500, Andy Lutomirski wrote:
> GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it
> manipulates global state, and it sometimes causes things to
> malfunction after forking.  gnutls_global_init is documented as being
> unsafe if called from multiple threads, which seems silly.

fwiw, p11-kit (which gnutls integrates by default) is designed
specifically to solve the concurrency issue.  So iiuc, the only way to
trigger the concern about gnutls_pkcs11_init above is if you use
something other than p11-kit to handle pkcs11 modules.

> (As an even more off-topic aside, how is there nothing better than
> pkcs11 for interfacing with abstract keys?)

it's a shame, isn't it?  Stef Walter addresses this question too in his
response to the issues with gnutls_pkcs11_init:

http://lists.freedesktop.org/archives/p11-glue/2013-November/000397.html

Regards,

        --dkg

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQJ8BAEBCgBmBQJSlhWhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc+wsP/2WXCAGVxRjwvwFJb56JDK02
fkhru51q0exDdy02Aabmix9KAHawjWi12NrD2vI732R63Vmdrkz3DIav1wW17A03
UyLQ0jVDDG3dojMzNPBkwruPSScHrCXCAJKQYahvRVOlw5vTiGbB32tOF80onLc2
odueuoZquFmz/VjpqNu0FoKexDPD7MzKbGP20ANVe1AprQxVTteFffxTa9Ki4pAR
hRxGuNaM2IK7pNlQck5uvKzPtHa0TgzuXBf15zyc/QGxJswEIzMKgNNQX9fbBQ0E
3DG7XEHDyR5WE1nz3eTey4qhPJyaJ2aPl0paP+sjYpw2ublKbhh3mTQ6gWl2KOr5
mzn6a7qlOVCHuWuruOYQ+Ltw52zSMvgO05QDT4R/xWzY7YbHqxp+kQWp11AOuK/k
JP1hJRWtDDAyQhmXVDjtPbhN42SzkIPfwrDCHauiiKx7X/ofyfFgGapwRuvi45qn
DTgPm5HFX6X49nEZ8fq5vpYim4d0GPcpdbHo899tBvy40gqZtyjk+GQs+53ZssXp
uPQAFewLFV4wyYg5GBMCAfzOrOJNztqSwsJgUJCnlA0VyNRaauGrjjayWkBuJ+va
G22p2fE4idW47ZlgbNEdefxlH7j002+ERIof/BfgmrrCRbMin7dl0oB+tm+r6zHE
xKWUcEGOs3+/HS9ag9ps
=2vy0
-----END PGP SIGNATURE-----
--=-=-=--

From agl@google.com  Wed Nov 27 08:14:03 2013
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078101AE170 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 08:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-46JTzvnAk8 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 08:14:02 -0800 (PST)
Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DA2AD1AE148 for <tls@ietf.org>; Wed, 27 Nov 2013 08:13:50 -0800 (PST)
Received: by mail-vb0-f47.google.com with SMTP id x11so5069711vbb.34 for <tls@ietf.org>; Wed, 27 Nov 2013 08:13:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NZWHT3ZAL0GpFZLO99DimSeWChK5gRbQhVmDKOSOxfI=; b=Q6qDAlhC36Om1Nm5H1AYRKg4C0HHTLjt/tl6Kubh+LE20dX+pQA2KJry6CX0At+GmM SPNDRVWLMat48w53S78epeyh6w+gL+X1vTL4UQ+j7+6f0qtRBnaLG9Ws6G8xhZ6Z1fLO mNIf237SRNgnXSt8pjGj5LvyNvV3TBZqZPHaH+1lNlGforDkUVjttNwYlnU/pN+51I55 BKsgeU7fvCMlTUE1a4OWgtUrD9qKHQ+GGx76FBMg+NWyjBC+Mnxo3uqLQPFJ5KV986uT rEDoySlC87F3W1YmHclFp4v8r6sOS9BXb2OPjwhi3f9TKrIiHX70yKD2GmUgDjTYUQ0l CIHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NZWHT3ZAL0GpFZLO99DimSeWChK5gRbQhVmDKOSOxfI=; b=GVYXSQMXLhlIOLAz4FrpqS0f6whbebyo37zeSxEFUOnAMd3QsGSd/OafzqZiR0jRYD Bp6xEBxDhUuybI/pjEfzsFEp0/MXPQV9gUycNzeQsyCwkvgpEg/vKXJvGWvQ/6qwh4z5 vLNsG07pHAzNCp0SD1tSokHQfKvhkdr7foR8z8caM2EkTndnbIkDn95zeNsYQmMlTWE6 7GyGlthjnSQ8GGupGy6kIrZgm9mCQG9GpASGVmLvDMSrm15v4+rHiYQb16BNsVBQInfd 86EinL5yzugpEeCEQAqPJQ7ksZrLVUvYDvqGRYuGtzH5HEw2wJ1CVlpbfzzMMrP99XWP B4OQ==
X-Gm-Message-State: ALoCoQkRm/TrYcSs2vMcw8q2EwntuiG5Ij2xS74ZO+SqPgd5mChN4VtE7W4nrFXPCd0plhzHcwaxkF/l9ZQz5ruu2ufzM8GvWqFp+DdvfV/kmhIbULdv91Y8YDJfZAZhxpvSzPoPZuy+jslTb2TAMFrHHLOw7MRl+7z9CLgT3jG41o3SbQkkU10z5SkI2L/36VAvmrYOfNP7
X-Received: by 10.221.47.193 with SMTP id ut1mr35033545vcb.8.1385568830220; Wed, 27 Nov 2013 08:13:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Wed, 27 Nov 2013 08:13:30 -0800 (PST)
In-Reply-To: <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com> <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com>
From: Adam Langley <agl@google.com>
Date: Wed, 27 Nov 2013 11:13:30 -0500
Message-ID: <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 16:14:03 -0000

On Wed, Nov 27, 2013 at 6:40 AM, Bodo Moeller <bmoeller@acm.org> wrote:
> Writing the I-D, I realized that it would be a pity if, in case a need came
> up to implement similar fallback strategies when deploying future protocol
> versions, you'd have to wait for *another* document to specify *another*
> SCSV to be able to prevent new protocol downgrade attacks, such as from TLS
> 1.3 to TLS 1.2.  Ideally all servers implementing
> TLS_FALLBACK_SCSV/TLS_DOWNGRADE_SCSV would be fully version tolerant, but
> obviously tolerance for *future* protocol versions is not a server feature
> normally exercised in practice -- so to cope with the "Universal Rule of
> Users", we'll have to assume that some servers may be around that aren't
> fully version tolerant, while working perfectly as far as said Users are
> concerned.  Hence the server logic to compare the client's protocol version
> to the server's supported protocol version: if the client is falling back to
> the server's highest supported protocol, that's not a malicious protocol
> downgrade.

Ah, I understand now, thanks. That's a good point, I'll do that.


Cheers

AGL

From SRS0=e3ap=VE=acm.org=bmoeller@srs.kundenserver.de  Wed Nov 27 09:09:34 2013
Return-Path: <SRS0=e3ap=VE=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A51ADE7C for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 09:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-XdHoVx0D0v for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 09:09:32 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 074FF1A1F7D for <tls@ietf.org>; Wed, 27 Nov 2013 09:09:32 -0800 (PST)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LpUcU-1V6cVb3qac-00fOsH; Wed, 27 Nov 2013 18:09:30 +0100
Received: by mail-ob0-f178.google.com with SMTP id uz6so7645170obc.37 for <tls@ietf.org>; Wed, 27 Nov 2013 09:09:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=f4zbxkDneb/VfmtJ35J1CVpTLYnMUkE9EPsMqZT7ARs=; b=AJI9JoD0F7QtJHmU48ncf3USEDLYmAhSRZa8Gi5+1653u51rG/zLGvE4tSCrncQiox WJigAtvExx5mX3blNTvjZwNdYvSjit6rfjTQlemUBZa4sS5vFwmwd9+wA1aS9C7UTHee 67Jc4om/GJEC76ukAaOpVPOaBL9bgjvjLfk1+WmcTtvI9ZlUBXMI9cJ3Ry3ioFw7lSE/ 4Fyh+mZv1Y1LxnYM5jpHDiT6G9Ce3hKgvGNZchYD8RjgIUvAP8xZlYfttX9woIHaRSIp cxtSEtA19VsY2SMB7pFGta+BqBK6TlXanfwX7g6mXwsyQkiC0GG69OKY7qHWH7BPE0gA Xs1Q==
MIME-Version: 1.0
X-Received: by 10.60.42.168 with SMTP id p8mr1066699oel.73.1385572168544; Wed, 27 Nov 2013 09:09:28 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Wed, 27 Nov 2013 09:09:28 -0800 (PST)
In-Reply-To: <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com>
Date: Wed, 27 Nov 2013 18:09:28 +0100
Message-ID: <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b5d41a6eaba5e04ec2ba842
X-Provags-ID: V02:K0:Z0QypUsLrKH+fvFvWrHVxM2ihuB6Ejk5P0u+XTod4xc 2GBdcu83fESBWiQBvvxvgUhbHDejNgn1UXR0NTbldFNpZBCVsc VfUBaEPVHv1WkhB7wTD9uIJY2o9BpAhKJPSIUz1MsQgCiTNt/g 7AZNtr6l9bBNaDb8OcimhZnc7YZ0ZlFZvGklutM7mcF/WQmsAH 22FhMPKCdoUa4HW0EvLjdXuLjdr4l4JOHCLMkE8wr2qm34v7br yl0JxAuw4VJjK1BHfNrK7JTl2KZrb5S4S8m/YFLLLNKyjgnQVI 4VllKRwu+HphqxX1ZT9QYI9G4AdAdE6FJ1jvQaBcQEhfpnv2lJ damRkj1OP2i+TNW0NIgTDyJ30Gx1pVjcIJC7ToOjDfZxaefeK3 KySCt8lUFCVpr89KJokWG7t+SOvS6V6QPvG1pBEneob+8oRRjl 4xZ+c
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 17:09:34 -0000

--047d7b5d41a6eaba5e04ec2ba842
Content-Type: text/plain; charset=ISO-8859-1

2013/11/19 Bodo Moeller <bmoeller@acm.org>

> 2013/11/8 Douglas Stebila <stebila@qut.edu.au>
>
>> I believe that where possible the IETF should aim to standardize
>> cryptographic protocols that have provable security results.  Such proofs
>> of course don't guarantee the protocol is secure in all scenarios, but at
>> least rule out some classes of attacks.  In the field of password
>> authenticated key exchange, there are many provably secure protocols, and
>> so it would be preferable to see one such protocol adopted.
>
>

> Right.  So there's already an RFC for using SRP in TLS, but it's
> Informational.  Many other such protocols can be found in the research
> literature (and, sometimes, in Internet-Drafts).  If we're picking a
> password-based key exchange for Standards Track, why this one?  What are
> the advantages of this specific protocol over the others?
>
> From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack of
> formal security arguments appears to be that it's presumably less efficient
> than some other such protocols ("hunt-and-peck" loop).
>

Besides the *general* security concerns about this protocol (cursory review
by CFRG doesn't make up for a lack of formal security arguments), here's a
*specific* concern.  (This should be considered "pars pro toto": for all we
know, the protocol could have countless other problems, as isn't uncommon
for cryptographic protocols not justified by format security arguments.)

Given how draft-ietf-tls-pwd-02 specifies negotiation of domain parameters,
I think that a trapdoor-prime attack similar to the one I previously
described for SRP applies (
https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ).
 It makes more sense to standardize domain parameters (allowing a selection
of "named groups").  Full flexibility sounds nice at first, until you
realize that it couldn't only be used by legitimate protocol participants
to select groups that they might deem more secure than whatever is
specified, but could also used by an attacker to select particularly bad
groups (in particular if the scenario doesn't provide for any
authentication other than the password-based authentication the protocol is
meant to provide).

Bodo

--047d7b5d41a6eaba5e04ec2ba842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/11/19 Bodo Moeller <span dir=3D"ltr">&lt;<a href=3D"mailto:bmoeller@acm.or=
g" target=3D"_blank">bmoeller@acm.org</a>&gt;</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir=3D"ltr">2013/11/8 Douglas Stebila <span dir=3D"ltr">&lt;<a href=3D=
"mailto:stebila@qut.edu.au" target=3D"_blank">stebila@qut.edu.au</a>&gt;</s=
pan><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">


I believe that where possible the IETF should aim to standardize cryptograp=
hic protocols that have provable security results. =A0Such proofs of course=
 don&#39;t guarantee the protocol is secure in all scenarios, but at least =
rule out some classes of attacks. =A0In the field of password authenticated=
 key exchange, there are many provably secure protocols, and so it would be=
 preferable to see one such protocol adopted.</blockquote>

</div></div></div></div></blockquote><div>=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr">

<div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Right. =A0So the=
re&#39;s already an RFC for using SRP in TLS, but it&#39;s Informational. =
=A0Many other such protocols can be found in the research literature (and, =
sometimes, in Internet-Drafts). =A0If we&#39;re picking a password-based ke=
y exchange for Standards Track, why this one? =A0What are the advantages of=
 this specific protocol over the others?</div>


<div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px">From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack =
of formal security arguments appears to be that it&#39;s presumably less ef=
ficient than some other such protocols (&quot;hunt-and-peck&quot; loop).</s=
pan></div>

</div></div></div></blockquote><div><br></div><div>Besides the *general* se=
curity concerns about this protocol <font face=3D"arial, sans-serif">(curso=
ry review by CFRG doesn&#39;t make up for a lack of formal security argumen=
ts), here&#39;s a *specific* concern. =A0(This should be considered &quot;p=
ars pro toto&quot;: for all we know, the protocol could have countless othe=
r problems, as isn&#39;t uncommon for cryptographic protocols not justified=
 by format security arguments.)</font></div>

<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Given how=A0draft-ietf-tls-pwd-02 specifies negotiation o=
f domain parameters, I think that a trapdoor-prime attack similar to the on=
e I previously described for SRP applies (<a href=3D"https://groups.google.=
com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ" target=3D"_blank">https=
://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ</a>). =
=A0It makes more sense to standardize domain parameters (allowing a selecti=
on of &quot;named groups&quot;). =A0Full flexibility sounds nice at first, =
until you realize that it couldn&#39;t only be used by legitimate protocol =
participants to select groups that they might deem more secure than whateve=
r is specified, but could also used by an attacker to select particularly b=
ad groups (in particular if the scenario doesn&#39;t provide for any authen=
tication other than the password-based authentication the protocol is meant=
 to provide).</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Bodo</font></div><div><br></div></div></div>
</div>

--047d7b5d41a6eaba5e04ec2ba842--

From luto@amacapital.net  Wed Nov 27 11:56:51 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45DA1ADFA3 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 11:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvCxoruqDN8x for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 11:56:30 -0800 (PST)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id BABE31ADFA7 for <tls@ietf.org>; Wed, 27 Nov 2013 11:55:57 -0800 (PST)
Received: by mail-pd0-f182.google.com with SMTP id v10so10618203pde.27 for <tls@ietf.org>; Wed, 27 Nov 2013 11:55:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o/D5KhgmMvSxcixMPq6QxlLlkP9yFKIQsqoSi3zTcig=; b=BKE4sHXGUMN+ylXjxSbYxTs/t9/legHANHhmbrlZRCRQtdXfY88dfmCxq6lf08Q3/y u4tOknNBXdeqdr0NMV4+6JZ2Y5+MaEiI9AsRYBky8aFkmiEFpl7G7tqdTrGpQxnwSxGB q92owom00zEU28S1RkEuFm6OuNbUMDS9+20JquzTFQ/jP9bvU7OAA5XU2JVN7UBe0T+d ZVuFfW1xzXSn8sPRj97Z8oU7aut2kOke5cC0aJ4L4nNnoqFMTnPPF8/qwaO+QOc8Ponq vZ+CN8QnoANrNG1gIk5upDzkDr6nIs5JhEbyD9A0l4yqHNo1e3LYXE30wOuwBe6thiuD IObA==
X-Gm-Message-State: ALoCoQmeTpAHQJQljXaWI9f8c3Xjs4N87iN0so0jzrOQZ3XG0SrFrPcItghTscaPLhOe3yQ00NnD
X-Received: by 10.68.25.229 with SMTP id f5mr6747941pbg.6.1385582157195; Wed, 27 Nov 2013 11:55:57 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id iu7sm89846651pbc.45.2013.11.27.11.55.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 11:55:56 -0800 (PST)
Message-ID: <52964E4B.5010208@mit.edu>
Date: Wed, 27 Nov 2013 11:55:55 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Yoav Nir <synp71@live.com>, Andy Lutomirski <luto@amacapital.net>,  Peter Gutmann <p.gutmann@auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <BLU0-SMTP2032BA7A56EA05E1C2679F7B1EF0@phx.gbl>
In-Reply-To: <BLU0-SMTP2032BA7A56EA05E1C2679F7B1EF0@phx.gbl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 19:56:51 -0000
X-List-Received-Date: Wed, 27 Nov 2013 19:56:51 -0000

On 11/26/2013 10:56 PM, Yoav Nir wrote:
> On 27/11/13 1:51 AM, Andy Lutomirski wrote:
>> On Tue, Nov 26, 2013 at 3:28 PM, Peter Gutmann
>> <p.gutmann@auckland.ac.nz> wrote:
>>> Andy Lutomirski <luto@amacapital.net> writes:
>>>
>>>> - When in client mode, implementations MUST refuse to connect to a
>>>> server
>>>> unless an explicitly chosen set of trust roots (or other mechanism
>>>> such as
>>>> DANE) authenticates that server (hello, everything).
>>> Translated: "TLS implementations MUST refuse to connect to any
>>> computer or
>>> device that isn't a public web server with a commercial CA-issued
>>> certificate".  You may as well mandate that "TLS implementations MUST
>>> NOT
>>> allow the tide to come in".
>> Not at all.  I didn't say "bundled set of trust roots;" I said
>> "explicitly chosen".  This would ban, for example:
>>
>>   - stunnel in client mode with verify = 0 or verify = 1
>>   - OpenSSL's SSL_VERIFY_NONE mode
>>   - The default behavior of Python's urllib2 module
>>
>> etc.  If an implementation wanted to offer a scary opt-in way to say
>> "make me completely insecure", I have no problem with that.  It's
>> unacceptable, though, that the default behavior of a lot of libraries
>> is to skip verification.
>>
>> I personally use TLS with private trust roots -- lots of people do
>> this.  The problem is when people use TLS with no trust roots at all.
> If by "lots" you mean too many to get them all together for beer night
> -- yes. But the kind of technical know-how is in short supply, and
> caring about this even among those with technical know-how is also thin
> on the ground.
> 
> I'm sure there are thousands of people who use TLS with private trust
> roots, as well as thousands of companies. But that's a small portion of
> people and companies, and the rest of us also need stuff that works.

Do you mean that the rest of us need to write mobile apps that appear to
work but are, in fact, insecure?  I really don't think that TLS is
supposed to serve the purpose of making people feel good about using it
-- it's supposed to provide some form of security.

I think that the rest of us actually need a TLS library that doesn't
suck and an easy and foolproof way to create and use a CA key, CA cert,
and server keypair.

--Andy

From ynir@checkpoint.com  Wed Nov 27 13:22:50 2013
Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4D61ADED9 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 13:22:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1OSpBaHQtU9 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 13:22:48 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD4F1A802B for <tls@ietf.org>; Wed, 27 Nov 2013 13:22:48 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rARLMX6M028959; Wed, 27 Nov 2013 23:22:33 +0200
X-CheckPoint: {52965FE0-1-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 23:22:33 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Andy Lutomirski <luto@amacapital.net>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: Ac7q/y/ihw40evCST4Suv+3m/1v4Fv//5RMAgAB2vYCAANmmgIAAGDWA
Date: Wed, 27 Nov 2013 21:22:32 +0000
Message-ID: <E7D8565E-64D0-443A-AB72-3F0B9F7AA0D5@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <BLU0-SMTP2032BA7A56EA05E1C2679F7B1EF0@phx.gbl> <52964E4B.5010208@mit.edu>
In-Reply-To: <52964E4B.5010208@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.240]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DDF4F3AD334BEA4D87506808AD20C035@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 21:22:50 -0000

On Nov 27, 2013, at 9:55 PM, Andy Lutomirski <luto@amacapital.net>
 wrote:
>>> Not at all.  I didn't say "bundled set of trust roots;" I said
>>> "explicitly chosen".  This would ban, for example:
>>>=20
>>>  - stunnel in client mode with verify =3D 0 or verify =3D 1
>>>  - OpenSSL's SSL_VERIFY_NONE mode
>>>  - The default behavior of Python's urllib2 module
>>>=20
>>> etc.  If an implementation wanted to offer a scary opt-in way to say
>>> "make me completely insecure", I have no problem with that.  It's
>>> unacceptable, though, that the default behavior of a lot of libraries
>>> is to skip verification.
>>>=20
>>> I personally use TLS with private trust roots -- lots of people do
>>> this.  The problem is when people use TLS with no trust roots at all.
>> If by "lots" you mean too many to get them all together for beer night
>> -- yes. But the kind of technical know-how is in short supply, and
>> caring about this even among those with technical know-how is also thin
>> on the ground.
>>=20
>> I'm sure there are thousands of people who use TLS with private trust
>> roots, as well as thousands of companies. But that's a small portion of
>> people and companies, and the rest of us also need stuff that works.
>=20
> Do you mean that the rest of us need to write mobile apps that appear to
> work but are, in fact, insecure? =20

No. Those of us who write mobile apps need the know-how, and can and should=
 get it. And they should be able to configure a common library to be secure=
 according to their needs. That does not mean that this library should not =
have any other modes.
>=20
> I think that the rest of us actually need a TLS library that doesn't
> suck and an easy and foolproof way to create and use a CA key, CA cert,
> and server keypair.

OpenSSL scripts are a Google search away. XCA is free and available for all=
 platforms. The more irritating part is dealing with revocation.

Yoav


From luto@amacapital.net  Wed Nov 27 14:08:58 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E3C1AD937 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 14:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q99Fq5QOS3dm for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 14:08:56 -0800 (PST)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA961AD6A4 for <tls@ietf.org>; Wed, 27 Nov 2013 14:08:56 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz11so5702173veb.32 for <tls@ietf.org>; Wed, 27 Nov 2013 14:08:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FwEMNz9eUS0kpTLhi9U9wcV+Ee92QaSgNFGxDkn/Lyk=; b=mLslgWCcNWEKYprzCHwkLNQUDC/Zokai5+adH99MJLVXmXtHFzL4Fhw6bEo/CDdDsq CWLc6TeP51T7ayZQEfa2h/1NBQL6q39V7RzVLEFpNA/Zh+OdImVXTwluFDqyibSUEfhp eVHOuHsuMWFw03ttGKnjZkzM+W866CVleWj85OsRTAS2xgwVShb7lpY6L4H+wiMSS4Wz iIj/0thLp7+cTP4LM99+pwfO3ldXi8XIIHaVigUEItB6aJ6Piw+yj/ZmJLYekCrpktct 1+RyyvLgtQN1TwOo2LQBQC4OUayyH0RqO8hmddMhu5tJakmRVVM7rAz6t02zYTnfSbw/ n/0Q==
X-Gm-Message-State: ALoCoQnugj7k5czGhbhsL6Z40fZrh7TKGqZvIi7fxDh0OlxijboBiVud30fkxZeAJUwN8kVv9KJb
X-Received: by 10.220.47.10 with SMTP id l10mr1773798vcf.32.1385590135425; Wed, 27 Nov 2013 14:08:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Wed, 27 Nov 2013 14:08:35 -0800 (PST)
In-Reply-To: <E7D8565E-64D0-443A-AB72-3F0B9F7AA0D5@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C736541CBFC@uxcn10-tdc06.UoA.auckland.ac.nz> <CALCETrVeBHqckreYHmaiNONZ8Yj-om5+yQv+ZOfs0Qpj7xXOUA@mail.gmail.com> <BLU0-SMTP2032BA7A56EA05E1C2679F7B1EF0@phx.gbl> <52964E4B.5010208@mit.edu> <E7D8565E-64D0-443A-AB72-3F0B9F7AA0D5@checkpoint.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Wed, 27 Nov 2013 14:08:35 -0800
Message-ID: <CALCETrWkedEubJUujtkua7w6qosSeHagZWf9KeTnKFU65yuKSQ@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 22:08:58 -0000

On Wed, Nov 27, 2013 at 1:22 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> On Nov 27, 2013, at 9:55 PM, Andy Lutomirski <luto@amacapital.net>
>  wrote:
>>>> Not at all.  I didn't say "bundled set of trust roots;" I said
>>>> "explicitly chosen".  This would ban, for example:
>>>>
>>>>  - stunnel in client mode with verify = 0 or verify = 1
>>>>  - OpenSSL's SSL_VERIFY_NONE mode
>>>>  - The default behavior of Python's urllib2 module
>>>>
>>>> etc.  If an implementation wanted to offer a scary opt-in way to say
>>>> "make me completely insecure", I have no problem with that.  It's
>>>> unacceptable, though, that the default behavior of a lot of libraries
>>>> is to skip verification.
>>>>
>>>> I personally use TLS with private trust roots -- lots of people do
>>>> this.  The problem is when people use TLS with no trust roots at all.
>>> If by "lots" you mean too many to get them all together for beer night
>>> -- yes. But the kind of technical know-how is in short supply, and
>>> caring about this even among those with technical know-how is also thin
>>> on the ground.
>>>
>>> I'm sure there are thousands of people who use TLS with private trust
>>> roots, as well as thousands of companies. But that's a small portion of
>>> people and companies, and the rest of us also need stuff that works.
>>
>> Do you mean that the rest of us need to write mobile apps that appear to
>> work but are, in fact, insecure?
>
> No. Those of us who write mobile apps need the know-how, and can and should get it. And they should be able to configure a common library to be secure according to their needs. That does not mean that this library should not have any other modes.

Empirically they don't.

Note that I changed my straw-man language to allow an insecure mode.
But I still think that, in any sane TLS implementation, it must be
crystal clear that, by turning off verification, you are doing
something completely insecure.  Insecure-by-default is crap and should
end.

>>
>> I think that the rest of us actually need a TLS library that doesn't
>> suck and an easy and foolproof way to create and use a CA key, CA cert,
>> and server keypair.
>
> OpenSSL scripts are a Google search away. XCA is free and available for all platforms. The more irritating part is dealing with revocation.

XCA looks decent.  The OpenSSL scripts that are a Google search away
AFAICT mostly suck or are at the very least written by people who
don't know what they're talking about.

--Andy

From dharkins@lounge.org  Wed Nov 27 14:21:09 2013
Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7206D1AE133 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 14:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MbM6DHaBk6F for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 14:21:07 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 513B21ADFE0 for <tls@ietf.org>; Wed, 27 Nov 2013 14:21:07 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8336B10224008; Wed, 27 Nov 2013 14:21:06 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 27 Nov 2013 14:21:06 -0800 (PST)
Message-ID: <e2d8d4a17842e828a3325665a2e5e348.squirrel@www.trepanning.net>
In-Reply-To: <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com>
Date: Wed, 27 Nov 2013 14:21:06 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Bodo Moeller" <bmoeller@acm.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 22:21:09 -0000

  Hi Bodo,

On Wed, November 27, 2013 9:09 am, Bodo Moeller wrote:
> 2013/11/19 Bodo Moeller <bmoeller@acm.org>
>
>> 2013/11/8 Douglas Stebila <stebila@qut.edu.au>
>>
>>> I believe that where possible the IETF should aim to standardize
>>> cryptographic protocols that have provable security results.  Such
>>> proofs
>>> of course don't guarantee the protocol is secure in all scenarios, but
>>> at
>>> least rule out some classes of attacks.  In the field of password
>>> authenticated key exchange, there are many provably secure protocols,
>>> and
>>> so it would be preferable to see one such protocol adopted.
>>
>>
>
>> Right.  So there's already an RFC for using SRP in TLS, but it's
>> Informational.  Many other such protocols can be found in the research
>> literature (and, sometimes, in Internet-Drafts).  If we're picking a
>> password-based key exchange for Standards Track, why this one?  What are
>> the advantages of this specific protocol over the others?
>>
>> From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack of
>> formal security arguments appears to be that it's presumably less
>> efficient
>> than some other such protocols ("hunt-and-peck" loop).
>>
>
> Besides the *general* security concerns about this protocol (cursory
> review
> by CFRG doesn't make up for a lack of formal security arguments), here's a
> *specific* concern.  (This should be considered "pars pro toto": for all
> we
> know, the protocol could have countless other problems, as isn't uncommon
> for cryptographic protocols not justified by format security arguments.)
>
> Given how draft-ietf-tls-pwd-02 specifies negotiation of domain
> parameters,
> I think that a trapdoor-prime attack similar to the one I previously
> described for SRP applies (
> https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ).
>  It makes more sense to standardize domain parameters (allowing a
> selection
> of "named groups").  Full flexibility sounds nice at first, until you
> realize that it couldn't only be used by legitimate protocol participants
> to select groups that they might deem more secure than whatever is
> specified, but could also used by an attacker to select particularly bad
> groups (in particular if the scenario doesn't provide for any
> authentication other than the password-based authentication the protocol
> is meant to provide).

  TLS-pwd does allow for a selection of "named groups". If you look at
the example exchange in appendix A of -02 you'll see that that is how
an elliptic curve is agreed upon (a whole slew of named curves are offered
by the client in the ClientHello and they end up using brainpoolP256r1:
curve_id = 26).

  That said, the issue you bring up remains since it is also possible to
just send the complete domain parameter set. But this is how TLS handles
discrete logarithm-style cryptographic parameter negotiation. So this
issue applies to every TLS cipher suite that provides for some kind of
exchange using discrete logarithm cryptography, including all of the
ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This
"full flexibility" issue sounds more like something for TLSv1.3  than for
TLS-pwd.

  regards,

  Dan.




From SRS0=e3ap=VE=acm.org=bmoeller@srs.kundenserver.de  Wed Nov 27 14:31:42 2013
Return-Path: <SRS0=e3ap=VE=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E291B1AE184 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 14:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEVfU2NOaru0 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 14:31:41 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 98C031ADFD2 for <tls@ietf.org>; Wed, 27 Nov 2013 14:31:41 -0800 (PST)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MHtl3-1VnBkf0etR-003dY1; Wed, 27 Nov 2013 23:31:40 +0100
Received: by mail-ob0-f176.google.com with SMTP id va2so7963400obc.21 for <tls@ietf.org>; Wed, 27 Nov 2013 14:31:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=heVHkk23M6IZ7AHxjLRK+6xpQ0WYpHdKhbVN10p29dY=; b=CiXPfH/H8IB6Bexm30PFMKTnbQUIGG7QKa7sPtR78U6NvdETtxCXWCmEI/lN88vW8x ATcTC7wGo4cTzTjnAShfw3P1Bv769tViiHSHdzBwnowkPkxq86Bj6uMyKeLm6gftTmf7 Xu2ZYcSbzODILND2zdjcLRHhW2hxEzkao6IBslVVbbX6A8l6/ZA1QOTGflShHmx7hWxN LuWIHTij0E8zFVcPaMkUKVA47RWNRgUK+HZ+fgbVV4WZaJZgRoIfP4Dqe2nyepXlZKo7 6ynkRFNeP6O2oBgz/Mq8lb6cmMcFoGhVOvS3gQ4wvH3ws6u5Qgl5YgDLDBOyG9YLH/n+ VI3w==
MIME-Version: 1.0
X-Received: by 10.182.28.134 with SMTP id b6mr36313019obh.27.1385591498908; Wed, 27 Nov 2013 14:31:38 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Wed, 27 Nov 2013 14:31:38 -0800 (PST)
In-Reply-To: <e2d8d4a17842e828a3325665a2e5e348.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com> <e2d8d4a17842e828a3325665a2e5e348.squirrel@www.trepanning.net>
Date: Wed, 27 Nov 2013 23:31:38 +0100
Message-ID: <CADMpkc+ArvpCA5rpqhSGH8WmV3AsPMsL6ZMf0r2-UeHR=jOjug@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2903c18b7a904ec30294d
X-Provags-ID: V02:K0:MWI7KlNjbvgoLj9Lef6CacxshzZC9BHDvYXsZEi3NVz CdnOSPMrPg6JjrRxZvj0dAQ6ZhGplHoew5JBpdMTw5pz/l6iA9 xk0WXe2J0M+1HdgfY71nW7FtUY0V9nawBg0XGBFjyRawvXpjT7 knO9DdBcwdQtbzPQ1ICsu2A+hJnlVvJ6WyrjM7MJuaiQL6TS2C eVazvRu0/fgWU2U3QDuDfhQA/Dctf4/ccpOucKy1lvUsbRzQzM sKixa8OCG6SDkb0c8M5bUWG59LoNfGpYhYYiPWQC4b6RMftMbC pgL/rC4A3VJUS7LOf1IypzYAhRtIzvB4ql0XiXwLHeR6pz9el3 kIGKXj9iO6Tj0OA3Q2EgxxppImmb+J1FPHatZACL2ZoDUH3H53 kGOElJsXaXn1cSOmy6f1+1oA6kqJ8iErmEOda/Rzv21OqG3srn Accl7
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 22:31:43 -0000

--001a11c2903c18b7a904ec30294d
Content-Type: text/plain; charset=ISO-8859-1

Dan Harkins:


>   That said, the issue you bring up remains since it is also possible to
> just send the complete domain parameter set. But this is how TLS handles
> discrete logarithm-style cryptographic parameter negotiation. So this
> issue applies to every TLS cipher suite that provides for some kind of
> exchange using discrete logarithm cryptography, including all of the
> ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This
> "full flexibility" issue sounds more like something for TLSv1.3  than for
> TLS-pwd.
>

While parameter negotiation does look like that for TLS DHE ciphersuites,
that's actually a very different issue, because there these groups are used
differently: either parameters are authenticated (signed by the server's
public key from the server cert) or the server is entirely anonymous.  This
is very different from relying on initially unauthenticated parameters for
a password-authenticated key exchange, where the security issues that I
described come up.

Bodo

--001a11c2903c18b7a904ec30294d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Dan Harkins:</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=A0 That said, the issue you bring up remains since it is also possible to<=
br>
just send the complete domain parameter set. But this is how TLS handles<br=
>
discrete logarithm-style cryptographic parameter negotiation. So this<br>
issue applies to every TLS cipher suite that provides for some kind of<br>
exchange using discrete logarithm cryptography, including all of the<br>
ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This<br>
&quot;full flexibility&quot; issue sounds more like something for TLSv1.3 =
=A0than for<br>
TLS-pwd.<br></blockquote><div><br></div><div>While parameter negotiation do=
es look like that for TLS DHE ciphersuites, that&#39;s actually a very diff=
erent issue, because there these groups are used differently: either parame=
ters are authenticated (signed by the server&#39;s public key from the serv=
er cert) or the server is entirely anonymous. =A0This is very different fro=
m relying on initially unauthenticated parameters for a password-authentica=
ted key exchange, where the security issues that I described come up.</div>
<div><br></div><div>Bodo</div><div><br></div></div><br></div></div>

--001a11c2903c18b7a904ec30294d--

From nico@cryptonector.com  Wed Nov 27 15:54:57 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797161ADFD7 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 15:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwRxVegLEm3L for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 15:54:56 -0800 (PST)
Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 32F281ADF7C for <tls@ietf.org>; Wed, 27 Nov 2013 15:54:56 -0800 (PST)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 9C70BB8058; Wed, 27 Nov 2013 15:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2LsVkCHudUjwLS v4RG9xLytiku8=; b=d7KQgw2NGf0sVtWvCk+8ukYvgXVq9FE/3u0EslvXeAoPT0 anmrtNiTJTBu6XEsABEm0mtrSOtPiB38oV15KJ05dir1iGK2t0XZMFpp9d1JyFr2 Nig4uUz8IP2GfsALLvvFtapf0qNKURevnuj9KrhUySlkgxgIduCpRJT4epaUM=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 37C2EB8057; Wed, 27 Nov 2013 15:54:55 -0800 (PST)
Date: Wed, 27 Nov 2013 17:54:54 -0600
From: Nico Williams <nico@cryptonector.com>
To: Andy Lutomirski <luto@amacapital.net>
Message-ID: <20131127235451.GW21240@localhost>
References: <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Patrick Pelletier <code@funwithsoftware.org>, "tls@ietf.org" <tls@ietf.org>, GnuTLS development list <gnutls-devel@lists.gnutls.org>
Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-BeenThere: tls@ietf.org
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." <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, 27 Nov 2013 23:54:57 -0000

All of this is off-topic for this list.  I'll post a reply anyways, and
I apologize to the list.

On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote:
>                     [...].  gnutls_global_init is documented as being
> unsafe if called from multiple threads, which seems silly.

Initialization is not thread-safe in OpenSSL either.  This is a terrible
thing.  It *can* be made thread-safe, so there's no excuse for it not
being thread-safe.

> GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it
> manipulates global state, and it sometimes causes things to
> malfunction after forking.  [...]

PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs).

Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be
fork-unsafe for at least open sessions/objects on tokens that require
authentication (PIN).  That's because any library using file descriptors
where offset is not a relevant concept will necessarily be fork-unsafe
by default.  And: any stateful cryptography library (e.g., an
implementation of TLS) will tend to be fork-unsafe (imagine a process
trying to use a TLS connection on both sides of a fork()!).

Of course, that's all rather POSIX-specific, but the problem is inherent
to any fork()-like interface.  Use posix_spawn() or similar, then you
won't have to worry about fork-safety at all.  Long ago I used to think
fork+exec superior to spawn since spawn was easy to implement in terms
of fork+exec, but in truth fork() is a dangerous and difficult-to-use
interface -- the only safe things to do on the child side of fork() are:
async-signal-safe things, culminating in _exit() or exec*() ASAP.

> (As an even more off-topic aside, how is there nothing better than
> pkcs11 for interfacing with abstract keys?)

Not really, not portably, not to my knowledge :(  Something better is
badly needed, yes.

In particular we need: a) decent APIs for software crypto (even if it
uses specialized HW under the covers), b) decent APIs for talking to
smartcards (tokens), including softtokens, c) decent APIs for
cryptographic protocols, d) decent APIs for PKIX naming, ...

Nico
-- 

From sneves@dei.uc.pt  Wed Nov 27 20:30:40 2013
Return-Path: <sneves@dei.uc.pt>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7F1AE10A for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 20:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMpztMDdTPR2 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 20:30:37 -0800 (PST)
Received: from smtp2.dei.uc.pt (smtp2.dei.uc.pt [193.137.203.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9D1A1DFA for <tls@ietf.org>; Wed, 27 Nov 2013 20:30:37 -0800 (PST)
Received: from [192.168.1.71] (bl21-79-240.dsl.telepac.pt [2.82.79.240]) (authenticated bits=0) by smtp2.dei.uc.pt (8.14.4/8.14.4) with ESMTP id rAS4UEIT006546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Thu, 28 Nov 2013 04:30:20 GMT
Message-ID: <5296C6D7.2040509@dei.uc.pt>
Date: Thu, 28 Nov 2013 04:30:15 +0000
From: Samuel Neves <sneves@dei.uc.pt>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com> <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com>
In-Reply-To: <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner-ID: rAS4UEIT006546
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00)
X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt
Subject: Re: [TLS] Salsa vs. ChaCha
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 04:30:40 -0000

On 19-11-2013 08:36, Nikos Mavrogiannopoulos wrote:
>
>  This was not our intention (and if there is some text that needs to be
> changed to prevent that, please let us know). Mainly what we want to say
> there, is that we do not want to evaluate any new cipher (we are not
> experts in cipher design). We select what is considered secure from the
> existing cryptographic competitions in order to replace RC4.

Section 7 does seem to focus a lot on the performance aspect of ChaCha.
In reality, ChaCha was designed to improve diffusion, which would
hopefully translate to more security per round. The speed advantages
were (mostly) incidental.

> If we follow the path to chacha, which is not the outcome of a cipher
> competition there can be arguments why not consider some other XXX
> stream cipher as well which could be better than ChaCha in some aspect.
> Such arguments would then be hard to confront.

I certainly understand the rationale of picking a co-winner (along with
Rabbit, HC-128, and SOSEMANUK) of a cryptographic competition. Nobody
ever got fired for that!

A few comments, though:

 - The most successful cryptanalysis performed on Salsa20 also analyzed
ChaCha [1, 2]. In each case, ChaCha withstood attacks with one fewer
round than its predecessor. ChaCha does seem to deliver on its goal of
more diffusion per round.

 - Zooko has mentioned BLAKE and its success against cryptanalysis, but
as noted this does not translate to a useful security reduction. It is
worth pointing out, however, that cryptographers chose to base the core
of their algorithm in the ChaCha quarter-round rather than the Salsa
quarter-round. This suggests equal or more confidence in ChaCha (see
also [4]).

 - There is a concurrent proposal to integrate Chacha20 + Poly1305 as a
TLS AEAD mode [3]. Implementors are unlikely to appreciate the
redundancy in having two separate, but very similar ciphers, in TLS (I
do realize that it makes just as much sense to ask Adam Langley to
change to Salsa20).

Ultimately, whatever variant ends up being chosen, I believe it's the
overwhelming consensus that it beats RC4.

[1] http://eprint.iacr.org/2007/472
[2] http://link.springer.com/chapter/10.1007%2F978-3-642-37682-5_24
[3] http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04#page-14
[4] http://www.ietf.org/mail-archive/web/cfrg/current/msg03491.html

From dharkins@lounge.org  Wed Nov 27 22:49:07 2013
Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368D1AE13F for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 22:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level: 
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBdc_dz7lwjR for <tls@ietfa.amsl.com>; Wed, 27 Nov 2013 22:49:05 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D5F921AE10B for <tls@ietf.org>; Wed, 27 Nov 2013 22:49:05 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B4B4010224008; Wed, 27 Nov 2013 22:49:04 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 27 Nov 2013 22:49:05 -0800 (PST)
Message-ID: <3f9cc03f542291ac17e0d173c09d0177.squirrel@www.trepanning.net>
In-Reply-To: <CADMpkc+ArvpCA5rpqhSGH8WmV3AsPMsL6ZMf0r2-UeHR=jOjug@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com> <e2d8d4a17842e828a3325665a2e5e348.squirrel@www.trepanning.net> <CADMpkc+ArvpCA5rpqhSGH8WmV3AsPMsL6ZMf0r2-UeHR=jOjug@mail.gmail.com>
Date: Wed, 27 Nov 2013 22:49:05 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Bodo Moeller" <bmoeller@acm.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 06:49:07 -0000

On Wed, November 27, 2013 2:31 pm, Bodo Moeller wrote:
> Dan Harkins:
>
>>   That said, the issue you bring up remains since it is also possible to
>> just send the complete domain parameter set. But this is how TLS handles
>> discrete logarithm-style cryptographic parameter negotiation. So this
>> issue applies to every TLS cipher suite that provides for some kind of
>> exchange using discrete logarithm cryptography, including all of the
>> ones with DH in the key exchange-- i.e. DHE, ECDH, ECDHE, etc. This
>> "full flexibility" issue sounds more like something for TLSv1.3  than
>> for
>> TLS-pwd.
>
> While parameter negotiation does look like that for TLS DHE ciphersuites,
> that's actually a very different issue, because there these groups are
> used
> differently: either parameters are authenticated (signed by the server's
> public key from the server cert) or the server is entirely anonymous.
> This
> is very different from relying on initially unauthenticated parameters for
> a password-authenticated key exchange, where the security issues that I
> described come up.

  I'm not sure how using a cipher suite with an anonymous (i.e.
unauthenticated) server is "very different from relying on initially
unauthenticated parameters" since with an unauthenticated server
the parameters will not only be initially unauthenticated but always
unauthenticated.

  Regardless though, what you said was that TLS-pwd was susceptible to
a "trapdoor prime" attack and you provided a link describing it in regards
to TLS-SRP,  and you described it thusly:

"Not all safe primes are created equal -- a malicious server might
compel the client into performing the SRP protocol where N is a
'trapdoor prime', a prime that has been specifically chosen to make
the computation of discrete logarithms feasible."

And that is not possible with TLS-pwd because the client presents the
set of domain parameter sets and the server picks one. The server does
not dictate the acceptable domain parameter set(s) with TLS-pwd. This
sort of attack where a malicious server forces a client into using a
domain parameter set it did not offer is not really possible. And any
man-in-the-middle that mucked with a ClientHello to force the
exchange into some domain parameter set it wants would be detected
when checking the Finished message and the exchange would fail.

  It's interesting that the fix you suggest for this problem-- "The proper
fix is to allow just a certain fixed (standardized) set of parameters" --
is what TLS-pwd already does.

  Dan.




From peter.sylvester@edelweb.fr  Thu Nov 28 00:07:07 2013
Return-Path: <peter.sylvester@edelweb.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945CE1AE165 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 00:07:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C87bdtwFakU8 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 00:07:05 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id B88B81AC7EE for <tls@ietf.org>; Thu, 28 Nov 2013 00:07:04 -0800 (PST)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 564D75E00E; Thu, 28 Nov 2013 09:00:14 +0100 (CET)
Received: from [127.0.0.1] (unknown [192.168.11.68]) by mx1.on-x.com (Postfix) with ESMTP id B8DD35E00D; Thu, 28 Nov 2013 09:00:13 +0100 (CET)
Message-ID: <5296F9A5.9050807@edelweb.fr>
Date: Thu, 28 Nov 2013 09:07:01 +0100
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com>
In-Reply-To: <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------040701040603060708090705"
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 08:07:07 -0000

This is a multi-part message in MIME format.
--------------040701040603060708090705
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 11/27/2013 06:09 PM, Bodo Moeller wrote:
>

> Given how draft-ietf-tls-pwd-02 specifies negotiation of domain parameters, I think that a 
> trapdoor-prime attack similar to the one I previously described for SRP applies 
> (https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ 
> <https://groups.google.com/forum/#%21msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ>).  It makes more
The server's ability to send arbitrary values for negotiation does not mean that the client blindly 
accepts them.

> sense to standardize domain parameters (allowing a selection of "named groups").
In the SRP code of OpenSSL for example, by default, the client accepts only a few groups, the one's 
from the RFC

  "names"  vs  actual values:
- syntactical sugar
- needs or doesn't some form of registration
- requires more or less data to be transmitted
- ...

One possible name for a value is "value", it is understood without any prerequisites, registration,
avoids name clashes.  the price is 500 octets, another "name" would be the hash of the
parameters, since/if they are known in advance.

> Full flexibility sounds nice at first, until you realize that it couldn't only be used by 
> legitimate protocol participants to select groups that they might deem more secure than whatever 
> is specified, but could also used by an attacker to select particularly bad groups (in particular 
> if the scenario doesn't provide for any authentication other than the password-based 
> authentication the protocol is meant to provide).
you wrote in your comment:
"but the adversary, when sitting in for the server, can send Alice the parameters for any 
well-formed group"

  The client can decide what it accepts as "well-formed".

>
> Bodo
Peter
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------040701040603060708090705
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/27/2013 06:09 PM, Bodo Moeller
      wrote:<br>
    </div>
    <blockquote
cite="mid:CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <blockquote
cite="mid:CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Given how&nbsp;draft-ietf-tls-pwd-02 specifies negotiation
              of domain parameters, I think that a trapdoor-prime attack
              similar to the one I previously described for SRP applies
              (<a moz-do-not-send="true"
href="https://groups.google.com/forum/#%21msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ"
                target="_blank">https://groups.google.com/forum/#!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ</a>).
              &nbsp;It makes more </div>
          </div>
        </div>
      </div>
    </blockquote>
    The server's ability to send arbitrary values for negotiation does
    not mean that the client blindly accepts them.<br>
    <br>
    <blockquote
cite="mid:CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>sense to standardize domain parameters (allowing a
              selection of "named groups").&nbsp; <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    In the SRP code of OpenSSL for example, by default, the client
    accepts only a few groups, the one's from the RFC<br>
    <br>
    &nbsp;"names"&nbsp; vs&nbsp; actual values:<br>
    - syntactical sugar<br>
    - needs or doesn't some form of registration <br>
    - requires more or less data to be transmitted<br>
    - ...<br>
    <br>
    One possible name for a value is "value", it is understood without
    any prerequisites, registration,<br>
    avoids name clashes.&nbsp; the price is 500 octets, another "name" would
    be the hash of the<br>
    parameters, since/if they are known in advance.<br>
    <br>
    <blockquote
cite="mid:CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Full flexibility sounds nice at first, until you
              realize that it couldn't only be used by legitimate
              protocol participants to select groups that they might
              deem more secure than whatever is specified, but could
              also used by an attacker to select particularly bad groups
              (in particular if the scenario doesn't provide for any
              authentication other than the password-based
              authentication the protocol is meant to provide).</div>
          </div>
        </div>
      </div>
    </blockquote>
    you wrote in your comment:<br>
    "but the adversary, when sitting in for the server, can send Alice
    the parameters for any well-formed group"<br>
    <br>
    &nbsp;The client can decide what it accepts as "well-formed".<br>
    <br>
    <blockquote
cite="mid:CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Bodo</div>
          </div>
        </div>
      </div>
    </blockquote>
    Peter<br>
    <blockquote
cite="mid:CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
TLS mailing list
<a class="moz-txt-link-abbreviated" href="mailto:TLS@ietf.org">TLS@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/tls">https://www.ietf.org/mailman/listinfo/tls</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------040701040603060708090705--

From nmav@redhat.com  Thu Nov 28 01:10:41 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597491AD84D for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 01:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbt7baxXozOc for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 01:10:39 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E154A1AC49D for <tls@ietf.org>; Thu, 28 Nov 2013 01:10:38 -0800 (PST)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAS9AY1T005518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Nov 2013 04:10:34 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAS9AVNR020653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 04:10:32 -0500
Message-ID: <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Thu, 28 Nov 2013 10:10:30 +0100
In-Reply-To: <20131127235451.GW21240@localhost>
References: <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com> <20131127235451.GW21240@localhost>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: Patrick Pelletier <code@funwithsoftware.org>, GnuTLS development list <gnutls-devel@lists.gnutls.org>, "tls@ietf.org" <tls@ietf.org>, Andy Lutomirski <luto@amacapital.net>
Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 09:10:42 -0000

On Wed, 2013-11-27 at 17:54 -0600, Nico Williams wrote:
> All of this is off-topic for this list.  I'll post a reply anyways, and
> I apologize to the list.
> 
> On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote:
> >                     [...].  gnutls_global_init is documented as being
> > unsafe if called from multiple threads, which seems silly.
> Initialization is not thread-safe in OpenSSL either.  This is a terrible
> thing.  It *can* be made thread-safe, so there's no excuse for it not
> being thread-safe.
Hello,
 I don't understand why this is an issue since it is documented. If a
function (like a global initialization function) is supposed to create
the mutexes for the rest of the library functions it cannot be expected
to be thread safe; at least in a portable way since static
initialization of mutexes is not a portable thing.

Nevertheless, even if you really need to call a global initialization
function in every thread you create (I really don't see why), you can
simply call it in a locked mutex. 

> > GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it
> > manipulates global state, and it sometimes causes things to
> > malfunction after forking.  [...]
> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs).

It requires some reinitialization on every fork. Again if that is
documented it can be made to work. I agree, it is a PITA to handle
though.

regards,
Nikos



From SRS0=uCA0=VF=acm.org=bmoeller@srs.kundenserver.de  Thu Nov 28 01:09:36 2013
Return-Path: <SRS0=uCA0=VF=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E831AD6D1 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 01:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkbX_iVSOHTm for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 01:09:35 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD51AC49D for <tls@ietf.org>; Thu, 28 Nov 2013 01:09:35 -0800 (PST)
Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lzrgx-1VYCJq2rD9-0154Ol; Thu, 28 Nov 2013 10:09:34 +0100
Received: by mail-oa0-f43.google.com with SMTP id i7so8903798oag.30 for <tls@ietf.org>; Thu, 28 Nov 2013 01:09:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/ShS4T3DlbFjjwFUeHCnTjNKth1TCV6+b9JqIKGjouc=; b=jf3iuWwmKSb7Q8eEYn7qAqJqQ6zUx8GPS43XnFLhO2/+Xrx1OJ5NYDQ9rPSMvzOo56 e7uT1RDtx/nmF5sebRtWPmO4scl3lgOuY9cWpLLY5EqBG/I2Lgjkd6IxrJfyvWn/EtyM Q0RkNYpCagOZwERgu0Qy16oBsTJR3TuMQ+n3PfLF8W9FXAB8yUpxooVIp7zsq41wIpOY 3JXs2k59fDoyXNWVPbUdmmuU/FtJPD1PqgE1anKm4ecSxAXcYYbfcYZQLdnKj0A/WGHc GpKLdXJfT652D5qvIUeew8rE+t3wmn6M6RI1cf4cXkNEAKFaKCZQeUn8w6cTjLvXKJB2 Wwjw==
MIME-Version: 1.0
X-Received: by 10.182.16.33 with SMTP id c1mr7015363obd.4.1385629772382; Thu, 28 Nov 2013 01:09:32 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 28 Nov 2013 01:09:32 -0800 (PST)
In-Reply-To: <5296F9A5.9050807@edelweb.fr>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com> <5296F9A5.9050807@edelweb.fr>
Date: Thu, 28 Nov 2013 10:09:32 +0100
Message-ID: <CADMpkcLCm=ONtzu9Wf1tXMr9jeKSeyGEfBXrwU4dO8qzmc+TQg@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=f46d04479f935f8b8f04ec3912c4
X-Provags-ID: V02:K0:lplPP3Uwpyp5G8Ex6SpSapU59TGpuPcuuyq/frrCPa+ 58n4g3lhlHnvlj5LWD/3KlNFaHlxzS1x/31PNU4fM/MXj+y5Rt +kH/PsTjslIoNqlpcY4ccfMl/WR5Q7shW/AJ0azmkrGIlTrl5P f2rGwQdZhprnyzTWIFUjinCiXdk5kYioVN7o25xCDxXvnlvt67 Sd+nADlamLoPd6i2rUEnjFy420h+M6R9qjb133+ke640KDLB9c 6n0toOSWQaqnE/exzWq77ZKYWG/e1HpIWRodUQE045ZMjacUym UMJvtJNGiG858lJHhfbWHRWxav8XZg07viIl3IGXvRiiNYyXE8 7AKcwAk8sYWw0QPhmqjpgnUJdDTUY4s81yfwGLbeOsgyWT/qCr MjA9egTetEM8W9xRQeovqBdHwix4tE1qMkDkQAsRX9XSNAHe7G lDXF4
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 09:16:04 -0000

--f46d04479f935f8b8f04ec3912c4
Content-Type: text/plain; charset=ISO-8859-1

Peter Sylvester <peter.sylvester@edelweb.fr>:

The server's ability to send arbitrary values for negotiation does not mean
> that the client blindly accepts them.


> In the SRP code of OpenSSL for example, by default, the client accepts
> only a few groups, the one's from the RFC
>

That works, of course.  The TLS-SRP RFC says that "Because of the
difficulty of checking for [trapdoor] primes in real time, clients SHOULD
only accept group parameters that come from a trusted source, such as those
listed in Appendix A, or parameters configured locally by a trusted
administrator."  (Language added as of draft-ietf-tls-srp-09, after I'd
presented the attack idea.)

draft-ietf-tls-pwd-02 does not appear to have a similar provision.  If
there are no standardized primes that you can rely on for interoperability,
there's the danger that implementations might do what the specification
appears to suggest, which is to do the same checks they'd be doing to
validate parameters for a DH key exchange.  (This is useful as a sanity
check to prevent certain types of severely broken implementations from
getting deployed, but it is not sufficient to protect against malicious
parties.)

Bodo

--f46d04479f935f8b8f04ec3912c4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">Pete=
r Sylvester <span dir=3D"ltr">&lt;<a href=3D"mailto:peter.sylvester@edelweb=
.fr" target=3D"_blank">peter.sylvester@edelweb.fr</a>&gt;:</span></div><div=
 class=3D"gmail_quote">
<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">The server&#39;s abil=
ity to send arbitrary values for negotiation does
    not mean that the client blindly accepts them.</blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"im"><br></div>
    In the SRP code of OpenSSL for example, by default, the client
    accepts only a few groups, the one&#39;s from the RFC<br></div></blockq=
uote><div><br></div><div>That works, of course. =A0The TLS-SRP RFC says tha=
t &quot;Because of the difficulty of checking for [trapdoor] primes in real=
 time, clients SHOULD only accept group parameters that come from a trusted=
 source, such as those listed in Appendix A, or parameters configured local=
ly by a trusted administrator.&quot; =A0(Language added as of=A0draft-ietf-=
tls-srp-09, after I&#39;d presented the attack idea.)</div>
<div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
3px">draft-ietf-tls-pwd-02 does not appear to have a similar provision. =A0=
If there are no standardized primes that you can rely on for interoperabili=
ty, there&#39;s the danger that implementations might do what the specifica=
tion appears to suggest, which is to do the same checks they&#39;d be doing=
 to validate parameters for=A0</span><font face=3D"arial, sans-serif">a DH =
key exchange. =A0(This is useful as a sanity check to prevent certain types=
 of severely broken implementations from getting deployed, but it is not su=
fficient to protect against malicious parties.)</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Bodo</font></div><div><font face=3D"arial, sans-serif"><b=
r></font></div></div></div></div>

--f46d04479f935f8b8f04ec3912c4--

From SRS0=uCA0=VF=acm.org=bmoeller@srs.kundenserver.de  Thu Nov 28 01:00:07 2013
Return-Path: <SRS0=uCA0=VF=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB0E1ACCFF for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 01:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkK2UYEfGk3b for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 01:00:06 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id E82331AC49D for <tls@ietf.org>; Thu, 28 Nov 2013 01:00:05 -0800 (PST)
Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MIkdY-1VoANY0gDw-002DWK; Thu, 28 Nov 2013 10:00:04 +0100
Received: by mail-oa0-f54.google.com with SMTP id h16so8797792oag.41 for <tls@ietf.org>; Thu, 28 Nov 2013 01:00:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=IJkigmF4QpZv73p7b8ItprBJ9GMpwTPRRukj24t9HAw=; b=ExLWUdoMyYYB1nNn4A4c76UGoPWCsUS+2MWCXa5BrPm7dsm84eGbdFGvU9l9+1D4/c f4g0ZkyCh1+GUXHkzJCxyQSXTBRWUrDl18AtC8nkryBNls0hhOJtRIJPnTjW8VkJ0Zf1 QS70WJBucmdr2MUZKwV5PEKqriiNBCQe+UIaMr+mkcvAfeiojpiEK6Qr+MwG9gwcPzNL zKEGxjKViyR/KcgFCwvU+qGPSqU1raMme4zu0jXQ/nGV4BusnojxfynB2fTE6ZYqbVMw j09gT1ncsPac58DZn3heXYzIXiI2BgdJ8iOlZAkD86NJ/oSVdtKDcVqaVYY4Rpi2WrTw YUBQ==
MIME-Version: 1.0
X-Received: by 10.60.103.106 with SMTP id fv10mr18087460oeb.44.1385629202978;  Thu, 28 Nov 2013 01:00:02 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 28 Nov 2013 01:00:02 -0800 (PST)
In-Reply-To: <3f9cc03f542291ac17e0d173c09d0177.squirrel@www.trepanning.net>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au> <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com> <CADMpkc+YAhDNwTk-6XsnUAscPnb7byStTE09e86L-gYhqn6L9Q@mail.gmail.com> <e2d8d4a17842e828a3325665a2e5e348.squirrel@www.trepanning.net> <CADMpkc+ArvpCA5rpqhSGH8WmV3AsPMsL6ZMf0r2-UeHR=jOjug@mail.gmail.com> <3f9cc03f542291ac17e0d173c09d0177.squirrel@www.trepanning.net>
Date: Thu, 28 Nov 2013 10:00:02 +0100
Message-ID: <CADMpkcLgke+p+vx51BxTPnwMzxQmJR9wv9WgF1SKRR8C_zRPWw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e012277b46f1e6d04ec38f01b
X-Provags-ID: V02:K0:i2/d2rYbwF4A1JWEG5ynepxNT42uWHxmvBf6abQfENC PKizeqGYNSOnO/LRD2mn7wHv77sQyR8a2ZMNyUZDtnysaR/Ato DvhSEnhnYhF6FEt2u5p5RnpSLs1H6e9l7CBOduu694PlYDD7Ar KINiCloQjfLnaOqRFmABrNnZ4ZNlN3djOKtZIdriL0PauuHMz5 7uKSjkrD1Vao6Cw1Mr8RMngQi84TjdIaJPC7eD5iEY2cRDrdv8 Nql3gyPJpzQw6ennLqORFjkb+eXl5gzzM0PL8kU0pXdvm/wKZk ZRNNuda8dF1UV6tSZDP10WRoXQUey/kHjZ7WrPZreHExHlFiwJ ETbgHZ0iZH04aXMNmaSFxgkEOdo1LGz7rfQqAEiorbn+0+tRzy OK+rwhnqCBlV0F8CJ1yD3gIJDXWOY7vnPxkwx9mQvHtnfRNCOp Q0SAf
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 09:16:12 -0000

--089e012277b46f1e6d04ec38f01b
Content-Type: text/plain; charset=ISO-8859-1

2013/11/28 Dan Harkins <dharkins@lounge.org>

  I'm not sure how using a cipher suite with an anonymous (i.e.
> unauthenticated) server is "very different from relying on initially
> unauthenticated parameters" since with an unauthenticated server
> the parameters will not only be initially unauthenticated but always
> unauthenticated.
>

Right; in that case you have no hopes of defending against an active
adversay anyway.



> And that is not possible with TLS-pwd because the client presents the
> set of domain parameter sets and the server picks one.


What I got from draft-ietf-tls-pwd-02 is that (in the non-EC case) the
server proposes a group in ServerFFPWDParams in the ServerKeyExchange
message, and "Upon receipt of the ServerKeyExchange, the client decides
whether to support the indicated group or not."  Before the server chooses
the group for the ServerKeyExchange, all the client sends is the
ClientHello, which does not seem to allow the client to present a set of
domain parameters.  I may have missed something.

In any case, if the client presents the domain parameters and the server
accepts or rejects, we should have a similar attack the other way around.



  It's interesting that the fix you suggest for this problem-- "The proper
> fix is to allow just a certain fixed (standardized) set of parameters" --
> is what TLS-pwd already does.
>

It doesn't seem that FFC primes are standardized in draft-ietf-tls-pwd-02.
 Am I missing something?

Bodo

--089e012277b46f1e6d04ec38f01b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/11/28 Dan Harkins <span dir=3D"ltr">&lt;<a href=3D"mailto:dharkins@lounge.=
org" target=3D"_blank">dharkins@lounge.org</a>&gt;</span></div><div class=
=3D"gmail_quote">
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:sol=
id;padding-left:1ex">=A0 I&#39;m not sure how using a cipher suite with an =
anonymous (i.e.<br>

unauthenticated) server is &quot;very different from relying on initially<b=
r>
unauthenticated parameters&quot; since with an unauthenticated server<br>
the parameters will not only be initially unauthenticated but always<br>
unauthenticated.<br></blockquote><div><br></div><div>Right; in that case yo=
u have no hopes of defending against an active adversay anyway.</div><div><=
br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">

And that is not possible with TLS-pwd because the client presents the<br>
set of domain parameter sets and the server picks one.</blockquote><div><br=
></div><div>What I got from=A0draft-ietf-tls-pwd-02 is that (in the non-EC =
case) the server proposes a group in ServerFFPWDParams in the ServerKeyExch=
ange message, and &quot;Upon receipt of the ServerKeyExchange, the client d=
ecides whether to support the indicated group or not.&quot; =A0Before the s=
erver chooses the group for the ServerKeyExchange, all the client sends is =
the ClientHello, which does not seem to allow the client to present a set o=
f domain parameters. =A0I may have missed something.</div>
<div><br></div><div>In any case, if the client presents the domain paramete=
rs and the server accepts or rejects, we should have a similar attack the o=
ther way around.</div><div><br></div><div><br></div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">

=A0 It&#39;s interesting that the fix you suggest for this problem-- &quot;=
The proper<br>
fix is to allow just a certain fixed (standardized) set of parameters&quot;=
 --<br>
is what TLS-pwd already does.<br></blockquote><div><br></div><div>It doesn&=
#39;t seem that FFC primes are standardized in draft-ietf-tls-pwd-02. =A0Am=
 I missing something?</div><div><br></div><div>Bodo</div><div><br></div>
</div></div></div>

--089e012277b46f1e6d04ec38f01b--

From skyper@thc.org  Thu Nov 28 03:06:05 2013
Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E7F1ADFDB for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 03:06:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEMd-tziCJfC for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 03:06:03 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB41AE008 for <tls@ietf.org>; Thu, 28 Nov 2013 03:06:03 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id at1so13701299iec.21 for <tls@ietf.org>; Thu, 28 Nov 2013 03:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=rs6K940J1pbWEY6UuXDryWxvpq1DtKavbPco1spryco=; b=cEyGDIbOM2ca8/0Urjf0kO52SswYSZ3nWb05Jqpqjq3k7Ep8swMzCHV9pu41wHFSY7 iQYTwyv4Bng0YZfh5762WzyIoimADUV+TZuEXhnm2OGFtfPyMqvAN2rgcvxqePbegSUF xI3tOlphi01g5UqjEvAjraGLvDGEEEOqh6Hfc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=rs6K940J1pbWEY6UuXDryWxvpq1DtKavbPco1spryco=; b=JNDfQcopbbdS8v7X3CICZ5W2AOan9/VXMuC/kHOsBxFgQV+4aCkQRdn10wmqSRRbyq LBV0oLFy9CCauU79NAIGszoRt8WrvVequZ9ZqLzv6AlaYkf3BALjNL1l9uh7tGUSAGCJ ufoELoi5rQO0jfrYaf7HIv6W3PyPg0PfRDvKcCl+nbDLXO0J2bbP6MNzTSwE4BOECtVb ECGW5ZTGRsEV5KIazPVPbauUdpPHqKqlXCnO4FW8A/PqsiBuGCYOsI2p4NUZsXArHGyB XtAheEJX2nPLNPFtP6dBCuSbD+Tpa73ke3v4GKs3cmSS9fCjyIoxlXCECM9Qibhg25Nw dkFg==
X-Gm-Message-State: ALoCoQk+UZsK2B3RfkNhce3oTS0W9Rt7ZptwUnfEwOujlelL2PQw/wCe6IcGKp6sw4IoAAEu4SEL
MIME-Version: 1.0
X-Received: by 10.50.73.130 with SMTP id l2mr1647613igv.36.1385636762522; Thu, 28 Nov 2013 03:06:02 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Thu, 28 Nov 2013 03:06:02 -0800 (PST)
X-Originating-IP: [217.39.7.252]
In-Reply-To: <bf15ecb1612347f9ad4d2f58c4ac3195@BY2PR03MB074.namprd03.prod.outlook.com>
References: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com> <20131112214115.9095A1AA81@ld9781.wdf.sap.corp> <CA+BZK2pT8wJyLLV1K4B4tq_Ay_06dYLXyu-AM=gtWd2Ax=77qA@mail.gmail.com> <bf15ecb1612347f9ad4d2f58c4ac3195@BY2PR03MB074.namprd03.prod.outlook.com>
Date: Thu, 28 Nov 2013 11:06:02 +0000
Message-ID: <CA+BZK2r6XPfLqphpF__PRKfRPnZK6hUdpbzb0O2wSC2BsZCRZw@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=089e01160edc04badd04ec3ab377
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 11:06:05 -0000

--089e01160edc04badd04ec3ab377
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Twitter shared some interesting statistics after enabling ECDHE

https://blog.twitter.com/2013/forward-secrecy-at-twitter-0

The key statistic relevant to this discussion is the impact of an extra
round trip during the handshake. Twitter states that most requests do not
require a full handshake:

"HTTP keepalives and session
resumption<http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html>mean
that most requests do not require a full handshake, so handshake
operations do not dominate our CPU usage."

This is great news for encrypted SNI and ALPN.

Any more statistics welcome.

Increased security for everyone. Neglectable performance impact in limited
circumstances.


regards,

skyper



On Tue, Nov 19, 2013 at 11:21 PM, Marsh Ray <maray@microsoft.com> wrote:

> From: Ralf Skyper Kaiser
> > > > No. Not at all. What I'm looking for is encrypted SNI and the
> browser to stop advertising
> > > > in advance which server I'm connecting to. (On a side note there is
> a lot of work
> > > > progressing in the DNS community for making DNS confidential. Now is
> the time to
> > > > fix the last leg that leaks the domain name: SNI).
>
> > > This is not something you can solve with a few tweaks of the TLS
> protocol.
> > > And may get the consumers of TLS in big trouble if you continue
> boasting
> > > that you could achieve this, because some might fall for this myth.
>
> I think what Martin may be referring to is that to provide this protection
> against
> active MitM attackers generally requires an additional round trip.
>
> > It fact it can be solved with a tweak in TLS 1.3. See Eric's IETF88
> presentation.
> > regards,
>
> This was my prior suggestion which functions as an extension to 1.0.
> Posting it here mainly
> In case anyone was interested to see how big of a 'tweak' that requires.
>
> http://www.ietf.org/mail-archive/web/tls/current/msg08722.html
>
> - Marsh
>
> Usual disclaimers apply, my own personal opinions, etc.
>
>

--089e01160edc04badd04ec3ab377
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br>Twitter shared some interesting statistics=
 after enabling ECDHE<br><br><a href=3D"https://blog.twitter.com/2013/forwa=
rd-secrecy-at-twitter-0">https://blog.twitter.com/2013/forward-secrecy-at-t=
witter-0</a><br>
<br></div>The key statistic relevant to this discussion is the impact of an=
 extra round trip during the handshake. Twitter states that most requests d=
o not require a full handshake:<br><div><br>&quot;HTTP keepalives and <a hr=
ef=3D"http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html"=
>session resumption</a> mean that most requests do not require a full hands=
hake, so handshake operations do not dominate our CPU usage.&quot;<br>
<br></div><div>This is great news for encrypted SNI and ALPN.<br><br></div>=
<div>Any more statistics welcome.<br><br></div><div>Increased security for =
everyone. Neglectable performance impact in limited circumstances.<br></div=
>
<div><br><br></div><div>regards,<br><br>skyper<br></div><div><br></div></di=
v><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Nov=
 19, 2013 at 11:21 PM, Marsh Ray <span dir=3D"ltr">&lt;<a href=3D"mailto:ma=
ray@microsoft.com" target=3D"_blank">maray@microsoft.com</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">From: Ralf Skyper Kaiser<br>
<div class=3D"im">&gt; &gt; &gt; No. Not at all. What I&#39;m looking for i=
s encrypted SNI and the browser to stop advertising<br>
&gt; &gt; &gt; in advance which server I&#39;m connecting to. (On a side no=
te there is a lot of work<br>
&gt; &gt; &gt; progressing in the DNS community for making DNS confidential=
. Now is the time to<br>
&gt; &gt; &gt; fix the last leg that leaks the domain name: SNI).<br>
<br>
&gt; &gt; This is not something you can solve with a few tweaks of the TLS =
protocol.<br>
&gt; &gt; And may get the consumers of TLS in big trouble if you continue b=
oasting<br>
&gt; &gt; that you could achieve this, because some might fall for this myt=
h.<br>
<br>
</div>I think what Martin may be referring to is that to provide this prote=
ction against<br>
active MitM attackers generally requires an additional round trip.<br>
<div class=3D"im"><br>
&gt; It fact it can be solved with a tweak in TLS 1.3. See Eric&#39;s IETF8=
8 presentation.<br>
&gt; regards,<br>
<br>
</div>This was my prior suggestion which functions as an extension to 1.0. =
Posting it here mainly<br>
In case anyone was interested to see how big of a &#39;tweak&#39; that requ=
ires.<br>
<br>
<a href=3D"http://www.ietf.org/mail-archive/web/tls/current/msg08722.html" =
target=3D"_blank">http://www.ietf.org/mail-archive/web/tls/current/msg08722=
.html</a><br>
<br>
- Marsh<br>
<br>
Usual disclaimers apply, my own personal opinions, etc.<br>
<br>
</blockquote></div><br></div>

--089e01160edc04badd04ec3ab377--

From p.gutmann@auckland.ac.nz  Thu Nov 28 03:32:39 2013
Return-Path: <p.gutmann@auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B295D1AE036 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 03:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aATnF_FSUeNw for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 03:32:37 -0800 (PST)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 284D91ADF5B for <tls@ietf.org>; Thu, 28 Nov 2013 03:32:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1385638356; x=1417174356; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=LKUsnsqGhxxkhFaH8csh9qxOi9ipbFJzh4BSBEwvGqo=; b=WRXjX/TTiURhrCRkqyEFuQ4c1552+EC87Pj6GksfkExp9Vp3q25xLvbh c44BTYJQIhxa/UlJWnE5KntbhldETuD0Ai8xPil1wJYAa/wAvt18EhMgs 3j0Kmqk3jbhgDz0l/B6oYhVq0KimXMAL/KiAmlZhgzpvp8vXprvofwjgD A=;
X-IronPort-AV: E=Sophos;i="4.93,790,1378814400"; d="scan'208";a="295430175"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 29 Nov 2013 00:32:30 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.231]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 00:32:29 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re:  padding bug)
Thread-Index: Ac7sLYUj8fxPetFNSxmzMY7tNy/bWg==
Date: Thu, 28 Nov 2013 11:32:29 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Encrypt-then-MAC again (was Re:  padding bug)
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 11:32:39 -0000

Michael D'Errico <mike-list@pobox.com> writes:=0A=
=0A=
>In trying to figure out what's stalling the encrypt-then-mac draft=0A=
=0A=
What's stalling the draft is that the WG chairs refuse to accept it, and=0A=
nothing else.  This is a simple, trivial fix for a decade-old problem that'=
s=0A=
come back to bite us again and again, that several implementations have=0A=
already implemented, and that a straw poll on the list a while back indicat=
ed=0A=
had general support.  In other words the requirements for rough consensus a=
nd=0A=
running code was met some time ago.=0A=
=0A=
Therefore, I propose a second straw poll to follow the earlier one:=0A=
=0A=
 The WG chairs have refused to accept a draft containing a simple,=0A=
 straightforward fix to a serious problem in TLS' crypto, one that has roug=
h=0A=
 consensus and running code.  I therefore propose a vote of no-confidence i=
n=0A=
 the TLS WG chairs, since I have no confidence that they're acting in the b=
est=0A=
 interests of TLS development and TLS users.=0A=
=0A=
To get things started, I'll vote no-confidence in the TLS WG chairs.=0A=
=0A=
Peter.=0A=

From SRS0=uCA0=VF=acm.org=bmoeller@srs.kundenserver.de  Thu Nov 28 04:21:52 2013
Return-Path: <SRS0=uCA0=VF=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840861AE0B0 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 04:21:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.969
X-Spam-Level: 
X-Spam-Status: No, score=0.969 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9g31mNz4q-r for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 04:21:51 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1C21D1ADFA0 for <tls@ietf.org>; Thu, 28 Nov 2013 04:21:51 -0800 (PST)
Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0LzWb8-1VYPtv0rH0-014z7a; Thu, 28 Nov 2013 13:21:49 +0100
Received: by mail-ob0-f178.google.com with SMTP id uz6so8864468obc.9 for <tls@ietf.org>; Thu, 28 Nov 2013 04:21:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AtEuKy8PO5GKWNHUPCE0MtNAyyRAEzWe6GpHXnldbNo=; b=IGn5TNDGErhZJSD8VyfBaFo4tiqe57QzWqYmvv83SE/hWrEGlIvESHMmdWfAPS2ANd 4V8C//OtGRdCrP+IuWvNzQL4AU3v+2V81Ee3QGfpqca+tBYSY4cCT21TxW40PVJ4abMt GpWKMfhvD4uOqkNv+mY1pRqdK7R+EJqyVDy4eAExwDdx/wLrTFahkwlAYf2sWX2zribM K5uUFAUkswBCN+YZ7Nwy/y9e2Vb3J5Vq9XGh0MXiywhfSIjPRT6SEeaiCFvu2lQvxEGa 6LvLEMAzlq2waDGfIteA5Dx8JWIowRESTSF9K8TUQq4PXOI5W8VU5b/Mvcq7j/UihBnT EPuw==
MIME-Version: 1.0
X-Received: by 10.60.93.67 with SMTP id cs3mr38263410oeb.12.1385641307965; Thu, 28 Nov 2013 04:21:47 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Thu, 28 Nov 2013 04:21:47 -0800 (PST)
In-Reply-To: <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com> <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com> <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com>
Date: Thu, 28 Nov 2013 13:21:47 +0100
Message-ID: <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b33d176f292ff04ec3bc16a
X-Provags-ID: V02:K0:yXKb4cBNpYP3bGg8NgLQ0dYz/u2fJMlXtea+efowg4t UxR82x5m+9D1vXhdHeKH178LCvg8blQFYvoF3F6cbkBDpqm97S 0AFfEzuA5k8nTspWtf4Bjhbv7QvpdxewDGMja73hMrouTLP10H bqx21XQxY3qQnQgMmnxz0C+bDEHDAjp4x3vu5vyZyTmbULKq5a yC4jDY/Ds2HUxt3wUSGP1X80qG1m6vD2PYbi242OMEEqc7qVEN RlM13/uvcF681CEncY1he5bTWiR9eDXNqxpmNtAOJn3FWUTm/F U5ADEGtxjV1lCk8U7FnmG5G1yw3gNj0JYqJQS4TieiE8xOtiKf ktOhoESqX9hJEgmnR0Nu3TL6t9IOd759cMW8vBE1yebCxpOcUb zbFlLe9Ykeq6wqX+mqHhUXZpXrO2kAIcyxsO+cY39M6/EXnyJC Ewgtr
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 12:21:52 -0000

--047d7b33d176f292ff04ec3bc16a
Content-Type: text/plain; charset=ISO-8859-1

Everyone,

the new I-D for TLS_FALLBACK_SCSV is now at
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.

I hope we can get rough consensus on this beyond Adam and me, and get it
adopted as a Working Group item with all due haste.

Bodo

--047d7b33d176f292ff04ec3bc16a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Everyone,<div><br></div><div>the new I-D for=A0TLS_FALLBAC=
K_SCSV is now at=A0<a href=3D"http://tools.ietf.org/html/draft-bmoeller-tls=
-downgrade-scsv-01">http://tools.ietf.org/html/draft-bmoeller-tls-downgrade=
-scsv-01</a>.</div>
<div><br></div><div>I hope we can get rough consensus on this beyond Adam a=
nd me, and get it adopted as a Working Group item with all due haste.</div>=
<div><br></div><div>Bodo</div><div><br></div><div><br></div></div>

--047d7b33d176f292ff04ec3bc16a--

From ekr@rtfm.com  Thu Nov 28 07:03:33 2013
Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A401AD9B8 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 07:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hto0T-Unrjq for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 07:03:31 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 38D0B1AD7BF for <tls@ietf.org>; Thu, 28 Nov 2013 07:03:31 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so5750325wgh.22 for <tls@ietf.org>; Thu, 28 Nov 2013 07:03:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R3hABBIyTSs5irmQ9BKxkQz6zgLVf/7QO23q6mtoVpY=; b=F/mgoLtdAUX8BfEJR8CCkWwCssJZmOSqSUp7Tpx+6JUOoGwRWHqmGr93g/FlskqboG NvgDNhBkYS+l9gnaVNmWWVmsP+c592r/3jDpmrhLIyI/YWD73dK+h+fdTR4mj8BoYb3B 9ll3HKBg1+RbQvHqkLTAcJpSewdOSQmdq774tNX4DCFMAHknWeG5R/LvRx6XEFLx0X1M aQS7vCaLAiRNYb4lx5l02Tk886P1uAMywVrn4vTiyVWYh2mWUCqdaA08XItJpe17fyUP 2/qW+5thULoe4I5kWPsjE6iCtx/cHBpYrH2PIOmevN6A7MJD8RAVLVq7VQVe7n6N/xDX dABQ==
X-Gm-Message-State: ALoCoQnl//TFvqph2pBqOj7tNB0QV1uKYQFeXyDmbhLI+Vgs8IHhn9BvaBRkc4EAWCShsZ2xR8Mg
X-Received: by 10.194.47.161 with SMTP id e1mr2452493wjn.66.1385651009707; Thu, 28 Nov 2013 07:03:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.152.137 with HTTP; Thu, 28 Nov 2013 07:02:49 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Nov 2013 07:02:49 -0800
Message-ID: <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 15:03:33 -0000

On Thu, Nov 28, 2013 at 3:32 AM, Peter Gutmann <p.gutmann@auckland.ac.nz> wrote:
> Michael D'Errico <mike-list@pobox.com> writes:
>
>>In trying to figure out what's stalling the encrypt-then-mac draft
>
> What's stalling the draft is that the WG chairs refuse to accept it, and
> nothing else.

Peter,

This topic was discussed at the TLS WG meeting in Vancouver
(since you declined to attend, Joe Salowey provided a brief
description of the two options). Your proposed approach
had no support in the room. You can find the minutes here:

http://tools.ietf.org/wg/tls/minutes?item=minutes-88-tls.html

So, while there has been some support on the list, I don't
believe that this supports the claim that there is rough
consensus for this draft.

With that said, if you're unhappy with the performance of the
chairs, you should reach out to the Security ADs
(sec-ads@tools.ietf.org)

Best.
-Ekr
[Speaking as Chair]

From nmav@redhat.com  Thu Nov 28 08:08:36 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3698B1ACCE4 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 08:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5ujIoCdo_7d for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 08:08:34 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 602C21AC403 for <tls@ietf.org>; Thu, 28 Nov 2013 08:08:34 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rASG8OcX030372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Nov 2013 11:08:25 -0500
Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rASG8KOJ027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Nov 2013 11:08:24 -0500
Message-ID: <1385654900.23418.33.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Samuel Neves <sneves@dei.uc.pt>
Date: Thu, 28 Nov 2013 17:08:20 +0100
In-Reply-To: <5296C6D7.2040509@dei.uc.pt>
References: <CAM_a8JzY8VGq+N-5YbDk_3EdXkKJzof1BtUTVY8pJev2HZ9U6g@mail.gmail.com> <1384850165.2542.13.camel@dhcp-2-127.brq.redhat.com> <5296C6D7.2040509@dei.uc.pt>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: tls@ietf.org
Subject: Re: [TLS] Salsa vs. ChaCha
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 16:08:36 -0000

On Thu, 2013-11-28 at 04:30 +0000, Samuel Neves wrote:
> A few comments, though:
>  - The most successful cryptanalysis performed on Salsa20 also analyzed
> ChaCha [1, 2]. In each case, ChaCha withstood attacks with one fewer
> round than its predecessor. ChaCha does seem to deliver on its goal of
> more diffusion per round.
> 
>  - Zooko has mentioned BLAKE and its success against cryptanalysis, but
> as noted this does not translate to a useful security reduction. It is
> worth pointing out, however, that cryptographers chose to base the core
> of their algorithm in the ChaCha quarter-round rather than the Salsa
> quarter-round. This suggests equal or more confidence in ChaCha (see
> also [4]).
> 
>  - There is a concurrent proposal to integrate Chacha20 + Poly1305 as a
> TLS AEAD mode [3]. Implementors are unlikely to appreciate the
> redundancy in having two separate, but very similar ciphers, in TLS (I
> do realize that it makes just as much sense to ask Adam Langley to
> change to Salsa20).

I agree with your last point that the drafts should match to reduce the
number of algorithms needed in a TLS implementation. There is no point
to have both salsa20 and chacha.

To me it is pretty inexplicable why one would not want the winner of a
recent crypto competition in TLS but rather a modification of it (e.g.,
I haven't seen anyone arguing for another cipher in TLS when RIJNDAEL
was the winner of the NIST competition).

Nevertheless, if the TLS WG consensus is to use Chacha20/20 (or
Chacha20/12?) to replace RC4 instead of the estream's salsa20, it would
be very simple to draft a new text with it. What I didn't understand,
however, from the IETF88-TLS notes is whether it is planned to replace
RC4 at all (with a non-AEAD cipher that is).

regards,
Nikos



From watsonbladd@gmail.com  Thu Nov 28 09:15:41 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDCF1AE17D for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 09:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BrH8sFGMHLf for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 09:15:39 -0800 (PST)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 12EB61AE058 for <tls@ietf.org>; Thu, 28 Nov 2013 09:15:38 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id cc10so1109085wib.16 for <tls@ietf.org>; Thu, 28 Nov 2013 09:15:37 -0800 (PST)
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=PONZC1vfjf6959rHp98SJRpr9gSSnf3DcXZAG8YeGyU=; b=gSHVWc7rNZyRnLv5l/P1uen+2gNFAUrbPS9efp3t1We/v2De2fTai+An0DZhawqKGz n7VUFbVkC2yJVBEpuAoV3TVx2uEywIMFWhdX8crSyfELh91HiQiaCHLuzebDVSn3TI0q yW+jCJ2yrmuRH1cc3O+Ahc/nTrVJb93W74cDo6QBTsd00iSYBcGA5fmovwpt2adSwYSe Z1/w93G8NoYbbY0h+Lln+SY3ekqhylCBPQo1mGRCWFHFccvvf3/tQROYipUHvdUMadHy b8bHdFIM14dfOlIrPyuSNnGKqcNNgJRg+MIs7eqtLsmz4IuM/HoO7v7554LO7zETy/Yv dXXg==
MIME-Version: 1.0
X-Received: by 10.180.101.230 with SMTP id fj6mr3300508wib.58.1385658937735; Thu, 28 Nov 2013 09:15:37 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Thu, 28 Nov 2013 09:15:37 -0800 (PST)
In-Reply-To: <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com>
Date: Thu, 28 Nov 2013 09:15:37 -0800
Message-ID: <CACsn0ckAoQeo_rP0K4XONahzXp_kxLo8LxZMv8wjxr-dL+q_=A@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 17:15:41 -0000

On Thu, Nov 28, 2013 at 7:02 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Thu, Nov 28, 2013 at 3:32 AM, Peter Gutmann <p.gutmann@auckland.ac.nz> wrote:
>> Michael D'Errico <mike-list@pobox.com> writes:
>>
>>>In trying to figure out what's stalling the encrypt-then-mac draft
>>
>> What's stalling the draft is that the WG chairs refuse to accept it, and
>> nothing else.
>
> Peter,
>
> This topic was discussed at the TLS WG meeting in Vancouver
> (since you declined to attend, Joe Salowey provided a brief
> description of the two options). Your proposed approach
> had no support in the room. You can find the minutes here:
>
> http://tools.ietf.org/wg/tls/minutes?item=minutes-88-tls.html
>
> So, while there has been some support on the list, I don't
> believe that this supports the claim that there is rough
> consensus for this draft.
Where are the opponents on the list? Anyone can hum, but I would like
to see them
put their names and reasons down. I personally think we should have a
ciphersuitedammerung in which
everything but AES-GCM is depreciated, and adding encrypt-then-mac
isn't worth it, so I probably
would have opposed it: it adds complexity at no gain. Then again my
hopes have been crushed again and again.

But as chair you have failed consistently to ensure that the list
reflects the decision making process.
You are directly responsible for endorsing drafts with known security
issues, and have failed to articulate
a clear direction forwards for this WG. You have placed users and
their security below the convenience of vendors,
presiding over the expansion of a smorgasbord of options so that
everyone can claim to support TLS 1.2, without providing
an iota of security or interoperability. Anyone can extend TLS and get
your approval, so long as it doesn't improve
security or have a chance of actually getting used. (See SRP and PWD).
What have the past 14 years done for us in terms of improvements to TLS?
Sincerely,
Watson
>
> With that said, if you're unhappy with the performance of the
> chairs, you should reach out to the Security ADs
> (sec-ads@tools.ietf.org)
>
> Best.
> -Ekr
> [Speaking as Chair]
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From lloyd@randombit.net  Thu Nov 28 13:46:42 2013
Return-Path: <lloyd@randombit.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26DD1AE14B for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 13:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHULuAhdr0Nl for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 13:46:41 -0800 (PST)
Received: from maple.randombit.net (maple.randombit.net [66.228.45.112]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9C51AE0E1 for <tls@ietf.org>; Thu, 28 Nov 2013 13:46:41 -0800 (PST)
Received: from oak.randombit.net (oak.randombit.net [50.116.63.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by maple.randombit.net (Postfix) with ESMTPS id 32A9BA06AF for <tls@ietf.org>; Thu, 28 Nov 2013 16:46:39 -0500 (EST)
Received: by oak.randombit.net (sSMTP sendmail emulation); Thu, 28 Nov 2013 16:46:38 -0500
From: "Jack Lloyd" <lloyd@randombit.net>
Date: Thu, 28 Nov 2013 16:46:38 -0500
To: tls@ietf.org
Message-ID: <20131128214638.GA13703@randombit.net>
Mail-Followup-To: tls@ietf.org
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com> <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com> <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com> <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B
X-PGP-Key: http://www.randombit.net/pgpkey.html
User-Agent: Mutt/1.5.22 (2013-10-16)
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 21:46:42 -0000

On Thu, Nov 28, 2013 at 01:21:47PM +0100, Bodo Moeller wrote:
> Everyone,
> 
> the new I-D for TLS_FALLBACK_SCSV is now at
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01.
> 
> I hope we can get rough consensus on this beyond Adam and me, and get it
> adopted as a Working Group item with all due haste.

+1 from me on this draft.

Jack

From geoffk@geoffk.org  Thu Nov 28 13:56:26 2013
Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975BF1ADF5F for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 13:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa3I2rVRw_Hk for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 13:56:25 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0857A1ADF8C for <tls@ietf.org>; Thu, 28 Nov 2013 13:56:25 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 3FD9F33D18A; Thu, 28 Nov 2013 21:56:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Ralf Skyper Kaiser <skyper@thc.org>
References: <CA+BZK2oGsu=yr0JtAro=KOu7YUbX0E_xNnkCwfiC2g0BDS61TA@mail.gmail.com> <20131112214115.9095A1AA81@ld9781.wdf.sap.corp> <CA+BZK2pT8wJyLLV1K4B4tq_Ay_06dYLXyu-AM=gtWd2Ax=77qA@mail.gmail.com> <bf15ecb1612347f9ad4d2f58c4ac3195@BY2PR03MB074.namprd03.prod.outlook.com> <CA+BZK2r6XPfLqphpF__PRKfRPnZK6hUdpbzb0O2wSC2BsZCRZw@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 28 Nov 2013 13:56:24 -0800
In-Reply-To: <CA+BZK2r6XPfLqphpF__PRKfRPnZK6hUdpbzb0O2wSC2BsZCRZw@mail.gmail.com>
Message-ID: <m2ob54yyuv.fsf@localhost.localdomain>
Lines: 15
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 21:56:26 -0000

Ralf Skyper Kaiser <skyper@thc.org> writes:

> "HTTP keepalives and session resumption mean that most requests do
> not require a full handshake, so handshake operations do not
> dominate our CPU usage."
> 
> This is great news for encrypted SNI and ALPN.

To take advantage of this, a server using encrypted SNI and/or ALPN
must be able to determine the SNI/ALPN information from the session
resumption data.  I guess this is not too much of a problem, since the
usual reason you can't do this is that you have some kind of front-end
'server NAT' or load balancer which redirects connections to back-end
servers based on SNI/ALPN without doing any cryptography, and this
would be impossible with encrypted SNI/ALPN anyway.

From James.H.Manger@team.telstra.com  Thu Nov 28 14:52:09 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75711ADF76 for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 14:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level: 
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvZY3TboIi5E for <tls@ietfa.amsl.com>; Thu, 28 Nov 2013 14:52:08 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id D511E1ADF64 for <tls@ietf.org>; Thu, 28 Nov 2013 14:52:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,793,1378821600"; d="scan'208";a="177372167"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 29 Nov 2013 09:51:51 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,7273"; a="179436907"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 29 Nov 2013 09:51:51 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 29 Nov 2013 09:51:50 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Bodo Moeller <bmoeller@acm.org>, "tls@ietf.org" <tls@ietf.org>
Date: Fri, 29 Nov 2013 09:51:48 +1100
Thread-Topic: [TLS] An SCSV to stop TLS fallback.
Thread-Index: Ac7sNHHoKQglzGkiTcOYEDTQG2XN6AAV7W0g
Message-ID: <255B9BB34FB7D647A506DC292726F6E11536D5B2F3@WSMSG3153V.srv.dir.telstra.com>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CACsn0ckuupJaNKXGjP63LfZiDsV5FLOqfk902O9i1oheqtAAhA@mail.gmail.com> <CAL9PXLxueY_k0XWgTrqVxqXDgvCRhAW5UEa8YjU9_rnuZ6otTA@mail.gmail.com> <CAL2p+8TXJVmnb-v3xH6uzW+rpZ+v8J65TjO32__O3ZofQiwSig@mail.gmail.com> <CAL9PXLwKxF14CUNmN=-P6mhcr+xcGw0_Aaq7amdBXZKUsrKsKA@mail.gmail.com> <CADMpkcLRNmmoMOpJ9QVFPMEbpSyu39afipWUv4Du-assHoC1rw@mail.gmail.com> <CAL9PXLx0+bYn_KXKhvFz=D_jXfctdVihaXnj=SqB6EeEqRLOSg@mail.gmail.com> <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
In-Reply-To: <CADMpkcKvXxHwj+Rj_j8qF84aEbWJiBiXnk9t1qfh7NychraZcQ@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
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." <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: Thu, 28 Nov 2013 22:52:10 -0000

PiB0aGUgbmV3IEktRCBmb3LCoFRMU19GQUxMQkFDS19TQ1NWIGlzIG5vdyBhdMKgaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm1vZWxsZXItdGxzLWRvd25ncmFkZS1zY3N2LTAxLg0K
Pg0KPiBJIGhvcGUgd2UgY2FuIGdldCByb3VnaCBjb25zZW5zdXMgb24gdGhpcyBiZXlvbmQgQWRh
bSBhbmQgbWUsIGFuZCBnZXQgaXQgYWRvcHRlZCBhcyBhIFdvcmtpbmcgR3JvdXAgaXRlbSB3aXRo
IGFsbCBkdWUgaGFzdGUuDQo+DQo+IEJvZG8NCg0KKzE7IGxvb2tzIGxpa2UgYSB1c2VmdWwgYW5k
IHNpbXBsZSBhcHByb2FjaC4NCg0KLS0NCkphbWVzIE1hbmdlcg0K

From SRS0=WqfS=VG=acm.org=bmoeller@srs.kundenserver.de  Fri Nov 29 05:00:07 2013
Return-Path: <SRS0=WqfS=VG=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32A81AE029 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 05:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t3k4-3sxlwM for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 05:00:06 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDF1ADF7E for <tls@ietf.org>; Fri, 29 Nov 2013 05:00:05 -0800 (PST)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MHci0-1VlGgR1c68-003gFY; Fri, 29 Nov 2013 14:00:03 +0100
Received: by mail-ob0-f171.google.com with SMTP id wp18so9973166obc.2 for <tls@ietf.org>; Fri, 29 Nov 2013 05:00:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zr3doMRNBrTLbyqINkmXziCgPvAlpsHxxyJZpq7Trfg=; b=YFvZvnWzcfkm6U5uCu/OXv2bkOiiqJ7a7famRM6mNvL9ObXkfHg+GBxNPm4kUPY1g2 CyFKfXDr96k/YF0LfkrKH3pKuHBhRnj0XXoj+PSgeustY4DkGB7JFcFg4Rf9SSSz0IZw AevdfECfwBeIQec7dhTK3wRatvuK2TNwM9xqlxUPcJ+knRYcGX+iObuZdou2RtE+M9wT vpmk4r+DN5fUpsuNmFfMCeLzwT6LLwbZcviv4jhbOqBYEe2P+KcfYOBAaoj8OHMHu60/ 4FvuDIjSeqIaaBrQxxLc6WHCRReOPYhvMkUrTR5mol3fHpmKRQsiMtb7OLdP8nQRwTny VtXQ==
MIME-Version: 1.0
X-Received: by 10.182.229.34 with SMTP id sn2mr967044obc.86.1385730002213; Fri, 29 Nov 2013 05:00:02 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Fri, 29 Nov 2013 05:00:02 -0800 (PST)
In-Reply-To: <CACsn0ckAoQeo_rP0K4XONahzXp_kxLo8LxZMv8wjxr-dL+q_=A@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com> <CACsn0ckAoQeo_rP0K4XONahzXp_kxLo8LxZMv8wjxr-dL+q_=A@mail.gmail.com>
Date: Fri, 29 Nov 2013 14:00:02 +0100
Message-ID: <CADMpkc+jju32F+TwGQCY+jqFW0uZMZ6H68PB+Cw_x9ThuudJww@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a1134975089610a04ec506801
X-Provags-ID: V02:K0:hhCIkfUW0/PqL4ClNXUvInWceCBoqTvShwtUIBWj+9D F/e/Z1mQLBUw04wY7LsLiUok0Q+Y+s1W1yG1gjPuWaj8Brdmvf HpFzIptvPIeGOQKBsesSP4UClSjKm/nYOh04WK9bQC5LRkpeh7 kuhwSjHx1MvWtamF5gcQsnR2CtEgpI/VeNHAbxVOkwZ0O+Ez0x xYnUwA1b2HU5bKn1crE8IHa87l+gCNw0eFFs+8po20sCIvJ7E+ KSTT6aaPVcGXLh9ECIfK6zrmDylo5X0AMuUSjaXKRJR+fMLnTV Tx3ZTwCYjT2xSAm5drkxMCLcPhiYSEV+Wbsxe3JZacxj0IYrlE Q286MFUyXUS5BhFxBaWQbkdKieLAV7qgfJxqMhS8qNRRz4mIxz K0ngD9b+mtfp9ihnD2gUhgk6MuSmT8tf9DOgi+a+hFmeR3ckmr +bahB
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 13:01:01 -0000

--001a1134975089610a04ec506801
Content-Type: text/plain; charset=ISO-8859-1

> > This topic was discussed at the TLS WG meeting in Vancouver
> > (since you declined to attend, Joe Salowey provided a brief
> > description of the two options). Your proposed approach
> > had no support in the room. You can find the minutes here:
> >
> > http://tools.ietf.org/wg/tls/minutes?item=minutes-88-tls.html
>

That page looks broken (garbled UTF-8?).  Try
http://www.ietf.org/proceedings/88/minutes/minutes-88-tls for a more
legible version (PDF).


> So, while there has been some support on the list, I don't
> > believe that this supports the claim that there is rough
> > consensus for this draft.
>


> Where are the opponents on the list? Anyone can hum, but I would like
> to see them
> put their names and reasons down


Decisions at meetings can't silently override mailing list consensus, but I
think Eric felt that the meeting outcome merely reflected a lack of
consensus that he'd previously already got from the list -- see his
previous summary on this list here:

http://www.ietf.org/mail-archive/web/tls/current/msg10004.html

(That said, Nikos' complaint seems bogus to me.  Peter's proposal seems
fine from a security point of view -- as long as clients refuse to
unnecessarily roll back to SSL 3.0, e.g. using
draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it's worth
the extra complexity given the other options.)

Bodo

--001a1134975089610a04ec506801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex">
<div class=3D"im">&gt; This topic was discussed at the TLS WG meeting in Va=
ncouver<br>
&gt; (since you declined to attend, Joe Salowey provided a brief<br>
&gt; description of the two options). Your proposed approach<br>
&gt; had no support in the room. You can find the minutes here:<br>
&gt;<br>
&gt; <a href=3D"http://tools.ietf.org/wg/tls/minutes?item=3Dminutes-88-tls.=
html" target=3D"_blank">http://tools.ietf.org/wg/tls/minutes?item=3Dminutes=
-88-tls.html</a></div></blockquote><div><br></div><div>That page looks brok=
en (garbled UTF-8?). =A0Try=A0<a href=3D"http://www.ietf.org/proceedings/88=
/minutes/minutes-88-tls">http://www.ietf.org/proceedings/88/minutes/minutes=
-88-tls</a> for a more legible version (PDF).</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div class=3D"im">
&gt; So, while there has been some support on the list, I don&#39;t<br>
&gt; believe that this supports the claim that there is rough<br>
&gt; consensus for this draft.<br></div></blockquote><div>=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">
<div class=3D"im">
</div>Where are the opponents on the list? Anyone can hum, but I would like=
<br>
to see them<br>
put their names and reasons down</blockquote><div><br></div><div>Decisions =
at meetings can&#39;t silently override mailing list consensus, but I think=
 Eric felt that the meeting outcome merely reflected a lack of consensus th=
at he&#39;d previously already got from the list -- see his previous summar=
y on this list here:</div>
<div><br></div><div><div><a href=3D"http://www.ietf.org/mail-archive/web/tl=
s/current/msg10004.html">http://www.ietf.org/mail-archive/web/tls/current/m=
sg10004.html</a><br></div></div><div><br></div><div>(That said, Nikos&#39; =
complaint seems bogus to me. =A0Peter&#39;s proposal seems fine from a secu=
rity point of view -- as long as clients refuse to unnecessarily roll back =
to SSL 3.0, e.g. using draft-bmoeller-tls-downgrade-scsv-01 --, the questio=
n is just if it&#39;s worth the extra complexity given the other options.)<=
/div>
<div><br></div><div>Bodo</div><div><br></div></div></div></div>

--001a1134975089610a04ec506801--

From nmav@redhat.com  Fri Nov 29 07:23:48 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EE41ADF7E for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 07:23:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iemYmyhi_r9K for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 07:23:46 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id C05D71ADBE5 for <tls@ietf.org>; Fri, 29 Nov 2013 07:23:46 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rATFNhOT007750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 10:23:43 -0500
Received: from [10.10.55.102] (vpn-55-102.rdu2.redhat.com [10.10.55.102]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rATFNZ5u011067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 10:23:42 -0500
Message-ID: <1385738609.3050.4.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Bodo Moeller <bmoeller@acm.org>
Date: Fri, 29 Nov 2013 16:23:29 +0100
In-Reply-To: <CADMpkc+jju32F+TwGQCY+jqFW0uZMZ6H68PB+Cw_x9ThuudJww@mail.gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com> <CACsn0ckAoQeo_rP0K4XONahzXp_kxLo8LxZMv8wjxr-dL+q_=A@mail.gmail.com> <CADMpkc+jju32F+TwGQCY+jqFW0uZMZ6H68PB+Cw_x9ThuudJww@mail.gmail.com>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 15:23:48 -0000

On Fri, 2013-11-29 at 14:00 +0100, Bodo Moeller wrote:

>         > So, while there has been some support on the list, I don't
>         > believe that this supports the claim that there is rough
>         > consensus for this draft.
>         Where are the opponents on the list? Anyone can hum, but I
>         would like
>         to see them
>         put their names and reasons down

> Decisions at meetings can't silently override mailing list consensus,
> but I think Eric felt that the meeting outcome merely reflected a lack
> of consensus that he'd previously already got from the list -- see his
> previous summary on this list here:
> http://www.ietf.org/mail-archive/web/tls/current/msg10004.html
> 
> (That said, Nikos' complaint seems bogus to me.  Peter's proposal
> seems fine from a security point of view -- as long as clients refuse
> to unnecessarily roll back to SSL 3.0, e.g. using
> draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it's
> worth the extra complexity given the other options.)

I think there is some confusion over that. It was a suggestion rather
than a complain; and is not a stopper for such a draft. The fact that
MAC truncation is known to improve security (for HMAC-MD5 and
HMAC-SHA1), does not render non-truncation insecure (as many have
pointed out -including me - there are no known practical attacks against
HMAC-MD5 and HMAC-SHA1).

regards,
Nikos




From SRS0=WqfS=VG=acm.org=bmoeller@srs.kundenserver.de  Fri Nov 29 08:02:21 2013
Return-Path: <SRS0=WqfS=VG=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0321AE0D0 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 08:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Level: 
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn4bqT18pEUc for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 08:02:19 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB1E1AE01E for <tls@ietf.org>; Fri, 29 Nov 2013 08:02:19 -0800 (PST)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Ma2v9-1W3oXu1C4l-00LoZZ; Fri, 29 Nov 2013 17:02:17 +0100
Received: by mail-oa0-f50.google.com with SMTP id n16so10480957oag.23 for <tls@ietf.org>; Fri, 29 Nov 2013 08:02:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FFyv1UtzPD2pRN9YYjheGWQOMtDyWzVizALcG80HwHI=; b=BS2gQ8f/wQm14LHslV7F8N3pVz/07MgTxfMeacWiCmySTmkcPs8L1aEhOCJWTWuolC oPStOERNu181eUEpZ73ifT4FkLwlwZ152/IzQJYP8TzoEuqxxtTrI2nrYXCEvWWQRjxl dVSAzwUG4Gif4u/R9o7vDWC7HC6AVg1F/xKTWlobfuNaO2Ac9cUZxHoQ/HCoz4vTab2T LBjj82iJkH8GHyT/+0qyeBqjzwISFpEYlWkdpx+aMhAhUqh6kiDxsn3AseqKwJTQa9Z1 ymFr2jkXMllBS/0ffRGL96RZVkAmvOA4HfXyPrRez2h00qE+QY7+PT4ysjFb0MumKO2d M8cw==
MIME-Version: 1.0
X-Received: by 10.182.80.196 with SMTP id t4mr43695868obx.1.1385740936019; Fri, 29 Nov 2013 08:02:16 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Fri, 29 Nov 2013 08:02:15 -0800 (PST)
In-Reply-To: <1385738609.3050.4.camel@aspire.lan>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <CABcZeBP77fwR8Rwv9me4PuGza7ec9cU-JbsMUOxHbpV0ULYOqA@mail.gmail.com> <CACsn0ckAoQeo_rP0K4XONahzXp_kxLo8LxZMv8wjxr-dL+q_=A@mail.gmail.com> <CADMpkc+jju32F+TwGQCY+jqFW0uZMZ6H68PB+Cw_x9ThuudJww@mail.gmail.com> <1385738609.3050.4.camel@aspire.lan>
Date: Fri, 29 Nov 2013 17:02:15 +0100
Message-ID: <CADMpkc+uK8C=LwbgV0jkpnDPEPyYs_vv_+XtbiGjSMRHs2rM0Q@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e4eda3e5b7b04ec52f44b
X-Provags-ID: V02:K0:nXuS3/n2wSMxGHwyriwkOeBVSFK6JeXv8mbfPCg12pn BL/oFymI8UE659Y3FUB0jW6jGUvu8Pt//w4Ix3EjlIG6ERYAux Bh5MchYsP44x5je3ip2xActeri7d/38vI2neU4I1H/K9xUlxQj H0yDArX0Asmjc8yemEi9o1hwAjSyLbXa/n1OIS804hk35AENau vRbbBB/ydXWDCEBCofEwkNrg1r8Det1+BnrRTeIIKht1U6/cqM TikJnZuk49G8ZJBKMJztqYiIPlAH3wxVB1SHFKCjI0mtxRdIyW 0RB/i9Ncj1hB3aF8vGOKjozdOv5KsIayO1a5TbR+83o2YRpccJ eg6nVyR2MebWHfvuOuunx0lNiK0Xxhe6uaxq5v7wv2RjnozbJp 07CI+cJXBmLOw2jeOUls1CLVt3WFxmgFUeHxJ80ESPzlcKTPCe pfkfJ
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 16:02:21 -0000

--047d7b2e4eda3e5b7b04ec52f44b
Content-Type: text/plain; charset=ISO-8859-1

>
>
> > http://www.ietf.org/mail-archive/web/tls/current/msg10004.html
> >
> > (That said, Nikos' complaint seems bogus to me.  Peter's proposal
> > seems fine from a security point of view -- as long as clients refuse
> > to unnecessarily roll back to SSL 3.0, e.g. using
> > draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it's
> > worth the extra complexity given the other options.)
>
> I think there is some confusion over that. It was a suggestion rather
> than a complain; and is not a stopper for such a draft.


Thanks for clarifying!


> The fact that
> MAC truncation is known to improve security (for HMAC-MD5 and
> HMAC-SHA1), does not render non-truncation insecure (as many have
> pointed out -including me - there are no known practical attacks against
> HMAC-MD5 and HMAC-SHA1).
>

It's also not actually a known fact that MAC truncation will improve
security.  While there are certain (hypothetical) advantages, there are
also certain (more concrete) disadvantages.  As the HMAC RFC puts it (RFC
2104): "The results in this area are not absolute as for the overall
security advantages of truncation."

Bodo

--047d7b2e4eda3e5b7b04ec52f44b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"im"><br>
&gt; <a href=3D"http://www.ietf.org/mail-archive/web/tls/current/msg10004.h=
tml" target=3D"_blank">http://www.ietf.org/mail-archive/web/tls/current/msg=
10004.html</a><br>
&gt;<br>
&gt; (That said, Nikos&#39; complaint seems bogus to me. =A0Peter&#39;s pro=
posal<br>
&gt; seems fine from a security point of view -- as long as clients refuse<=
br>
&gt; to unnecessarily roll back to SSL 3.0, e.g. using<br>
&gt; draft-bmoeller-tls-downgrade-scsv-01 --, the question is just if it&#3=
9;s<br>
&gt; worth the extra complexity given the other options.)<br>
<br>
</div>I think there is some confusion over that. It was a suggestion rather=
<br>
than a complain; and is not a stopper for such a draft.</blockquote><div><b=
r></div><div>Thanks for clarifying!</div><div>=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 The fact that<br>
MAC truncation is known to improve security (for HMAC-MD5 and<br>
HMAC-SHA1), does not render non-truncation insecure (as many have<br>
pointed out -including me - there are no known practical attacks against<br=
>
HMAC-MD5 and HMAC-SHA1).<br></blockquote><div><br></div><div>It&#39;s also =
not actually a known fact that MAC truncation will improve security. =A0Whi=
le there are certain (hypothetical) advantages, there are also certain (mor=
e concrete) disadvantages. =A0As the HMAC RFC puts it (RFC 2104): &quot;The=
 results in this area are not absolute as for the overall security advantag=
es of truncation.&quot;</div>
<div><br></div><div>Bodo</div><div><br></div></div></div></div>

--047d7b2e4eda3e5b7b04ec52f44b--

From mrex@sap.com  Fri Nov 29 08:20:40 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC971ADFCE for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 08:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pXy2OKsBMTR for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 08:20:38 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 105B61ADEA3 for <tls@ietf.org>; Fri, 29 Nov 2013 08:20:37 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rATGKPKh019672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 17:20:25 +0100 (MET)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>
Date: Fri, 29 Nov 2013 17:20:25 +0100 (CET)
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: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 29 Nov 2013 16:20:40 -0000

Peter Gutmann wrote:
>
>Michael D'Errico <mike-list@pobox.com> writes:
>> 
>>In trying to figure out what's stalling the encrypt-then-mac draft
> 
> What's stalling the draft is that the WG chairs refuse to accept it, and
> nothing else.  This is a simple, trivial fix for a decade-old problem that's
> come back to bite us again and again, that several implementations have
> already implemented, and that a straw poll on the list a while back indicated
> had general support.  In other words the requirements for rough consensus and
> running code was met some time ago.

I've been thinking over this proposal for quite a while, and I've made
up my mind.  I'm now strongly opposed.

I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
in GenericBlockCipher PDU for all existing versions of TLS, but I'm
strongly opposed to moving the HMAC into the clear, and into particular
I am strongly opposed to put the HMAC into the clear for the
GenericStreamCipher PDU.

I'm going to prepare a proposal I-D to do exactly (and only) what
Serge Vaudenay had recommended in 2001, and what TLSv1.1 failed to fix,
change mac-pad-encrypt into pad-mac-encrypt for the GenericBlockCipher PDU.
When doing this, we can also consistently adopt the explicit random IV
(which can be implemented as a random confounder) to all versions of TLS.

Signaling of this PDU change will be through a new SCSV in ClientHello,
confirmation by the Server through a simple ServerHelloExtension, similar
to how signaling is done for rfc5746 (TLS renegotiation_info extension).

-Martin

From juhovh@iki.fi  Fri Nov 29 09:05:02 2013
Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914271AE1BF for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 09:05:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSXii0AvbLCO for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 09:05:00 -0800 (PST)
Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by ietfa.amsl.com (Postfix) with ESMTP id EEF121AE12E for <tls@ietf.org>; Fri, 29 Nov 2013 09:04:12 -0800 (PST)
Received: from [10.178.135.118] (85-76-79-52-nat.elisa-mobile.fi [85.76.79.52]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 719491397D3; Fri, 29 Nov 2013 19:04:02 +0200 (EET)
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Fri, 29 Nov 2013 19:00:29 +0200
To: "mrex@sap.com" <mrex@sap.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 17:05:02 -0000

> On 29.11.2013, at 18.20, mrex@sap.com (Martin Rex) wrote:
>=20
> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
> strongly opposed to moving the HMAC into the clear, and into particular
> I am strongly opposed to put the HMAC into the clear for the
> GenericStreamCipher PDU.

You have been quite clear about that, and I've got the impression that you a=
re the only but very vocal opponent of encrypt-then-mac on this list. Althou=
gh in GenericStreamCipher it offers no benefit, I still haven't seen a convi=
ncing argument about why encrypt-then-mac should not be used.

I'm sure you have good reasons for this opposition, so could you please expl=
ain them in one or two sentences. This excluding the "encrypting the HMAC ma=
kes it safer" argument, which might be true but as I understand is not well p=
roven.

> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

This might be the only way to solve this problem, but I must point out that S=
CSVs seem to be a solution for everything now. Browsers allow a version down=
grade attack? Let's add an SCSV. The CBC handling is broken? Let's add an SC=
SV. How many SCSV hacks can we add?

Adding AEAD support for TLS <1.2 is a good idea and wouldn't require hacks, b=
ut I'm worried it wouldn't be adopted fast enough. Especially since CBC+HMAC=
 AEAD ciphers that would be easiest to patch are impossible in TLS because o=
f the way AEAD is implemented.

So I prefer fixing CBC first (with encrypt-then-mac unless otherwise proven)=
 and then allowing AEAD in all versions to let people prepare for GCM in wha=
tever version they use instead of trying to force TLS 1.2 upgrade with GCM, i=
t clearly isn't working.


Juho

From rransom.8774@gmail.com  Fri Nov 29 09:26:09 2013
Return-Path: <rransom.8774@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A11B1ACC8A for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 09:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.45
X-Spam-Level: 
X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCiG2pc-SRbx for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 09:26:08 -0800 (PST)
Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2531A1AC43E for <tls@ietf.org>; Fri, 29 Nov 2013 09:26:08 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id nd7so9961127qeb.17 for <tls@ietf.org>; Fri, 29 Nov 2013 09:26:06 -0800 (PST)
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:content-transfer-encoding; bh=C8Gn74K1aj2e5xotzFseYp95Ro10QQ3nSi7US8RefcI=; b=VK77TIiQIZI2+i+0P5tOKtTFWRK79fNNpWHHbwg3kInN/Wuj8X/9Wd+VVjjroYjm9D 88GB4yxbBb21IjcZh82tQ9CSbAyqv7Xop8kg9AaM7yvgd09kVGqKqdjc35f1Qufur/Ih fvFYzqKrV+rbvQUViVCcdgZc89OayimXgJ39sinqQz24vVWeQ4ljXwR74SSlSvUxi+qb qFk/wnEvaXSI+T/PHI3cq7E1ZJtsHFwoqG1v9bj6Ns7JZt05t8vP+WGiZwVCtJb1TNUl 4nSZjERF1AwK3kfGhQVc/dhGqn7U2TcFtPXYBjNQC39Dju+xeHCCS30phpLM5+CMyWrv Yo/Q==
MIME-Version: 1.0
X-Received: by 10.49.94.177 with SMTP id dd17mr88542465qeb.14.1385745966780; Fri, 29 Nov 2013 09:26:06 -0800 (PST)
Received: by 10.229.8.3 with HTTP; Fri, 29 Nov 2013 09:26:06 -0800 (PST)
In-Reply-To: <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp> <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
Date: Fri, 29 Nov 2013 09:26:06 -0800
Message-ID: <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com>
From: Robert Ransom <rransom.8774@gmail.com>
To: =?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= <juhovh@iki.fi>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 17:26:09 -0000

On 11/29/13, Juho V=C3=A4h=C3=A4-Herttua <juhovh@iki.fi> wrote:
>
>> On 29.11.2013, at 18.20, mrex@sap.com (Martin Rex) wrote:
>>
>> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
>> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
>> strongly opposed to moving the HMAC into the clear, and into particular
>> I am strongly opposed to put the HMAC into the clear for the
>> GenericStreamCipher PDU.
>
> You have been quite clear about that, and I've got the impression that yo=
u
> are the only but very vocal opponent of encrypt-then-mac on this list.

Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
don't know of any others.

> Although in GenericStreamCipher it offers no benefit, I still haven't see=
n a
> convincing argument about why encrypt-then-mac should not be used.
>
> I'm sure you have good reasons for this opposition, so could you please
> explain them in one or two sentences. This excluding the "encrypting the
> HMAC makes it safer" argument, which might be true but as I understand is
> not well proven.

"not well proven" is the wrong phrase here.  Marsh Ray solidly debunked it.



> Adding AEAD support for TLS <1.2 is a good idea and wouldn't require hack=
s,
> but I'm worried it wouldn't be adopted fast enough.

To put it even more bluntly: OS and hardware vendors will treat TLS
1.2 or AEAD support and an efficient-in-secure-software AEAD cipher as
new features, and sit on them for a few *years*.  TLS, and every
pre-1.2 TLS implementation in the world, needs a critical security
bugfix *yesterday*, and the only bugfix I see that is ready to be
deployed as such is draft-gutmann-tls-encrypt-then-mac.


Robert Ransom

From nmav@redhat.com  Fri Nov 29 10:13:41 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972B21AE29F for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UE8j_kMrRGPG for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:13:40 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id E50581AE29C for <tls@ietf.org>; Fri, 29 Nov 2013 10:13:39 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rATIDbGh011727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <tls@ietf.org>; Fri, 29 Nov 2013 13:13:38 -0500
Received: from [10.10.61.254] (vpn-61-254.rdu2.redhat.com [10.10.61.254]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rATIDZli019186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 29 Nov 2013 13:13:36 -0500
Message-ID: <1385748814.5805.4.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: tls@ietf.org
Date: Fri, 29 Nov 2013 19:13:34 +0100
In-Reply-To: <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com>
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp> <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi> <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 18:13:41 -0000

On Fri, 2013-11-29 at 09:26 -0800, Robert Ransom wrote:

> > You have been quite clear about that, and I've got the impression that you
> > are the only but very vocal opponent of encrypt-then-mac on this list.
> 
> Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
> don't know of any others.

It seems I'll have to repeat that. I don't oppose this draft. I prefer
an alternative [1], which was not mentioned in the IETF88 meeting. So if
the question would be AEAD (i.e, not a fix) or encrypt-then-mac, I'd go
with the latter. If the question is [1] or encrypt-then-mac I'd go with
the former.

> > I'm sure you have good reasons for this opposition, so could you
> please
> > explain them in one or two sentences. This excluding the "encrypting
> the
> > HMAC makes it safer" argument, which might be true but as I
> understand is
> > not well proven.
> "not well proven" is the wrong phrase here.  Marsh Ray solidly
> debunked it.

I don't quite understand that. No-one questioned his observations in any
point at any previous discussion. Please review them to understand where
I stand.

regards,
Nikos

[1].
http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01



From watsonbladd@gmail.com  Fri Nov 29 10:23:47 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A381AD948 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwkALMHdGFAc for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:23:45 -0800 (PST)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC911AD8F6 for <tls@ietf.org>; Fri, 29 Nov 2013 10:23:45 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so9384016wes.26 for <tls@ietf.org>; Fri, 29 Nov 2013 10:23:43 -0800 (PST)
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=5cJhoYs7JYWeAFZ7v92WnIE5nuKIxu/1emxd7c9TH/s=; b=dveQBYSzryr3yvD3xTH8iIrXW/77yXgPVPyPh1KP0+LlYhhQloS5edKiOVwEAqXijh w+ZwZvDKBP5hUEKKYs/bFf5v634qj3tjIBMFj+3KD9RMUWjLNE8poJfpDaVKugYZqtvp 8bhaQlIU//LkbPN3MuOrh7e0pDipDacYzv385FWB6nrDQBQ5A+HSEaKXVF5sqEieAApo K8/NDlQd0XO3dZYXKJWQAbsUe2fNpGWIf/qMtZ87zusKVCJZYuchR7TyhpU9Q/O7z0AO 7/Mc+FKq5gb7IOl80kF6VogiQb9RZiD2eu4ZeF1eHpaBL8z8Tz9WWL14cAE6w9enLaR+ Po5w==
MIME-Version: 1.0
X-Received: by 10.180.36.105 with SMTP id p9mr7875375wij.58.1385749423804; Fri, 29 Nov 2013 10:23:43 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 29 Nov 2013 10:23:43 -0800 (PST)
In-Reply-To: <1385748814.5805.4.camel@aspire.lan>
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp> <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi> <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com> <1385748814.5805.4.camel@aspire.lan>
Date: Fri, 29 Nov 2013 10:23:43 -0800
Message-ID: <CACsn0c=3OJ30Yq0dZHe_P3sM9A5g3smyzGAFT=XL_gDh5C8Ayg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 18:23:48 -0000

On Fri, Nov 29, 2013 at 10:13 AM, Nikos Mavrogiannopoulos
<nmav@redhat.com> wrote:
> On Fri, 2013-11-29 at 09:26 -0800, Robert Ransom wrote:
>
>> > You have been quite clear about that, and I've got the impression that you
>> > are the only but very vocal opponent of encrypt-then-mac on this list.
>>
>> Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
>> don't know of any others.
>
> It seems I'll have to repeat that. I don't oppose this draft. I prefer
> an alternative [1], which was not mentioned in the IETF88 meeting. So if
> the question would be AEAD (i.e, not a fix) or encrypt-then-mac, I'd go
> with the latter. If the question is [1] or encrypt-then-mac I'd go with
> the former.
Why do you prefer this alternative?
AEAD is a fix, provided we deploy it. But that isn't happening for
whatever reason.
I suspect that we will soon learn that all fixes do not get deployed
for mysterious reasons.
Solution: get it right the first time.
>
>> > I'm sure you have good reasons for this opposition, so could you
>> please
>> > explain them in one or two sentences. This excluding the "encrypting
>> the
>> > HMAC makes it safer" argument, which might be true but as I
>> understand is
>> > not well proven.
>> "not well proven" is the wrong phrase here.  Marsh Ray solidly
>> debunked it.
>
> I don't quite understand that. No-one questioned his observations in any
> point at any previous discussion. Please review them to understand where
> I stand.
So if HMAC is only a universal hash then HMAC followed by counter mode
is secure, but
HMAC followed by CBC is secure up to a collision of the chaining
value. This analysis assumes
the HMAC falls in a block.

But remember HMAC is essentially H(k||H(k||m)). In particular if the
H(k||m) is a universal hash function,
and H(k||..) satisfies some sort of keyed security assumption (PRF for
fixed length?) HMAC is secure.

So the only way HMAC followed by encrypt is more secure than encrypt
followed by HMAC is if things
break in a really weird way.
Sincerely,
Watson Ladd
>
> regards,
> Nikos
>
> [1].
> http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From juhovh@iki.fi  Fri Nov 29 10:24:19 2013
Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5C1AD948 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSxLOKnTSkbp for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 10:24:17 -0800 (PST)
Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by ietfa.amsl.com (Postfix) with ESMTP id E34F41AD8F6 for <tls@ietf.org>; Fri, 29 Nov 2013 10:24:15 -0800 (PST)
Received: from [10.178.135.118] (85-76-79-104-nat.elisa-mobile.fi [85.76.79.104]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id E0187139621; Fri, 29 Nov 2013 20:24:04 +0200 (EET)
References: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp> <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi> <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CABqy+sqtvqN0+GBiVydC6kKC1au8+0Nsj1xTNt=gyizK5VoNCA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <C24F5F00-9921-4808-9B90-C83FE47EBA7D@iki.fi>
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Fri, 29 Nov 2013 20:20:29 +0200
To: Robert Ransom <rransom.8774@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 18:24:20 -0000

> On 29.11.2013, at 19.26, Robert Ransom <rransom.8774@gmail.com> wrote:
>=20
>> On 11/29/13, Juho V=C3=A4h=C3=A4-Herttua <juhovh@iki.fi> wrote:
>>=20
>> You have been quite clear about that, and I've got the impression that yo=
u
>> are the only but very vocal opponent of encrypt-then-mac on this list.
>=20
> Nikos Mavrogiannopoulos has also been opposed to encrypt-then-HMAC.  I
> don't know of any others.

I understood his opposition was not strong, I think the last comment from hi=
m supports that.

>> I'm sure you have good reasons for this opposition, so could you please
>> explain them in one or two sentences. This excluding the "encrypting the
>> HMAC makes it safer" argument, which might be true but as I understand is=

>> not well proven.
>=20
> "not well proven" is the wrong phrase here.  Marsh Ray solidly debunked it=
.

I was probably being too careful with my words, not being a cryptographer my=
self. But let's change that to "based on current knowledge is debunked" :)

To correct myself a bit more, CBC+HMAC is possible in AEAD by modifying plai=
ntext before encryption as in McGrew et al. draft, but that's not very relev=
ant to the discussion.

> To put it even more bluntly: OS and hardware vendors will treat TLS
> 1.2 or AEAD support and an efficient-in-secure-software AEAD cipher as
> new features, and sit on them for a few *years*.  TLS, and every
> pre-1.2 TLS implementation in the world, needs a critical security
> bugfix *yesterday*, and the only bugfix I see that is ready to be
> deployed as such is draft-gutmann-tls-encrypt-then-mac.

I agree with this, sounds quite likely.


Juho=

From mrex@sap.com  Fri Nov 29 12:17:30 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6371ADDAC for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:17:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.052
X-Spam-Level: 
X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXgUW2eqbu8l for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:17:28 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E5C071ADBCA for <tls@ietf.org>; Fri, 29 Nov 2013 12:17:27 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rATKHElw014512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 21:17:14 +0100 (MET)
In-Reply-To: <37189D49-4190-4DCA-B6E8-C46226D9F51E@iki.fi>
To: =?UTF-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Fri, 29 Nov 2013 21:17:14 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 29 Nov 2013 20:17:30 -0000

Juho V=E4h=E4-Herttua wrote:
>>=20
>> On 29.11.2013, at 18.20, mrex@sap.com (Martin Rex) wrote:
>>=20
>> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
>> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
>> strongly opposed to moving the HMAC into the clear, and into particular
>> I am strongly opposed to put the HMAC into the clear for the
>> GenericStreamCipher PDU.
>=20
> You have been quite clear about that, and I've got the impression that
> you are the only but very vocal opponent of encrypt-then-mac on this list.
> Although in GenericStreamCipher it offers no benefit, I still haven't
> seen a convincing argument about why encrypt-then-mac should not be used.

I'm from the "don't-fix-it-if-it-ain't-broken" camp.
And the less code needs to be changed to adopt some useful feature,
the more likely you will see it being adopted for patches/maintenance.
I have seen *ZERO* compelling reason for switching to encrypt-then-mac
in TLS.  And I'm not aware of *ANY* reason why we should touch/change
the GenericStreamCipher processing (which Peter's proposal does).

I also dislike (a) making a change to SSLv3/TLSv1.0 GenericBlockCipher
processing, but (b) leaving the predictable IV exploited by BEAST
unfixed, and essentially creating two seperate new GenericBlockCipher PDUs,
rather than just a single one for all that fixes all known problems.


>=20
> I'm sure you have good reasons for this opposition, so could you please
> explain them in one or two sentences. This excluding the "encrypting the
> HMAC makes it safer" argument, which might be true but as I understand
> is not well proven.

The fact that GHASH must be encrypted is sufficient proof that an
encrypted MAC provides a better safety margin than a plaintext MAC.

MAC in the clear is only safe when the MAC algorithm is sufficiently
close to perfect.  We know painfully well that our hash algorithms
are *not* perfect, so I'm against taking chances, in particular
for the GenericBlockCipher PDU.


>=20
> > Signaling of this PDU change will be through a new SCSV in ClientHello,
> > confirmation by the Server through a simple ServerHelloExtension, simil=
ar
> > to how signaling is done for rfc5746 (TLS renegotiation_info extension).
>=20
> This might be the only way to solve this problem, but I must point out
> that SCSVs seem to be a solution for everything now. Browsers allow a
> version downgrade attack? Let's add an SCSV. The CBC handling is broken?
> Let's add an SCSV. How many SCSV hacks can we add?

I think we should distinguish between "fixes" and "new features".
Fixes should be as small as possible (code-wise and limited to the
exact problem) so that they have a high chance of getting adopted
for patches/maintenance to the installed base.

Looking at how many new ciphersuites have been proposed over the years,
the number of SCSV proposals IMO pale in comparison.  Even the "silly
ciphersuites" in rfc5246 outnumber the current SCSVs:

(ciphersuites which, according to SP800-57 are non-sensical)

rfc5246:
      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       =3D { 0x00,0x3C };
      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    =3D { 0x00,0x3E };
      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    =3D { 0x00,0x3F };
      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   =3D { 0x00,0x40 };
      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   =3D { 0x00,0x67 };
      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   =3D { 0x00,0x6C };

According to SP800-57, HMAC-SHA1 is perfectly sufficient for combination
with AES128, and this is even more true for encrypted HMAC-SHA1 with
TLS'es GenericBlockCipher PDU.

(btw. the one thing that confuses me about
 NIST SP 800-57 Part1 Rev.3 (July 2012) is that GHASH does not
 appear in Table 3 on page 65.)


>=20
> Adding AEAD support for TLS <1.2 is a good idea and wouldn't require
> hacks, but I'm worried it wouldn't be adopted fast enough.

Partially true.  The footprint for AES-GCM code changes is so large
that it may not happen for code that is under maintenance, rather
than new products.  In particular, AES-GCM will probably require
FIPS 140-2 recertification, whereas a fixing the CBC padding may
not need a recertification (this probably depends on the software
module boundaries).


>
> Especially since CBC+HMAC AEAD ciphers that would be easiest to patch
> are impossible in TLS because of the way AEAD is implemented.

I'm sorry, I fail to follow.  CBC and AEAD seems to be two distinct
modes of encryption and somewhat of a contradiction to each other.

Were you thinking of AES in counter mode with HMAC as MAC?
AFAIK, this could be done with GenericStreamCipher instead.

>=20
> So I prefer fixing CBC first (with encrypt-then-mac unless otherwise
> proven) and then allowing AEAD in all versions to let people prepare
> for GCM in whatever version they use instead of trying to force
> TLS 1.2 upgrade with GCM, it clearly isn't working.

Personally, I trust CBC+HMAC more than I trust GCM.
I have difficulties thinking of weaknesses of the cipher, that when
found, would always affect both CBC and GCM modes.  But not all weaknesses
that are fatal to GCM would also be fatal for CBC.

And we know that our algorithms are not perfect, and that NIST
didn't put much of a security margin into AES -- so little that
AES-256 is known to fall quite short of 256-bit security.


-Martin

From havoc@defuse.ca  Fri Nov 29 12:34:14 2013
Return-Path: <havoc@defuse.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6147F1ADFA3 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r-BLSVqBBgZ for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 12:34:12 -0800 (PST)
Received: from defuse.ca (defuse.ca [192.99.8.82]) by ietfa.amsl.com (Postfix) with ESMTP id CBC961ADDAC for <tls@ietf.org>; Fri, 29 Nov 2013 12:34:12 -0800 (PST)
Received: from [192.168.1.102] (S01065404a6902716.cg.shawcable.net [174.0.254.229]) by defuse.ca (Postfix) with ESMTPSA id 294CC1006B1 for <tls@ietf.org>; Fri, 29 Nov 2013 15:34:23 -0500 (EST)
Message-ID: <5298FA4C.7050803@defuse.ca>
Date: Fri, 29 Nov 2013 13:34:20 -0700
From: Taylor Hornby <havoc@defuse.ca>
Organization: https://defuse.ca/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: tls@ietf.org
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
In-Reply-To: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 20:34:14 -0000

On 11/29/2013 01:17 PM, Martin Rex wrote:
> Juho Vähä-Herttua wrote:
>>>
>>> On 29.11.2013, at 18.20, mrex@sap.com (Martin Rex) wrote:
>>>
>>> I'm perfectly OK with a solution for fixing the mac-pad-encrypt goof
>>> in GenericBlockCipher PDU for all existing versions of TLS, but I'm
>>> strongly opposed to moving the HMAC into the clear, and into particular
>>> I am strongly opposed to put the HMAC into the clear for the
>>> GenericStreamCipher PDU.
>>
>> You have been quite clear about that, and I've got the impression that
>> you are the only but very vocal opponent of encrypt-then-mac on this list.
>> Although in GenericStreamCipher it offers no benefit, I still haven't
>> seen a convincing argument about why encrypt-then-mac should not be used.
> 
> I'm from the "don't-fix-it-if-it-ain't-broken" camp.
> And the less code needs to be changed to adopt some useful feature,
> the more likely you will see it being adopted for patches/maintenance.
> I have seen *ZERO* compelling reason for switching to encrypt-then-mac
> in TLS.  And I'm not aware of *ANY* reason why we should touch/change
> the GenericStreamCipher processing (which Peter's proposal does).

The quantity of code changes isn't all that matters. The complexity and
the elegance of the changes do too.

Often you can fix something with a one-line hack that makes the code
more confusing, or you can re-write the function and do it properly. I
suspect moving to pad-mac-encrypt instead of pad-encrypt-mac is more
like a one-line hack that would actually make implementation harder.
Most of the encryption APIs I've seen do the padding internally, where
you can't access it to compute the MAC.

Also: Won't you still have to use the padding to *find* the MAC in the
ciphertext, in order to check the MAC before you remove the padding? If
so, then a padding oracle is still possible.

[snip]

> 
>>
>> I'm sure you have good reasons for this opposition, so could you please
>> explain them in one or two sentences. This excluding the "encrypting the
>> HMAC makes it safer" argument, which might be true but as I understand
>> is not well proven.
> 
> The fact that GHASH must be encrypted is sufficient proof that an
> encrypted MAC provides a better safety margin than a plaintext MAC.
> 
> MAC in the clear is only safe when the MAC algorithm is sufficiently
> close to perfect.  We know painfully well that our hash algorithms
> are *not* perfect, so I'm against taking chances, in particular
> for the GenericBlockCipher PDU.
> 

I don't follow this logic. MAC functions are evaluated by letting the
adversary see MAC tags and yet still not being able to forge messages.
Making them public does not reduce their security as a MAC... otherwise
they AREN'T MACs.

[snip]

-- 
Taylor Hornby

From mrex@sap.com  Fri Nov 29 13:09:46 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5841AE1DF for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 13:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzQJd45_WZq5 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 13:09:44 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 99C481AE1DE for <tls@ietf.org>; Fri, 29 Nov 2013 13:09:44 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rATL9ehW022873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 22:09:40 +0100 (MET)
In-Reply-To: <5298FA4C.7050803@defuse.ca>
To: Taylor Hornby <havoc@defuse.ca>
Date: Fri, 29 Nov 2013 22:09:40 +0100 (CET)
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: <20131129210940.6EB5E1AB11@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 29 Nov 2013 21:09:46 -0000

Taylor Hornby wrote:
> 
> The quantity of code changes isn't all that matters. The complexity and
> the elegance of the changes do too.

I do not consider seperate new GenericBlockCipher PDUs (one for SSLv3+TLSv1.0
and a seperate one for TLSv1.1+TLSv1.2) particularly elegant, and neither
do I think that leaving the predictable IV in SSLv3+TLSv1.0 is sensical
when we _do_ change that PDU.


> 
> Often you can fix something with a one-line hack that makes the code
> more confusing, or you can re-write the function and do it properly.


> I suspect moving to pad-mac-encrypt instead of pad-encrypt-mac is more
> like a one-line hack that would actually make implementation harder.
> Most of the encryption APIs I've seen do the padding internally, where
> you can't access it to compute the MAC.

Admittedly, I know very few encryption APIs.  The two that I know
offer CBC with both, a function that does PKCS-padding for you,
and one that does not perform padding.
PKCS#11 v2.01 (1997) seems to have both.

There are some applications that use padding other than PKCS-padding.
XMLenc is one example (PKCS-padding is a subset of valid XML-paddings).
 

> 
> Also: Won't you still have to use the padding to *find* the MAC in the
> ciphertext, in order to check the MAC before you remove the padding? If
> so, then a padding oracle is still possible.

Nope.  when using pad-mac-encrypt, then the mac will always be at the end,
and covered by the MAC computation.

-Martin

From juhovh@iki.fi  Fri Nov 29 13:42:53 2013
Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F131ADF27 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 13:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgvJJJT_OJL7 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 13:42:50 -0800 (PST)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4C54C1ADA5D for <tls@ietf.org>; Fri, 29 Nov 2013 13:42:50 -0800 (PST)
Received: from [10.178.135.118] (85-76-77-96-nat.elisa-mobile.fi [85.76.77.96]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 35F41151690; Fri, 29 Nov 2013 23:42:38 +0200 (EET)
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi>
X-Mailer: iPhone Mail (11B554a)
From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Fri, 29 Nov 2013 23:38:58 +0200
To: "mrex@sap.com" <mrex@sap.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Nikos Mavrogiannopoulos <nmav@gnutls.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 21:42:53 -0000

> On 29.11.2013, at 22.17, mrex@sap.com (Martin Rex) wrote:
>=20
> I'm from the "don't-fix-it-if-it-ain't-broken" camp.
> And the less code needs to be changed to adopt some useful feature,
> the more likely you will see it being adopted for patches/maintenance.
> I have seen *ZERO* compelling reason for switching to encrypt-then-mac
> in TLS.  And I'm not aware of *ANY* reason why we should touch/change
> the GenericStreamCipher processing (which Peter's proposal does).

I'm trying to explain my reasoning. First of all HMACs are designed to authe=
nticate data safely, but encrypting them adds an unknown factor to the calcu=
lation. Why not just use them as they are supposed to be used.

For me it is much more intuitive to do pad-encrypt-mac compared to attack re=
sistant pad-mac-encrypt. In current TLS spec you can give the plaintext+HMAC=
 to the encryptor as is and let it handle the padding. The same is true for e=
ncrypt-then-mac, just give the plaintext to the encryptor (either CBC or str=
eam) and let it handle the padding. But in pad-mac-encrypt you have to know t=
he length of the MAC before you actually calculate the MAC and add it manual=
ly! This is counter intuitive.

Finally, encrypt-then-mac allows detection of tampering in an earlier stage,=
 which is a plus in my books.

> I also dislike (a) making a change to SSLv3/TLSv1.0 GenericBlockCipher
> processing, but (b) leaving the predictable IV exploited by BEAST
> unfixed, and essentially creating two seperate new GenericBlockCipher PDUs=
,
> rather than just a single one for all that fixes all known problems.

Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a very=
 small update to TLSv1, so one could always ask why is it not supported bett=
er. Is the version number change somehow scary to people?

That being said, I would support adding explicit IV to the encrypt-then-mac s=
pec, unless we have reason to think it would slow down adoption. Personally I=
 don't see how a block of random numbers would be too difficult.

Nikos, do you think you should combine the pad and the IV in the defined str=
ucts? It would fix the BEAST attack at the same time even in SSLv3...

> The fact that GHASH must be encrypted is sufficient proof that an
> encrypted MAC provides a better safety margin than a plaintext MAC.

I don't think GHASH behaviour proves anything about HMACs, but please prove m=
e wrong.

> MAC in the clear is only safe when the MAC algorithm is sufficiently
> close to perfect.  We know painfully well that our hash algorithms
> are *not* perfect, so I'm against taking chances, in particular
> for the GenericBlockCipher PDU.

But in a VERY hypothetical case where attacks to some HMAC is found, we woul=
d have no idea how it affects TLS without further analysis, using it in a st=
andard way would at least give more information about what is broken. And of=
 course HMAC is not just a hash.

>> Let's add an SCSV. How many SCSV hacks can we add?
>=20
> I think we should distinguish between "fixes" and "new features".
> Fixes should be as small as possible (code-wise and limited to the
> exact problem) so that they have a high chance of getting adopted
> for patches/maintenance to the installed base.

I kind of find this comment contradicting with the "we should fix all known i=
ssues (BEAST) in a single patch" comment. But I admit SCSVs are a necessary e=
vil because of compatibility issues. It just makes me feel dirty...

>> Adding AEAD support for TLS <1.2 is a good idea and wouldn't require
>> hacks, but I'm worried it wouldn't be adopted fast enough.
>=20
> Partially true.  The footprint for AES-GCM code changes is so large
> that it may not happen for code that is under maintenance, rather
> than new products.  In particular,

Actually I wasn't talking about GCM which, as you say, is quite large.

>> Especially since CBC+HMAC AEAD ciphers that would be easiest to patch
>> are impossible in TLS because of the way AEAD is implemented.
>=20
> I'm sorry, I fail to follow.  CBC and AEAD seems to be two distinct
> modes of encryption and somewhat of a contradiction to each other.

I was thinking something like http://tools.ietf.org/html/draft-mcgrew-aead-a=
es-cbc-hmac-sha2-02 . It defines an AEAD CBC+HMAC mode which fixes all the k=
nown issues at once, as you suggested, but I find the padding outside of AEA=
D a bit of a hack. It is necessary only because we need to know the plaintex=
t length in TLS AEAD interface _before_ decryption.

But getting people to accept an AEAD patch (just because it sounds scary if n=
othing else) is probably hard. I can understand why the chairs would like to=
 go this "cleaner" route to fix CBC though.


Juho


From mrex@sap.com  Fri Nov 29 13:45:41 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCDC1AE06F for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 13:45:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8DqPnVMJVT5 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 13:45:38 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 63C411ADA5D for <tls@ietf.org>; Fri, 29 Nov 2013 13:45:38 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rATLjXnK005367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 22:45:33 +0100 (MET)
In-Reply-To: <CAJU7zaLsJe-B3gOF9BrROKPeLSvbNdM9RzJgYxRAZtBWofc8ew@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Fri, 29 Nov 2013 22:45:32 +0100 (CET)
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: <20131129214532.F2D361AB11@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] draft-mavrogiannopoulos-new-tls-padding-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 29 Nov 2013 21:45:41 -0000

Nikos Mavrogiannopoulos wrote:
> 
> http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00
 
If you leave the fixing (and changing) of the Cipher PDUs alone,
you could alternatively pursue a "random padding" by simply defining
an (anti-)compression algorithm to that effect, with whatever semantics you
desire.  This might also fit smoother with implementations.

The hard limit that your fancy (anti-)compression algorithm will
have to observe from the TLS specs,
  e.g. http://tools.ietf.org/html/rfc5246#section-6.2.2

is that the output of your (anti-)compression must not exceed 2^14+1024
bytes.

The "may not increase the content length by more than 1024 bytes" rule
is more of a soft rule that can be adjusted by the (anti-)compression
algorithm spec as long as the "the output must not exceed 2^14+1024"
hard rule is obeyed.

-Martin

From mrex@sap.com  Fri Nov 29 15:08:05 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896FD1AE04D for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.252
X-Spam-Level: 
X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GY1iwzaWvvET for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:08:03 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 47ADB1AD937 for <tls@ietf.org>; Fri, 29 Nov 2013 15:08:03 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id rATN7osS013930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 00:07:50 +0100 (MET)
In-Reply-To: <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi>
To: =?UTF-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= <juhovh@iki.fi>
Date: Sat, 30 Nov 2013 00:07:49 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20131129230749.E124B1AB10@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>, Nikos Mavrogiannopoulos <nmav@gnutls.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 29 Nov 2013 23:08:05 -0000

Juho V=E4h=E4-Herttua wrote:
>=20
> mrex@sap.com (Martin Rex) wrote:
> >=20
> > I'm from the "don't-fix-it-if-it-ain't-broken" camp.
> > And the less code needs to be changed to adopt some useful feature,
> > the more likely you will see it being adopted for patches/maintenance.
> > I have seen *ZERO* compelling reason for switching to encrypt-then-mac
> > in TLS.  And I'm not aware of *ANY* reason why we should touch/change
> > the GenericStreamCipher processing (which Peter's proposal does).
>=20
> I'm trying to explain my reasoning.  First of all HMACs are designed
> to authenticate data safely, but encrypting them adds an unknown
> factor to the calculation.  Why not just use them as they are
> supposed to be used.

There is nothing "unknown" about encryption, and certainly it will not
dillute the MAC (unless you come up with a bogus encryption scheme that
is not bijective--i.e. expands the data during encryption.

Keep in mind that encrypted MAC is what SSL&TLS have always been doing,
and what a number of implementations will continue to be doing for many
years to come.

If this had been the other way round, i.e. SSLv3 and TLS had been using
encrypt-then-mac, then I would not be asking to change it _unless_
a _real_ problem was demonstrated, and for the very same reasons
(don't fix it if it ain't broken, smaller code changes are more likely
to get adopted during maintenance).


>=20
> For me it is much more intuitive to do pad-encrypt-mac compared to attack
> resistant pad-mac-encrypt. In current TLS spec you can give the
> plaintext+HMAC to the encryptor as is and let it handle the padding.

In current TLS, you pass the plaintext to the record layer, and the
record layer will pipe it thorugh the compression function and
pass it to the pad+mac+encrypt function.

>
> The same is true for encrypt-then-mac, just give the plaintext to the
> encryptor (either CBC or stream) and let it handle the padding.
> But in pad-mac-encrypt you have to know the length of the MAC before
> you actually calculate the MAC and add it manually! This is counter
> intuitive.

Actually, in TLS you have to _know_ the size of the MAC long before you
process the first record, because it is part of the Connection state:

  http://tools.ietf.org/html/rfc2246#section-6.1

   MAC algorithm
       An algorithm to be used for message authentication. This
       specification includes the size of the hash which is returned by
       the MAC algorithm.

Since compression algorithms other than the null compression will
usually have an output size different from the plaintext input size,
the size of the mac and the exact amount of padding is something
internal to the TLS record layer.  The caller above the record
layer doesn't need to know and doesn't need to care.


>=20
> Finally, encrypt-then-mac allows detection of tampering in an earlier
> stage, which is a plus in my books.

This is entirely irrelevant in the real world (for TLS).
You have to successfully go through a full TLS handshake before you can
mess around here, and the public key stuff during the full handshake
is so much harder on the honest server, that this is a lame argument.


>=20
> > The fact that GHASH must be encrypted is sufficient proof that an
> > encrypted MAC provides a better safety margin than a plaintext MAC.
>=20
> I don't think GHASH behaviour proves anything about HMACs,
> but please prove me wrong.

It does.  Why do you think that HMAC is better than a simple keyed hash?
because it doesn't make the output of the keyed hash directly accessible
to the attacker.  This immediately transcends from the definition of HMAC,

  http://tools.ietf.org/html/rfc2104#section-2

  H(K XOR opad, H(K XOR ipad, text))

and the rationale behind HMAC:

  http://tools.ietf.org/html/rfc2104#section-6

   6. Security

   The security of the message authentication mechanism presented here
   depends on cryptographic properties of the hash function H: the
   resistance to collision finding (limited to the case where the
   initial value is secret and random, and where the output of the
   function is not explicitly available to the attacker)

The "output of the function that is not explicitly available to the attacke=
r"
is the output of the inner Hash function of the HMAC function.

It has the exact same output size as the output of the outer hash function.
Under given the assumption that H is "collision resistant", the outer
Hash-function of HMAC is equivalent to a symmetric encryption of
a block cipher with the blocksize of the hash size and the key "K".

Encrypting this the HMAC output again with a symmetric block cipher
is not going to weaken the resulting strength, but may strengthen it
when the properties of H are not as good as one might like.


>=20
> > MAC in the clear is only safe when the MAC algorithm is sufficiently
> > close to perfect.  We know painfully well that our hash algorithms
> > are *not* perfect, so I'm against taking chances, in particular
> > for the GenericBlockCipher PDU.
>=20
> But in a VERY hypothetical case where attacks to some HMAC is found,
> we would have no idea how it affects TLS without further analysis,
> using it in a standard way would at least give more information about
> what is broken. And of course HMAC is not just a hash.

The security of HMAC is vitally dependent on the security of the underlying
hash function.

IIRC, The first weakness demonstrated for MD5 (by Dobbertin) were
modifications of two bits that cancelled each other out for a
specific internal state of the MD5 hash.  Later, methods were discovered
to compute two plaintexts that will have the same hash result for
arbitrary internal state.

What would be devastating for pad-encrypt-hmac is when a method was found
to find bit modifications that cancel each other out with little or no
dependence on the internal state of the hash.  This would immediately
and seriously affect all pad-encrypt-hmac schemes with that hash, the AEAD
and GenericStreamCipher schemes independent of encrypt-mac or mac-encrypt.

GenericBlockCipher with pad-mac-encrypt will be significantly less
impacted, because flipping specific bits on the plaintext (the data
that is mac'ed in pad-mac-encrypt) will only be possible if the
BlockCipher is broken as well.


-Martin

From nmav@redhat.com  Fri Nov 29 15:22:49 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475251AE066 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.603
X-Spam-Level: 
X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzb2iQBMKJ1e for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:22:47 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 878B11ADFFE for <tls@ietf.org>; Fri, 29 Nov 2013 15:22:47 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rATNMfp6026133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 18:22:41 -0500
Received: from [10.10.62.14] (vpn-62-14.rdu2.redhat.com [10.10.62.14]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rATNMcP0023394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 18:22:39 -0500
Message-ID: <1385767358.5937.18.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Juho =?ISO-8859-1?Q?V=E4h=E4-Herttua?= <juhovh@iki.fi>
Date: Sat, 30 Nov 2013 00:22:38 +0100
In-Reply-To: <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi>
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp> <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 23:22:49 -0000

On Fri, 2013-11-29 at 23:38 +0200, Juho Vähä-Herttua wrote:

> > I also dislike (a) making a change to SSLv3/TLSv1.0
> GenericBlockCipher > processing, but (b) leaving the predictable IV
> exploited by BEAST > unfixed, and essentially creating two seperate new
> GenericBlockCipher PDUs, > rather than just a single one for all that
> fixes all known problems.
> 
> Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a
> very small update to TLSv1, so one could always ask why is it not
> supported better. Is the version number change somehow scary to people?

At the time of TLS 1.1, it was not known that a big number of TLS
implementations were not able to properly do TLS version negotiation and
handle gracefully a TLS version downgrade. In gnutls after we added TLS
1.1 we realized that enabling it would make the library unable to talk
to several (prominent at the time) servers. So I presume that this
compatibility issue and the fact that there was no popular demand (which
occurred only after the media hype with the beast attack), very few
bothered to implement it.

> That being said, I would support adding explicit IV to the
> encrypt-then-mac spec, unless we have reason to think it would slow
> down adoption. Personally I don't see how a block of random numbers
> would be too difficult.
> 
> Nikos, do you think you should combine the pad and the IV in the
> defined structs? It would fix the BEAST attack at the same time even in
> SSLv3...

Certainly the draft (or any other fix) could require that the TLS 1.1
explicit IV in CBC ciphersuites is used when used with TLS 1.0 or
earlier (although, that would make the protocol messier, it looks it
provides quite some advantages).

> > MAC in the clear is only safe when the MAC algorithm is sufficiently
> > close to perfect.  We know painfully well that our hash algorithms >
> are *not* perfect, so I'm against taking chances, in particular > for
> the GenericBlockCipher PDU.
> But in a VERY hypothetical case where attacks to some HMAC is found, we
> would have no idea how it affects TLS without further analysis, using
> it in a standard way would at least give more information about what is
> broken. And of course HMAC is not just a hash.

Contrary to popular opinion on this list AtE is a standard way of
operation with no flaws known unless used with an unauthenticated pad
(as in TLS). When SSL 3.0 was designed AtE was believed to be the
conservative approach comparing to EtA.

regards,
Nikos



From nmav@redhat.com  Fri Nov 29 15:32:26 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07301ADFB8 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:32:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMZotbg3TEzU for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:32:25 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5253B1ADF76 for <tls@ietf.org>; Fri, 29 Nov 2013 15:32:25 -0800 (PST)
Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rATNWNGI021071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Nov 2013 18:32:23 -0500
Received: from [10.10.62.14] (vpn-62-14.rdu2.redhat.com [10.10.62.14]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rATNWL7P000429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Nov 2013 18:32:22 -0500
Message-ID: <1385767940.5937.25.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: mrex@sap.com
Date: Sat, 30 Nov 2013 00:32:20 +0100
In-Reply-To: <20131129214532.F2D361AB11@ld9781.wdf.sap.corp>
References: <20131129214532.F2D361AB11@ld9781.wdf.sap.corp>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-mavrogiannopoulos-new-tls-padding-00
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 23:32:26 -0000

On Fri, 2013-11-29 at 22:45 +0100, Martin Rex wrote:

> > http://tools.ietf.org/html/draft-mavrogiannopoulos-new-tls-padding-00
>  
> If you leave the fixing (and changing) of the Cipher PDUs alone,
> you could alternatively pursue a "random padding" by simply defining
> an (anti-)compression algorithm to that effect, with whatever semantics you
> desire.  This might also fit smoother with implementations.
> 
> The hard limit that your fancy (anti-)compression algorithm will
> have to observe from the TLS specs,
>   e.g. http://tools.ietf.org/html/rfc5246#section-6.2.2
> 
> is that the output of your (anti-)compression must not exceed 2^14+1024
> bytes.
> The "may not increase the content length by more than 1024 bytes" rule
> is more of a soft rule that can be adjusted by the (anti-)compression
> algorithm spec as long as the "the output must not exceed 2^14+1024"
> hard rule is obeyed.

That's a pretty clever observation, and would be of quite use if the new
padding mechanism is not used. Note however, that one would want to keep
a uniform size in records and padding should be within the 2^14 limit
(or the max data limit); otherwise it may be of little use in hiding the
length.

regards,
Nikos



From luto@amacapital.net  Fri Nov 29 15:36:07 2013
Return-Path: <luto@amacapital.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1831ADF76 for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TsaxUtYn9WQ for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 15:36:05 -0800 (PST)
Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FD1AE087 for <tls@ietf.org>; Fri, 29 Nov 2013 15:36:05 -0800 (PST)
Received: by mail-vc0-f173.google.com with SMTP id ia6so7145529vcb.32 for <tls@ietf.org>; Fri, 29 Nov 2013 15:36:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yhtfrdgPIOcIO4GtPrZnPAiMm9XRvLO4KlU6JdWy3tQ=; b=fPMoMA+B/HqEpOaJcnZW14g3FP86yTHrglzxp6ej+DCbhr502NNJKiIkWZjSXGBdtc dW5wf8FGzq+7I115PLn34xRGJfQ33ekpI+DwAOwAdMbuWNW7lDq5J6Zv21YbXkOqcO74 rDG3yQWMZnp7BLW5Ni2io0Hu+wpCPehHgOeHy4GoiSe8RfdBSrMPFRWfg12NZ6AHrY7B rNfLNG3CVmceWGpE2wlfBZ02hJHGNbNAylDopCLYpQFDQIzllZGhidzyZ1ejeMNjCk9p 3r78VHGmL5pQzft5B+4A34w1Yw4ACISpc9ZNi3mgBEZrghnfLswyk5AhIScwfBGxOWeR YjVw==
X-Gm-Message-State: ALoCoQkO5W5eJopTg3/RCk+HPYazGgFxbar+KhbbpS0HapSh5vZIYVUmy3zHBFNaVnMgORQ8kOmi
X-Received: by 10.52.98.132 with SMTP id ei4mr138541vdb.62.1385768163628; Fri, 29 Nov 2013 15:36:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Fri, 29 Nov 2013 15:35:43 -0800 (PST)
In-Reply-To: <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com>
References: <CAPMEXDbgp5+Gg6mkMWNrcOzmAbSpv3kjftGV0cjpqvMnRxpw=A@mail.gmail.com> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <CACsn0c=9GrO21ECZczB2zft3bVODcc=1ZRp3pG22c-rrDfTPXQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <CAM_a8Jy_x-qZFdpxsLMnFjuYeAJBwqNqQLrnsAcf05GU5PuJfw@mail.gmail.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <CALCETrU0sN+dUGQ60v96hndKx_=7xUpgmxATtDVPJ3DqyGnbqA@mail.gmail.com> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 29 Nov 2013 15:35:43 -0800
Message-ID: <CALCETrWDOiNg9At4J_F3EEPW7MPcszSnzBSqpNyHNKd8VZn-eQ@mail.gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Patrick Pelletier <code@funwithsoftware.org>, "tls@ietf.org" <tls@ietf.org>, GnuTLS development list <gnutls-devel@lists.gnutls.org>
Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed)
X-BeenThere: tls@ietf.org
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." <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: Fri, 29 Nov 2013 23:36:07 -0000

On Thu, Nov 28, 2013 at 1:10 AM, Nikos Mavrogiannopoulos
<nmav@redhat.com> wrote:
> On Wed, 2013-11-27 at 17:54 -0600, Nico Williams wrote:
>> All of this is off-topic for this list.  I'll post a reply anyways, and
>> I apologize to the list.
>>
>> On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote:
>> >                     [...].  gnutls_global_init is documented as being
>> > unsafe if called from multiple threads, which seems silly.
>> Initialization is not thread-safe in OpenSSL either.  This is a terrible
>> thing.  It *can* be made thread-safe, so there's no excuse for it not
>> being thread-safe.
> Hello,
>  I don't understand why this is an issue since it is documented. If a
> function (like a global initialization function) is supposed to create
> the mutexes for the rest of the library functions it cannot be expected
> to be thread safe; at least in a portable way since static
> initialization of mutexes is not a portable thing.
>
> Nevertheless, even if you really need to call a global initialization
> function in every thread you create (I really don't see why), you can
> simply call it in a locked mutex.

No, I can't.  I occasionally use libraries, and those libraries in
turn use GnuTLS.  Requiring those libraries to force their users to
synchronize their initialization of GnuTLS sucks.

If GnuTLS really must use global state in a manner that isn't
transparent to its users, it should get the synchronization right.

Any self-respecting pthreads implementation should implement
PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes
its data, making it completely safe.  An even better solution would be
to use pthread_once.


--Andy

From watsonbladd@gmail.com  Fri Nov 29 17:23:06 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37411AE23D for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 17:23:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GXFPgdwvVWp for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 17:23:04 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 403DD1AE067 for <tls@ietf.org>; Fri, 29 Nov 2013 17:23:04 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id u57so4180219wes.23 for <tls@ietf.org>; Fri, 29 Nov 2013 17:23:02 -0800 (PST)
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:content-transfer-encoding; bh=PnjaYv5XF4zGEq2lA1MX2QVFOOX//9aBpJet7MGvuds=; b=WFcAurp7Q6e//4U6YgbSanuUbRQkoLrfXYDrNZ0b01lVbwLU8QBX42OXkvLjIQtSLj M8exYMoj93JZJTPcAr2LhmNRf7crL9dFahdWwp48zZrAB0hHJcANZefFLgeJCeZaMvVh V0hH9sdUaLgT955gSRMKdpxmRHsKhDUcqHaMrQdO3imhLoOQRaS5TqmmiWTYIXwgrtGM 2Tiyp/Ofi8sKPNddWkt+yPoR2Edfj1iVLe45Qz2iNYqNF1i16oTdKQ3UkTS62nHtX7cZ IX5/O8mkG0mo3Co+Ho3H0Hprz5HK6iTvHH2TO9ZsJ06Mm9bSHJiMd+4LHY9fcMqmJuCV xvnQ==
MIME-Version: 1.0
X-Received: by 10.180.36.105 with SMTP id p9mr8908088wij.58.1385774582267; Fri, 29 Nov 2013 17:23:02 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Fri, 29 Nov 2013 17:23:02 -0800 (PST)
In-Reply-To: <1385767358.5937.18.camel@aspire.lan>
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp> <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi> <1385767358.5937.18.camel@aspire.lan>
Date: Fri, 29 Nov 2013 17:23:02 -0800
Message-ID: <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 01:23:06 -0000

On Fri, Nov 29, 2013 at 3:22 PM, Nikos Mavrogiannopoulos
<nmav@redhat.com> wrote:
> On Fri, 2013-11-29 at 23:38 +0200, Juho V=C3=A4h=C3=A4-Herttua wrote:
>
>> > I also dislike (a) making a change to SSLv3/TLSv1.0
>> GenericBlockCipher > processing, but (b) leaving the predictable IV
>> exploited by BEAST > unfixed, and essentially creating two seperate new
>> GenericBlockCipher PDUs, > rather than just a single one for all that
>> fixes all known problems.
>>
>> Ok, this is a valid point I have missed in the discussion. TLSv1.1 is a
>> very small update to TLSv1, so one could always ask why is it not
>> supported better. Is the version number change somehow scary to people?
>
> At the time of TLS 1.1, it was not known that a big number of TLS
> implementations were not able to properly do TLS version negotiation and
> handle gracefully a TLS version downgrade. In gnutls after we added TLS
> 1.1 we realized that enabling it would make the library unable to talk
> to several (prominent at the time) servers. So I presume that this
> compatibility issue and the fact that there was no popular demand (which
> occurred only after the media hype with the beast attack), very few
> bothered to implement it.
>
>> That being said, I would support adding explicit IV to the
>> encrypt-then-mac spec, unless we have reason to think it would slow
>> down adoption. Personally I don't see how a block of random numbers
>> would be too difficult.
>>
>> Nikos, do you think you should combine the pad and the IV in the
>> defined structs? It would fix the BEAST attack at the same time even in
>> SSLv3...
1/n-1 record splitting needs to be implemented anyway, thanks to the
installed base.
>
> Certainly the draft (or any other fix) could require that the TLS 1.1
> explicit IV in CBC ciphersuites is used when used with TLS 1.0 or
> earlier (although, that would make the protocol messier, it looks it
> provides quite some advantages).
>
>> > MAC in the clear is only safe when the MAC algorithm is sufficiently
>> > close to perfect.  We know painfully well that our hash algorithms >
>> are *not* perfect, so I'm against taking chances, in particular > for
>> the GenericBlockCipher PDU.
>> But in a VERY hypothetical case where attacks to some HMAC is found, we
>> would have no idea how it affects TLS without further analysis, using
>> it in a standard way would at least give more information about what is
>> broken. And of course HMAC is not just a hash.
>
> Contrary to popular opinion on this list AtE is a standard way of
> operation with no flaws known unless used with an unauthenticated pad
> (as in TLS). When SSL 3.0 was designed AtE was believed to be the
> conservative approach comparing to EtA.
The passive voice is doing a lot of work here. Bellare and Namparah
showed that EtA is generically secure,
AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
"no flaws known"!=3D"proved to be secure"
AtE works only if the encryption and decryption functions are
bijective, as in stream cipher mode. Otherwise you have
an oracle. For CBC you restrict the message space to messages
multiples of the blocksize. But really, this is quibbling about
the color of a fence, rather than building it. Marsh Ray already
addressed these issues to the point where only the most blockheaded
would refuse to listen.

Furthermore, proliferating a mess of extensions and half-assed fixes
makes driving adoption of updates even harder.
The right to proceed is to provide something like a one round
protocol, that is secure, with no options, and sell adoption
on the new features. By making improved security contingent on TLS 1.2
adoption, we screwed ourselves over. But if what
results in a frankenprotocol on top of SSL 3.0, it might be better to
include a IM_OUTTA_HERE cipher which instructs the
recipient to do something sane instead.

Something needs to be done about the issues of TLS. It's clear there
is no consensus on this list, but doing nothing is not an option.
Personally, driving to TLS 1.2 avoids the need to deploy a long series
of patches, as well as design fixes and analyze them.
>
> regards,
> Nikos
Sincerely,
Watson Ladd
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From mrex@sap.com  Fri Nov 29 17:45:03 2013
Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5328B1AE29F for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 17:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYXdTq5OI61Z for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 17:45:01 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0B1AE267 for <tls@ietf.org>; Fri, 29 Nov 2013 17:45:00 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAU1inMI019067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 02:44:49 +0100 (MET)
In-Reply-To: <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 30 Nov 2013 02:44:49 +0100 (CET)
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: <20131130014449.760781AB10@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Sat, 30 Nov 2013 01:45:03 -0000

Watson Ladd wrote:
> 
> Something needs to be done about the issues of TLS. It's clear there
> is no consensus on this list, but doing nothing is not an option.
> Personally, driving to TLS 1.2 avoids the need to deploy a long series
> of patches, as well as design fixes and analyze them.

TLSv1.2 is a royal PITA for TLS clients, because it requires a reconnect
fallback facility to be implemented by ***EVERY*** application caller
client on top of TLS, ***PLUS*** every application caller will have to
memorize the fallback for every destination or the latency will be a
royal pain for every new handshake after the TLS session expires
from the client-side TLS session cache (when client-side session
caching is used at all.  Client-side TLS session caching seems to be
much less common in programmatic clients than I would have expected).

In addition, that fallback reconnect subjects the caller to a downgrade
vulnerability when those ciphersuites that are (apparently) considered
secure or preferable can not be proposed&negotiated when doing a fallback
reconnect.  Bodo and Adam think the downgrade issue of fallback reconnects
is sufficiently severe that it needs immediate Working Group action,
whereas I believe it would be much more reasonable to make the
negotiation of the desired security strength succeed even on a
TLS-version-downgraded handshake, because it would benefit everyone,
in particular the programmatic clients without a fallback reconnect
facility, and it would give better results in the face of dense
middle boxes.

The proposed "Server please Abort on Downgrade detection" will
lead to lots of end user nuisance, and the end user and IT help desk
work around will be to disable TLSv1.1 & TLSv1.2 in the browser,
both of which is squarely against the IETF spirit to promote
interop.


-Martin

From p.gutmann@auckland.ac.nz  Fri Nov 29 20:07:13 2013
Return-Path: <p.gutmann@auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FC71AE0BE for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 20:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3aUBedCXvaG for <tls@ietfa.amsl.com>; Fri, 29 Nov 2013 20:07:10 -0800 (PST)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 869001AE0B7 for <tls@ietf.org>; Fri, 29 Nov 2013 20:07:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1385784430; x=1417320430; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7Aw+Se81RcLwrPILCIPicBGl8rVNDrMzGs2ztn6Tle8=; b=bETEtIY04Li4R8r/eV9KFKaKsnCj7W5xKaCy0cqA58qOfZFNOx0kHEqa iGV3LEF4eSnUW60V984Iv/18POdLF2LZk+PTGCoTCL6OXFwPyApHk1F1P JTal6zhq78oSMFreVO6GA0RiRaw/zsjRytrsMKLd+IOMJ3TvDLQK/wiD1 Q=;
X-IronPort-AV: E=Sophos;i="4.93,799,1378814400"; d="scan'208";a="295975695"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Nov 2013 17:07:07 +1300
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.231]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Sat, 30 Nov 2013 17:07:06 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: Andy Lutomirski <luto@amacapital.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: Ac7tgaI4JNMJgY4tTJiGdHxlQRXsDg==
Date: Sat, 30 Nov 2013 04:07:06 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C736542186C@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 04:07:14 -0000

Andy Lutomirski <luto@amacapital.net> writes:=0A=
=0A=
>Not at all.  I didn't say "bundled set of trust roots;" I said "explicitly=
=0A=
>chosen".=0A=
=0A=
We already have explicitly-chosen trust roots, they're chosen by the browse=
r=0A=
vendors.  Or are you expecting granny to select CAs herself?  And once you'=
ve=0A=
decided to "trust" enough CAs to make the web usable, how do you deal with =
the=0A=
fact that many of these same CAs will happily sell their certs to phishers,=
=0A=
drive-by download sites, and all the other stuff that they're supposed to b=
e=0A=
protecting us from?=0A=
=0A=
>Do you really think that "completely insecure against active attack" is a=
=0A=
>good option?=0A=
=0A=
No, but I don't see what that has to do with trusting or not trusting CAs.=
=0A=
=0A=
Peter.=0A=

From nmav@redhat.com  Sat Nov 30 08:00:24 2013
Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E31AE44E for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 08:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level: 
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK6Nbabx61-w for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 08:00:22 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 606221AE454 for <tls@ietf.org>; Sat, 30 Nov 2013 08:00:22 -0800 (PST)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAUFo3s4030048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Nov 2013 10:50:05 -0500
Received: from [10.10.55.105] (vpn-55-105.rdu2.redhat.com [10.10.55.105]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAUFo0rG019640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Nov 2013 10:50:01 -0500
Message-ID: <1385826600.11639.25.camel@aspire.lan>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 30 Nov 2013 16:50:00 +0100
In-Reply-To: <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
References: <20131129201714.A6B031AB11@ld9781.wdf.sap.corp> <073259DE-D4EB-4229-945D-97CD5AF50A3C@iki.fi> <1385767358.5937.18.camel@aspire.lan> <CACsn0ckVhZV=JeQ10Uv9ESLvAO9C9V1or72-DqC6Vjh1cWm7aQ@mail.gmail.com>
Organization: Red Hat
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 16:00:24 -0000

On Fri, 2013-11-29 at 17:23 -0800, Watson Ladd wrote:

> > Contrary to popular opinion on this list AtE is a standard way of
> > operation with no flaws known unless used with an unauthenticated pad
> > (as in TLS). When SSL 3.0 was designed AtE was believed to be the
> > conservative approach comparing to EtA.
> The passive voice is doing a lot of work here. Bellare and Namparah
> showed that EtA is generically secure,
> AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
> "no flaws known"!="proved to be secure"

Proven to be secure doesn't mean that attacks don't exist. The TLS
padding scheme was proven to be secure prior to be broken; ironically by
the same person who made the proof. Attacks work by playing outside the
requirements of the proof.

Nevertheless, there is much more recent work on EtA vs AtE, that
actually proves AtE secure (not "generically" as you pose, you just need
a decent cipher). You may check "The order of encryption and
authentication for protecting communications (or: How secure is SSL?)".
There are even newer papers than that, it is just this that came to
mind.

regards,
Nikos



From alfredo@pironti.eu  Sat Nov 30 09:25:16 2013
Return-Path: <alfredo@pironti.eu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE761AE472 for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcCO-iHGWuqS for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:25:15 -0800 (PST)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2241AE471 for <tls@ietf.org>; Sat, 30 Nov 2013 09:25:14 -0800 (PST)
Received: by mail-oa0-f47.google.com with SMTP id k1so11452014oag.20 for <tls@ietf.org>; Sat, 30 Nov 2013 09:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BbcsTUVmUZRzgylWFRFFf+7k/KxdyP+emnyOcjKDQso=; b=NaEnJEPLAoGTPi48cXgRLvrWLBzaOOz0s3d3AvorCjAgoCKuwHhGZF317KIuPdrgTy RMjl/plh786lnDV9X9QIy8wqeQRldWO2lnZk/iiOQLCbDGYisdwvTadqFf3bR30CEEvw ZpSGwrEHeapKHwBXtNmorLUjFNJMby7znpZK0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=BbcsTUVmUZRzgylWFRFFf+7k/KxdyP+emnyOcjKDQso=; b=TdOshGYXUCmCd3bBb7c7r8JxVvD4pndky1xNmlFzT98jiB7ZNSlv4VKXB+72XA9CaG OMtYTGoFRHE8AVIMz7yXVjIiLhdVien+Wbwr7OjMU2B7ZvxvKzXopRcd6mDClElWx8Lg wxlBpJyH57qavzeIdFYmTGDoFh9kRGjUcC/S6k0jy1gSR/+EtcKDvrihvBIzPb/Pv7Af g7lz977pKvtnerPiMsfkB1ikJIxI7gOgLS6GTuem4EsaxAcsZD+nugq8fQ6DtCrVJJLs YYoCKBnUHTk6CN/arFYmRkeA1XKrmUrphElJLBkCEv5NBl+358/M/zJw2kSHCuVcBkF+ U/cg==
X-Gm-Message-State: ALoCoQl3m7tri/gsQkdXZKxAsz5C6b4ifT+7/Um339DjTr/rxb3sMz+o/4djs3KR285CXx2M28PB
MIME-Version: 1.0
X-Received: by 10.60.56.3 with SMTP id w3mr29364298oep.37.1385832312900; Sat, 30 Nov 2013 09:25:12 -0800 (PST)
Received: by 10.76.114.194 with HTTP; Sat, 30 Nov 2013 09:25:12 -0800 (PST)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
References: <9A043F3CF02CD34C8E74AC1594475C7365420C29@uxcn10-6.UoA.auckland.ac.nz> <20131129162025.83A731AB0E@ld9781.wdf.sap.corp>
Date: Sat, 30 Nov 2013 18:25:12 +0100
Message-ID: <CALR0ui+Ao6cd0h94W=0Yovs57hNCYL-bqqNwWa00T3kWDW1SgA@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 17:25:16 -0000

>
> I'm going to prepare a proposal I-D to do exactly (and only) what
> Serge Vaudenay had recommended in 2001, and what TLSv1.1 failed to fix,
> change mac-pad-encrypt into pad-mac-encrypt for the GenericBlockCipher PDU.
> When doing this, we can also consistently adopt the explicit random IV
> (which can be implemented as a random confounder) to all versions of TLS.

Please don't!
I think [1] does just what you're asking for. With 2 differences we
can agree upon:
1) Adding explicit IVs everywhere is a nice idea, and I'm up to add it
to the I-D.
2) If the paragraphs on non-GenericBlockCiphers really annoy you, just
ignore them.
To get a compliant implementation with non-block ciphers, all you have to do
is to add a 2-bytes empty vector to user data when sending, and parsing it when
receiving. All TLS implementations have a function for this, and it's
then a 2-lines patch.

>
> Signaling of this PDU change will be through a new SCSV in ClientHello,
> confirmation by the Server through a simple ServerHelloExtension, similar
> to how signaling is done for rfc5746 (TLS renegotiation_info extension).

I disagree with this. The more we add SSL3-compatible hacks, the more excuses
we give to vendors and to this WG to keep using SSL3.

[1] http://tools.ietf.org/search/draft-mavrogiannopoulos-new-tls-padding-01

Alfredo

>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From Kenny.Paterson@rhul.ac.uk  Sat Nov 30 09:29:29 2013
Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6152F1AE477 for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpfCyJidKV4w for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:29:26 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC731AE046 for <tls@ietf.org>; Sat, 30 Nov 2013 09:29:26 -0800 (PST)
Received: from mail87-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE004.bigfish.com (10.236.130.67) with Microsoft SMTP Server id 14.1.225.22; Sat, 30 Nov 2013 17:29:24 +0000
Received: from mail87-co9 (localhost [127.0.0.1])	by mail87-co9-R.bigfish.com (Postfix) with ESMTP id A782C4C09A9; Sat, 30 Nov 2013 17:29:24 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -4
X-BigFish: PS-4(zzbb2dI98dI936eI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh1de097hz2dh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(199002)(189002)(24454002)(51704005)(479174003)(63696002)(46102001)(81342001)(81686001)(74662001)(47976001)(85306002)(59766001)(65816001)(53806001)(19580395003)(19580405001)(83506001)(83322001)(76482001)(54356001)(49866001)(4396001)(81542001)(31966008)(51856001)(83072001)(81816001)(50986001)(74876001)(74706001)(80976001)(79102001)(77982001)(74366001)(47736001)(87936001)(80022001)(74502001)(56776001)(76796001)(76786001)(54316002)(2656002)(74482001)(47446002)(69226001)(76176001)(36756003)(87266001)(66066001)(56816005)(90146001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:80.42.233.244; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail87-co9 (localhost.localdomain [127.0.0.1]) by mail87-co9 (MessageSwitch) id 1385832561852232_27034; Sat, 30 Nov 2013 17:29:21 +0000 (UTC)
Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.250])	by mail87-co9.bigfish.com (Postfix) with ESMTP id CB05D22003F;	Sat, 30 Nov 2013 17:29:21 +0000 (UTC)
Received: from AM2PRD0311HT003.eurprd03.prod.outlook.com (157.56.249.149) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 30 Nov 2013 17:29:21 +0000
Received: from DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) by AM2PRD0311HT003.eurprd03.prod.outlook.com (10.255.162.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Sat, 30 Nov 2013 17:29:19 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sat, 30 Nov 2013 17:29:18 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0820.005; Sat, 30 Nov 2013 17:29:18 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>, Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO7R77H2f5vAeCGkOkJhCJPGzqVZo8bsWAgAA2+ACAABbXAIAAHPYAgAAhpACAAPI6AIAAG7aA
Date: Sat, 30 Nov 2013 17:29:17 +0000
Message-ID: <CEBFC33E.10954%kenny.paterson@rhul.ac.uk>
In-Reply-To: <1385826600.11639.25.camel@aspire.lan>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.233.244]
x-forefront-prvs: 00462943DE
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C86F39EF2B8622459A9A908B84FCD8B3@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 17:29:29 -0000

Hi Nikos, all,

I've been following this discussion with great interest, but keeping
rather quiet since my last contribution because I've been a bit busy with
other work, and because I was told that I was contorting reality last time
I tried to make a contribution...which left me somewhat disenchanted with
the tenor of the debate.

On 30/11/2013 15:50, "Nikos Mavrogiannopoulos" <nmav@redhat.com> wrote:

>On Fri, 2013-11-29 at 17:23 -0800, Watson Ladd wrote:
>
>> > Contrary to popular opinion on this list AtE is a standard way of
>> > operation with no flaws known unless used with an unauthenticated pad
>> > (as in TLS). When SSL 3.0 was designed AtE was believed to be the
>> > conservative approach comparing to EtA.
>> The passive voice is doing a lot of work here. Bellare and Namparah
>> showed that EtA is generically secure,
>> AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
>> "no flaws known"!=3D"proved to be secure"
>
>Proven to be secure doesn't mean that attacks don't exist. The TLS
>padding scheme was proven to be secure prior to be broken; ironically by
>the same person who made the proof. Attacks work by playing outside the
>requirements of the proof.

I assume here that you're referring to my "Tag size matters" paper with
Ristenpart and Shrimpton, and then to the Lucky 13 paper here. OK, with
some of my TLS credentials established for those who don't know me, here
are the key points that I take away from the TLS proof (from that paper)
versus the Lucky 13 attack:

The proof for MAC-then-Pad-then-Encrypt in TLS was extremely delicate and
difficult to produce. Indeed, in generating it, we came up with another
new attack on "TLS with short MACs" that excludes certain parameters from
ever being secure. We then had to make an assumption for the proof to go
through: that the decryption process does not leak the source of
decryption failure (sanity check failure, bad pad, or bad MAC), or any of
the timing involved in decryption.

What the Lucky 13 attack showed is that achieving this "uniformity of
errors" is very difficult for TLS's MAC-then-Pad-then-Encrypt construction.

And this is why MAC-then-Encrypt - and its real world variants - are being
given such a hard time on this list by some, including me: our bitter
experience is that implementing it securely is just much too hard. Witness
Adam Langley's 500 line patch for OpenSSL and NSS to get this (finally)
right. (Side note - Adam deserves credit for independently discovering the
same attack vector that we used in Lucky 13.)

To add a bit more detail: during the Lucky 13 disclosure process, I worked
with many vendors to help them get their patches ready. Very few of them
were actually able to completely eliminate timing side channels completely
in their implementations, and all that I know of (except for Adam) settled
for a "good enough" approach. Of course, that pragmatic approach is quite
justifiable. But it may still leave open small windows of opportunity for
future attack.

Bottom line: none of the many issues that MAC-then-Pad-then-Encrypt has
had in TLS should *ever* arise for Encrypt-then-MAC, unless the
implementer was extremely ill-educated.

To me, the perceived dangers of exposing the MAC - dangers which neither I
(nor any serious cryptographer I know) accept as being real - are far
outweighed by the simplicity and robustness provided by an
Encrypt-then-MAC approach.

>Nevertheless, there is much more recent work on EtA vs AtE, that
>actually proves AtE secure (not "generically" as you pose, you just need
>a decent cipher). You may check "The order of encryption and
>authentication for protecting communications (or: How secure is SSL?)".
>There are even newer papers than that, it is just this that came to
>mind.

This is too simplistic an interpretation of that paper by Hugo Krawczyk,
I'm afraid. It's an excellent piece of work, and quite ahead of its time
in trying to apply provable security techniques to a real protocol. But it
has two major shortcomings if you try to apply it to CBC-mode encryption
as used in TLS:

1. It does not consider TLS padding whatsoever - but instead assumes data
is all block-aligned. As soon as you introduce padding in-between the MAC
and the encryption, i.e. as in TLS's actual construction, you run into
lots of trouble - Vaudenay, Bodo Moeller's observations, Lucky 13 and all.

2. It assumes the MAC output size is the same as the block cipher's block
size. Out of all mainstream TLS ciphersuites that I know, this is true
only for HMAC-MD5 with AES. And I think we all agree we'd like to avoid
MD5 now!

On the plus side, and perhaps this is what you were referring to, Hugo's
analysis works just fine for stream-cipher based ciphersuites (as long as
the stream cipher is good - so not RC4 then!). The Asiacrypt 2011 paper
can be seen as extending his analysis to handle the actual construction
used in TLS's CBC-mode ciphersuites, but with the important, necessary,
and difficult-to-achieve proviso concerning uniformity of errors.

Also on the plus side, Hugo's analysis can be fairly easily extended to
cover the Pad-then-MAC-then-Encrypt construction for CBC-mode encryption
that you, and others, have been arguing for (still under the assumption
concerning the size of the MAC tags and the block size, though it might be
that this assumption can be removed with more work). So there is indeed
theoretical support for this kind of construction. And maybe it can even
be implemented securely, too.

But, at the risk of repeating myself, I very much prefer the simplicity
and robustness of an Encrypt-then-MAC construction.

Of course, this is just another opinion, like many others that have been
expressed on this list recently, and I cannot hope it will be the last
word on the subject. But I can hope that it's accepted as an opinion born
from significant experience in analysing TLS security, from a variety of
perspectives (theoretical, implementation, attacks).

Best wishes,

Kenny=20





From alfredo@pironti.eu  Sat Nov 30 09:58:33 2013
Return-Path: <alfredo@pironti.eu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FFE1AE115 for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAPXUJ98oyJc for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 09:58:32 -0800 (PST)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21F1AE110 for <tls@ietf.org>; Sat, 30 Nov 2013 09:58:32 -0800 (PST)
Received: by mail-ob0-f176.google.com with SMTP id va2so11143662obc.35 for <tls@ietf.org>; Sat, 30 Nov 2013 09:58:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NpYtV9qFOIPwi6XKIi5zL0J+ikoom8n/1PwzuAZdMsY=; b=L4OJPpRnxKRsq+w/ipfoGSc2wjQdw9i2FV93BRIfIe31Ct3ZCYpQqRgNkYDVsnpHfm /n2bAGhKZXCU4ZyelGR1d6v/UyAZEcnVWc2oMAxi35Ift9xnuxf+g7I8kWLlaYpIQfRE gBOvXru771KJpGaK5xnO6CyhtzL3m/dP+U2vU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NpYtV9qFOIPwi6XKIi5zL0J+ikoom8n/1PwzuAZdMsY=; b=ZgQnSKFj+CutJ4yms3+vu3zDZRzge1DpLsYaT52hzs0BBM2LLo39PnoxYNt7rM+cDg KfRR3wU1nzJj+bTTfB0HNR3Rm1q15231TTxtc4NfYMcre7CMco0WwrTF4/q5irwr1xRa KIqWwlx1ehVprzjY91X37DStW2mD9sapTRthxHdUDZ9YGSjiVlpdps0Cn55t7tR2sqWk SezU/i/W2U841C9MQTJGN0eq/P6XTN7Lrg+p3BeroFHe7EB8XY5qlzcCRC4Eyr0PEbLl kkJZZXqO8d4t/NMYd0WyxTx+tOQbiOez0w6hrQJR9RXBGDmjGHdP+EClTciN1bcJgWzk odZw==
X-Gm-Message-State: ALoCoQkLiMVGPFMDjW1Z/4xlhXFgpA9qKIt13PqXQQN0L+75ZriZLPZJQ2CaiWGRI3TCNWSiRStS
MIME-Version: 1.0
X-Received: by 10.60.45.102 with SMTP id l6mr29107791oem.36.1385834310938; Sat, 30 Nov 2013 09:58:30 -0800 (PST)
Received: by 10.76.114.194 with HTTP; Sat, 30 Nov 2013 09:58:30 -0800 (PST)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <CEBFC33E.10954%kenny.paterson@rhul.ac.uk>
References: <1385826600.11639.25.camel@aspire.lan> <CEBFC33E.10954%kenny.paterson@rhul.ac.uk>
Date: Sat, 30 Nov 2013 18:58:30 +0100
Message-ID: <CALR0uiLgqeF_87THr98rgFvXrLsmiUO2Q9p+LGLxiHa==5AmCQ@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 17:58:33 -0000

Hi Kenny,

> But, at the risk of repeating myself, I very much prefer the simplicity
> and robustness of an Encrypt-then-MAC construction.

I agree with you. Indeed, Encrypt-then-MAC and (or within) AEAD are
the only two cipher modes I'd like to see in TLS 1.3.

In practice however, we witness the disastrous experience in widely
deploying any change which is not a small patch to TLS1.0. So I'm
afraid that to get something deployed in reasonable times we may have
to get content with such a patch, like pad-MAC-Encrypt, that makes
more robust (if not provably secure) what we already have.

Alfredo

From watsonbladd@gmail.com  Sat Nov 30 10:02:39 2013
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D1C1AE120 for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 10:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fwdj9CkxFXiI for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 10:02:38 -0800 (PST)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 56A501AD73E for <tls@ietf.org>; Sat, 30 Nov 2013 10:02:38 -0800 (PST)
Received: by mail-wi0-f181.google.com with SMTP id hq4so3186518wib.14 for <tls@ietf.org>; Sat, 30 Nov 2013 10:02:36 -0800 (PST)
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=j9J3L5z4wGHYxYBh4jqZSxRJ+ymO3fQpPiEi6MV4Ics=; b=Afzm4lIRbkuLzqhldHL/ZC8iwKdYesYqXqpp7hAXqe0tgYZm1yChwU5wlHmcLApaWN z02mJJblR0kxsLFNPujD+9HTfTsGruDI880h4VpEliYIDqMpFAFAo/WoanXkgFx6ViLS o37dL50lAXa0QznNznM6h+8zuF1i7WZSaEcZkbVNmrmFbh+dmhpGMM136yEykzeEBDx6 NMQ+co8gBejc0k/Iq0ANGJkDGFZD56TgCQrGK9e1JtcDqHj8HBVo93uWfGgfljao2yZf btsOZp99PZAroO7HH9w5wPT8MIek9ZVgm+5kCkZvHBA8WWY12UooLqDwAxPojn1hQCOf bNDg==
MIME-Version: 1.0
X-Received: by 10.194.122.99 with SMTP id lr3mr45065505wjb.21.1385834556318; Sat, 30 Nov 2013 10:02:36 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Sat, 30 Nov 2013 10:02:36 -0800 (PST)
In-Reply-To: <CALR0uiLgqeF_87THr98rgFvXrLsmiUO2Q9p+LGLxiHa==5AmCQ@mail.gmail.com>
References: <1385826600.11639.25.camel@aspire.lan> <CEBFC33E.10954%kenny.paterson@rhul.ac.uk> <CALR0uiLgqeF_87THr98rgFvXrLsmiUO2Q9p+LGLxiHa==5AmCQ@mail.gmail.com>
Date: Sat, 30 Nov 2013 10:02:36 -0800
Message-ID: <CACsn0cnyGGiWynEb7LTrxnbsO53Z=8RtbdftD0T29n_80T8sWw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Alfredo Pironti <alfredo@pironti.eu>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 18:02:40 -0000

On Sat, Nov 30, 2013 at 9:58 AM, Alfredo Pironti <alfredo@pironti.eu> wrote:
> Hi Kenny,
>
>> But, at the risk of repeating myself, I very much prefer the simplicity
>> and robustness of an Encrypt-then-MAC construction.
>
> I agree with you. Indeed, Encrypt-then-MAC and (or within) AEAD are
> the only two cipher modes I'd like to see in TLS 1.3.
You do realize EtM is an AEAD if properly designed?
>
> In practice however, we witness the disastrous experience in widely
> deploying any change which is not a small patch to TLS1.0. So I'm
> afraid that to get something deployed in reasonable times we may have
> to get content with such a patch, like pad-MAC-Encrypt, that makes
> more robust (if not provably secure) what we already have.
How is pad-MAC-Encrypt less of a change then Encrypt then MAC?
We still can't kill RC4, which is a *configuration change*.
Patches aren't getting deployed even if painless, so arguing about the
ease of deployment is a red herring.
>
> Alfredo



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

From alfredo@pironti.eu  Sat Nov 30 10:23:56 2013
Return-Path: <alfredo@pironti.eu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F441AE141 for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 10:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNT8iVf1T66Y for <tls@ietfa.amsl.com>; Sat, 30 Nov 2013 10:23:55 -0800 (PST)
Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 720391AE136 for <tls@ietf.org>; Sat, 30 Nov 2013 10:23:55 -0800 (PST)
Received: by mail-oa0-f49.google.com with SMTP id i4so11435096oah.22 for <tls@ietf.org>; Sat, 30 Nov 2013 10:23:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fYFAz/5aHcBzBEAFB16WBMgb5aFSo0zbflsEe9ixB6Q=; b=a4usZSwWrya2uNbVA8lQqXBUpXlZvicv+B+B2xxO9ZJcz6BYCINnkdpcW+eL7OjbHa m2x3wrZcw8NFtkrbeLDQD5b8oH9MK5GcxJFZdv6kzD7oqQMddcz7TqQmbVW8Tf1FGmII tZndXxD9MnGwsry02bMoYA+Zyx/fhPtjcIrsU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fYFAz/5aHcBzBEAFB16WBMgb5aFSo0zbflsEe9ixB6Q=; b=Pd+EEosEf1CE/4EhNAnrxHsELwzYQyvQv71m9vAWNPH1aOcT9npAiP4hq0EyuGzuiy MaFxi/kkPbMoUF+aHqAyUdKkUzqyQ9oBpoF4ZmPbIhtQ8sFTv16/2NBfbKknrlYFtEl9 jnr6iQYqYVlvcs+0c6Wp0ErF5Ot60WqQulWYwVvQEfkIWJSglsrAuFWXGnEpmyvDcFed vb79jmJjK20nyP+WtoOXBYrbij6kNggdMcJc6OB0qGS+/gwy0+urTGKC1IAXQb89hhpg w9sMkfYu49gLvm258pkXGBlo8M3IXw7jXzXfMKVrd9fbsJOH9CG/Gi6U5llrnAkqVZvI PEQw==
X-Gm-Message-State: ALoCoQn1iZPyuTi4ujUvON28jSBbz6XPOjwnKU3MvDXuTdseKjfshBtbhQmpxWsYLm+u6LWd/1S8
MIME-Version: 1.0
X-Received: by 10.60.62.8 with SMTP id u8mr381521oer.54.1385835833736; Sat, 30 Nov 2013 10:23:53 -0800 (PST)
Received: by 10.76.114.194 with HTTP; Sat, 30 Nov 2013 10:23:53 -0800 (PST)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <CACsn0cnyGGiWynEb7LTrxnbsO53Z=8RtbdftD0T29n_80T8sWw@mail.gmail.com>
References: <1385826600.11639.25.camel@aspire.lan> <CEBFC33E.10954%kenny.paterson@rhul.ac.uk> <CALR0uiLgqeF_87THr98rgFvXrLsmiUO2Q9p+LGLxiHa==5AmCQ@mail.gmail.com> <CACsn0cnyGGiWynEb7LTrxnbsO53Z=8RtbdftD0T29n_80T8sWw@mail.gmail.com>
Date: Sat, 30 Nov 2013 19:23:53 +0100
Message-ID: <CALR0uiLqUCJxcrjpHDBxXCEmZhKEdLBBgfnwSJuPK9RXcV-c=Q@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
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." <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: Sat, 30 Nov 2013 18:23:56 -0000

On Sat, Nov 30, 2013 at 7:02 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
> On Sat, Nov 30, 2013 at 9:58 AM, Alfredo Pironti <alfredo@pironti.eu> wrote:
>> Hi Kenny,
>>
>>> But, at the risk of repeating myself, I very much prefer the simplicity
>>> and robustness of an Encrypt-then-MAC construction.
>>
>> I agree with you. Indeed, Encrypt-then-MAC and (or within) AEAD are
>> the only two cipher modes I'd like to see in TLS 1.3.
> You do realize EtM is an AEAD if properly designed?

I do. I was just speaking in TLS1.2 terminology, which does make a
distinction, even though all schemes are supposed to deliver
Authenticated Encryption with Additional Data anyway. If I just said
that I only wanted AEAD, somebody else would have shoot at me instead
by saying that GCM is too inefficient.

>>
>> In practice however, we witness the disastrous experience in widely
>> deploying any change which is not a small patch to TLS1.0. So I'm
>> afraid that to get something deployed in reasonable times we may have
>> to get content with such a patch, like pad-MAC-Encrypt, that makes
>> more robust (if not provably secure) what we already have.
> How is pad-MAC-Encrypt less of a change then Encrypt then MAC?

It is easier enough in that 2 implementations already implement pad-MtE
(GnuTLS and miTLS), and my personal experience in implementing the
patch says it's a small change.

But we need even more factual feedback, and I hope we get more people
to try to implement it elsewhere.

> We still can't kill RC4, which is a *configuration change*.
> Patches aren't getting deployed even if painless, so arguing about the
> ease of deployment is a red herring.
>>
>> Alfredo
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin