From maray@microsoft.com Mon Feb 3 14:08:17 2014 Return-Path: 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 B92371A0264 for ; Mon, 3 Feb 2014 14:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Xxrn35hFvWEm for ; Mon, 3 Feb 2014 14:08:13 -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 09ECC1A01EE for ; Mon, 3 Feb 2014 14:08:12 -0800 (PST) Received: from BY2PR03MB075.namprd03.prod.outlook.com (10.255.241.155) by BY2PR03MB207.namprd03.prod.outlook.com (10.242.36.154) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 22:08:11 +0000 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.868.8; Mon, 3 Feb 2014 22:08:10 +0000 Received: from BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.135]) by BY2PR03MB074.namprd03.prod.outlook.com ([169.254.12.135]) with mapi id 15.00.0868.013; Mon, 3 Feb 2014 22:08:09 +0000 From: Marsh Ray To: "tls@ietf.org" Thread-Topic: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv Thread-Index: AQHPGCLZFw5frHTkQUeKTyOugTzg05qfF16AgAUP55A= Date: Mon, 3 Feb 2014 22:08:09 +0000 Message-ID: <81674f0435c74985a8ad48a55f5c27fa@BY2PR03MB074.namprd03.prod.outlook.com> References: In-Reply-To: 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: 01110342A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(189002)(199002)(53806001)(4396001)(87936001)(76786001)(81816001)(81686001)(85852003)(87266001)(85306002)(92566001)(83072002)(46102001)(51856001)(2656002)(76796001)(77096001)(561944002)(54356001)(19580395003)(80976001)(83322001)(76576001)(15975445006)(47976001)(50986001)(47736001)(76482001)(49866001)(93516002)(90146001)(56816005)(74366001)(65816001)(80022001)(74876001)(94316002)(47446002)(79102001)(74662001)(15202345003)(74502001)(86362001)(93136001)(81542001)(31966008)(54316002)(56776001)(94946001)(33646001)(59766001)(77982001)(74706001)(81342001)(63696002)(69226001)(74316001)(86612001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB075; H:BY2PR03MB074.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:BC76F00D.A4F8C1D7.BDF393EA.4433E94D.20311; InfoNoRecordsMX: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] Call for acceptance of draft-moeller-tls-downgrade-scsv 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:08:17 -0000 Forgive me if this has been discussed before, sometimes I have trouble wrapping my head around all this version negotiation stuff. The draft http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 s= tates: > All unnecessary protocol downgrades are undesirable (e.g., from TLS > 1.2 to TLS 1.1 if both the client and the server actually do support > TLS 1.2); they can be particularly critical if they mean losing the > TLS extension feature (when downgrading to SSL 3.0). While this is certainly true, it is also 'undesirable' to increase the rate of spurious handshake failures for clients. So it's a lesser-of-two-evils tradeoff. Absent a plausible attack, an increased rate of total interop failure seems like the more tangible and quantifiable evil. So what's the attack that this SCSV is trying to solve? Could someone please give a scenario in which: A. The legitimate client supports ver > TLS 1.0. B. The attacker is able to trigger client fallback to ver <=3D TLS 1.0 C. *All* servers having the private key for a valid cert support ver > TLS 1.0. D. The attacker is able to exploit some weakness with the downgraded ver <=3D TLS 1.0 connection that he can *not* exploit in ver > TLS 1.0. E. The attacker is *not* able to actually impersonate the legitimate server over this downgraded (ver <=3D TLS 1.0) connection. Rationale: A. The value of this proposal comes when using post-TLS 1.0 aware clients. B. Obvs. C. The value of this proposal comes when using post-TLS 1.0 aware servers, but if any legitimate server only supports ver <=3D TLS 1.0, the attacke= r can forward the initial connection to that server. D. Otherwise, what would he gain by the downgrade? E. If the attacker could successfully impersonate the legitimate server over the downgraded connection, he would simply ignore the SCSV, right? I don't mean for this to sound like a rhetorical question, I'd just like to see what such a scenario would look like. I'm personally still on the fence about this one. Thanks, - Marsh -------------------------------- My personal opinions only, usual disclaimers apply. From ekr@rtfm.com Mon Feb 3 14:20:49 2014 Return-Path: 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 259581A015D for ; Mon, 3 Feb 2014 14:20:49 -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 ceCVjgnXm0ts for ; Mon, 3 Feb 2014 14:20:46 -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 96C841A0264 for ; Mon, 3 Feb 2014 14:20:46 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id p17so5065506vbe.40 for ; Mon, 03 Feb 2014 14:20:46 -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=aAXle7IGe53d+IGy+CZpM7ZK1AkoDRJRZ7vlhMaLV7Q=; b=a2MsB4xZKfcLz3UtWh8eGeKst8hzxRZnxffvOnNFq2ZqSs0qI8KBWzPU3Wy5L0qaO3 WOZOga4gSLhIoVDOh+XJUdPE/6fOrkG/V1R4lFxgH1NBYbH6XsMH2YCZ6kioFXIZNuK7 Jv79Jm/lo8afwqd7bjTpl93SV87/xRVh4ADUD+HKBOfby+qtbhQUZSziaNRMKOTUId6b gGc6DYo3Bu9tcbNi8kw3dpSy0J4AJSbM6fWU3ZIf/Gx7B8kXdBbct/OdlvxX1ZFXtWMh Rpq1ftiIxaxUhHIdfF+BRYBhhtSvKpIDdcFraOmsRRjvdD4ZtkGP5M+RWj+ayscA1SwS LE+g== X-Gm-Message-State: ALoCoQle0MYoE2783sAIYr3WnC+E4y+g9A+KxynOcFWs/sv0bKOJgMxX7KFJCTHpmfwZHTnG8QqX X-Received: by 10.220.58.202 with SMTP id i10mr3403569vch.23.1391466046244; Mon, 03 Feb 2014 14:20:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.106.162 with HTTP; Mon, 3 Feb 2014 14:20:06 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <81674f0435c74985a8ad48a55f5c27fa@BY2PR03MB074.namprd03.prod.outlook.com> References: <81674f0435c74985a8ad48a55f5c27fa@BY2PR03MB074.namprd03.prod.outlook.com> From: Eric Rescorla Date: Mon, 3 Feb 2014 14:20:06 -0800 Message-ID: To: Marsh Ray Content-Type: multipart/alternative; boundary=001a11c2d70e675ed704f187ef5d Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:20:49 -0000 --001a11c2d70e675ed704f187ef5d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 3, 2014 at 2:08 PM, Marsh Ray wrote: > Forgive me if this has been discussed before, sometimes I have trouble > wrapping my head around all this version negotiation stuff. > > The draft http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01states: > > All unnecessary protocol downgrades are undesirable (e.g., from TLS > > 1.2 to TLS 1.1 if both the client and the server actually do support > > TLS 1.2); they can be particularly critical if they mean losing the > > TLS extension feature (when downgrading to SSL 3.0). > > While this is certainly true, it is also 'undesirable' to increase > the rate of spurious handshake failures for clients. So it's > a lesser-of-two-evils tradeoff. Absent a plausible attack, an > increased rate of total interop failure seems like the more > tangible and quantifiable evil. > > So what's the attack that this SCSV is trying to solve? > > Could someone please give a scenario in which: > A. The legitimate client supports ver > TLS 1.0. > B. The attacker is able to trigger client fallback to ver <= TLS 1.0 > C. *All* servers having the private key for a valid cert support > ver > TLS 1.0. > D. The attacker is able to exploit some weakness with the > downgraded ver <= TLS 1.0 connection that he > can *not* exploit in ver > TLS 1.0. > E. The attacker is *not* able to actually impersonate the legitimate > server over this downgraded (ver <= TLS 1.0) connection. > The example I would use here is: http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05 Because this draft uses an extension for signaling, if the attacker can convince the client that the server is extensions-intolerant and the server reconnects over SSLv3, then the attacker has forced you to into using the old MAC/Encrypt order. He can do this even if he couldn't impersonate the server because the fallback in question is done at the application layer not via the TLS version negotiation mechanisms. Does this make sense? Note that this is distinct from the cost/benefit calculus of whether it's better to use this extension. It's just intended as an example of a realistic attack vector. -Ekr --001a11c2d70e675ed704f187ef5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Feb 3, 2014 at 2:08 PM, Marsh Ray <maray@microsoft.com> wrote:
Forgive me if this has been discussed before, sometimes I = have trouble
wrapping my head around all this version negotiation stuff.

The draft http://tools.ietf.org/html/draft-bmoeller-tls-= downgrade-scsv-01 states:
> =A0All unnecessary protocol downgrades are undesirable (e.g., from TLS=
> =A01.2 to TLS 1.1 if both the client and the server actually do suppor= t
> =A0TLS 1.2); they can be particularly critical if they mean losing the=
> =A0TLS extension feature (when downgrading to SSL 3.0).

While this is certainly true, it is also 'undesirable' to increase<= br> the rate of spurious handshake failures for clients. So it's
a lesser-of-two-evils tradeoff. Absent a plausible attack, an
increased rate of total interop failure seems like the more
tangible and quantifiable evil.

So what's the attack that this SCSV is trying to solve?

Could someone please give a scenario in which:
A. The legitimate client supports ver > TLS 1.0.
B. The attacker is able to trigger client fallback to ver <=3D TLS 1.0 C. *All* servers having the private key for a valid cert support
=A0 =A0ver > TLS 1.0.
D. The attacker is able to exploit some weakness with the
=A0 =A0downgraded ver <=3D TLS 1.0 connection that he
=A0 =A0can *not* exploit in ver > TLS 1.0.
E. The attacker is *not* able to actually impersonate the legitimate
=A0 =A0server over this downgraded (ver <=3D TLS 1.0) connection.

The example I would use here is:
= http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-05

Because this draft uses an extension for signaling, if = the attacker
can convince the client that the server is extension= s-intolerant
and the server reconnects over SSLv3, then the attac= ker has
forced you to into using the old MAC/Encrypt order. He can
d= o this even if he couldn't impersonate the server because the
fallback in question is done at the application layer not via the
TLS version negotiation mechanisms.

Does this= make sense? Note that this is distinct from the
cost/benefit cal= culus of whether it's better to use this extension.
It's = just intended as an example of a realistic attack vector.

-Ekr



--001a11c2d70e675ed704f187ef5d-- From bodomoeller@gmail.com Mon Feb 3 14:20:40 2014 Return-Path: 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 A919A1A0266 for ; Mon, 3 Feb 2014 14:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, 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 yxpG8Pb8Y_wC for ; Mon, 3 Feb 2014 14:20:39 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A60841A015D for ; Mon, 3 Feb 2014 14:20:39 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so8393699obc.25 for ; Mon, 03 Feb 2014 14:20:39 -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=26TbB+65WEl0YNmMFz8hPvXesHKbR+Nh4UiqgkrehUY=; b=Md9xS7uAHfbpVVF9jLsYhFa2ODYXrdMGEk0NSDeGt7uyppXphoJmmgpC2UFxMMVcT2 onftMYyL7dg2qy4m0ctRmbzvfVyWNgnCWTTDKLrhVW2c4Ans8/D6IoWS1tV8107A4g3l gNalQURucIYgG3tSIvrDP3B2iJjnAPKaULPNVbUJhly9IgyJ0Iq6RGQO/cBjkuEheIqF fpvhuXJY8dvsIle7YLX9WWWrpjM/Fbhg69c5iXstBLQwmTbfaELShy5PQ9G94cabt0pL bVOa5LEeqs4lOZrVK/kRpk+1XBh5HeL/Z3genuG6romfo4DhuzQ9eG522EIkLBO07SW+ Vv+g== MIME-Version: 1.0 X-Received: by 10.182.158.71 with SMTP id ws7mr32639175obb.6.1391466039417; Mon, 03 Feb 2014 14:20:39 -0800 (PST) Received: by 10.60.170.239 with HTTP; Mon, 3 Feb 2014 14:20:39 -0800 (PST) In-Reply-To: <81674f0435c74985a8ad48a55f5c27fa@BY2PR03MB074.namprd03.prod.outlook.com> References: <81674f0435c74985a8ad48a55f5c27fa@BY2PR03MB074.namprd03.prod.outlook.com> Date: Mon, 3 Feb 2014 23:20:39 +0100 Message-ID: From: =?ISO-8859-1?Q?Bodo_M=F6ller?= To: Marsh Ray Content-Type: multipart/alternative; boundary=089e01494a16ff24c704f187ee70 X-Mailman-Approved-At: Mon, 03 Feb 2014 14:23:05 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 22:20:41 -0000 --089e01494a16ff24c704f187ee70 Content-Type: text/plain; charset=ISO-8859-1 Marsh Ray : So what's the attack that this SCSV is trying to solve? > > Could someone please give a scenario in which: > A. The legitimate client supports ver > TLS 1.0. > B. The attacker is able to trigger client fallback to ver <= TLS 1.0 > C. *All* servers having the private key for a valid cert support > ver > TLS 1.0. > D. The attacker is able to exploit some weakness with the > downgraded ver <= TLS 1.0 connection that he > can *not* exploit in ver > TLS 1.0. > E. The attacker is *not* able to actually impersonate the legitimate > server over this downgraded (ver <= TLS 1.0) connection. > Examples: - The CBC cipher suites in TLS 1.0 are more broken than in TLS 1.1 and later (thanks to explicit IVs). They're even worse in SSL 3.0. - If you fall back to SSL 3.0 without extensions, you lose various features (for example, can't negotiate curves for ephemeral ECDH), not all of which have even been specified yet. Bodo --089e01494a16ff24c704f187ee70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mars= h Ray <maray@microsoft.com>:

So what's the attack that this SCSV is trying to solve?

Could someone please give a scenario in which:
A. The legitimate client supports ver > TLS 1.0.
B. The attacker is able to trigger client fallback to ver <=3D TLS 1.0 C. *All* servers having the private key for a valid cert support
=A0 =A0ver > TLS 1.0.
D. The attacker is able to exploit some weakness with the
=A0 =A0downgraded ver <=3D TLS 1.0 connection that he
=A0 =A0can *not* exploit in ver > TLS 1.0.
E. The attacker is *not* able to actually impersonate the legitimate
=A0 =A0server over this downgraded (ver <=3D TLS 1.0) connection.

Examples:

- The CBC = cipher suites in TLS 1.0 are more broken than in TLS 1.1 and later (thanks = to explicit IVs). They're even worse in SSL 3.0.

- If you fall back to SSL 3.0 without extensions, you l= ose various features (for example, can't negotiate curves for ephemeral= ECDH), not all of which have even been specified yet.

Bodo

--089e01494a16ff24c704f187ee70-- From seonghan.shin@aist.go.jp Mon Feb 3 22:53:59 2014 Return-Path: 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 2356A1A0383 for ; Mon, 3 Feb 2014 22:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 7necl-Rg-XWp for ; Mon, 3 Feb 2014 22:53:55 -0800 (PST) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id 069631A0382 for ; Mon, 3 Feb 2014 22:53:54 -0800 (PST) Received: from mail-la0-f51.google.com ([209.85.215.51]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUvCOgUYdxeopW3xlsfcxQj1n8lr7jCw1@postini.com; Mon, 03 Feb 2014 22:53:55 PST Received: by mail-la0-f51.google.com with SMTP id c6so6041839lan.24 for ; Mon, 03 Feb 2014 22:53:52 -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=ao0T1YO0zGsv1i5Ftld9N8jbaEgCU30sjZYQzU+UJMw=; b=Px2mR6oG0E5lw5TtIwgMFsyY2gq4/htaxO115M3H1/D23C+RtOOqOSIWLzdkJI0ViE ZQYHKiI9lcrlQESS12BkiWKy+ms07c9NKlfc/PnWGDTEHUkyvZumXdu1czlsYqShz8fD OsNXalUPJZgOxo6WC92mADJg2dKcMS150YGCc= 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=ao0T1YO0zGsv1i5Ftld9N8jbaEgCU30sjZYQzU+UJMw=; b=DlAJ3SeM8z4rV3Yvc8aQWPkya+2fJSg/PbgMG4LuDQ5nm5yCoCAUwMno+FZfaMyUBF lCPSTZcBGiYZq8q7uKRZdh4hq9gF0nsfqNMAa1Rfj1jwrSyuKNzymXhIlsD/dpGPKw2+ jIOyHmNPPe9eljxoO2geW8upsAK25DeD18GUnKcztXF6MPPrixYSP1a7CDuP7bxV/mrP vX3/c1rbFuwG9OKVbxtlBZij0bvb7SGS6acES81V0Vk8qF+pOoNVSFsLJcKRZJ0xYASV ShZgVnZm3USJrlvk4Hfwxt+fXXNZut5gk61e1imaXB4lL81BRZrIWmdzi9nePIfvldqS NYEA== X-Gm-Message-State: ALoCoQnr77S9UKyWzxBPlZf4CweIULBBkQuP0OGqIAVBupZD2350H3YMv8SbTMYVMqeFicyRRg3kYlgL1aB5GwXBhPeEP80jG1571EB3xLpLFqq1sYDH7e2eU7vgpTYNUm1IAJMK/ASYIBae6hFG42mgiyyMMTJzWg== X-Received: by 10.112.97.173 with SMTP id eb13mr27568lbb.65.1391496832513; Mon, 03 Feb 2014 22:53:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.97.173 with SMTP id eb13mr27562lbb.65.1391496832376; Mon, 03 Feb 2014 22:53:52 -0800 (PST) Received: by 10.112.164.35 with HTTP; Mon, 3 Feb 2014 22:53:52 -0800 (PST) In-Reply-To: <07A9A949-2A96-4401-B640-A0E1C438A8E8@gmail.com> References: <07A9A949-2A96-4401-B640-A0E1C438A8E8@gmail.com> Date: Tue, 4 Feb 2014 15:53:52 +0900 Message-ID: From: SeongHan Shin To: Fabrice Content-Type: multipart/alternative; boundary=001a1133e9dc6679d304f18f1a84 Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= , "" 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.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 06:53:59 -0000 --001a1133e9dc6679d304f18f1a84 Content-Type: text/plain; charset=ISO-8859-1 Hi Fabrice, I'm sorry for this delay. >I haven't seen anything in the TLS1.3 flows document that would allow that. I meant that the cached domain parameter set is used on client because the server has the password verifier, computed with the parameter set. >I guess you could only require the extra round trip for the first connection and have the client cache the group parameters somehow. Thank you! >But then you probably need a way for the client to tell the server which parameter it is using, so it can signal if the parameters match without going through the whole handshake. One option may be to use the Supported Ellitpic Curves Extension [RFC4492] though I did not describe AugPAKE over elliptic curve groups yet ^^; >Also, your draft don't define new ciphersuites, like TLS-SRP does, so I don't think it's complete. New ciphersuites would be added later. Best regards, Shin On Fri, Nov 8, 2013 at 7:37 AM, Fabrice wrote: > On Nov 7, 2013, at 10:36, SeongHan Shin wrote: > > Hi Fabrice, > > Thank you for your comment! > > 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. > > > >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? > > > I guess you could only require the extra round trip for the first > connection and have the client cache the group parameters somehow. > > But then you probably need a way for the client to tell the server which > parameter it is using, so it can signal if the parameters match without > going through the whole handshake. > > Also, your draft don't define new ciphersuites, like TLS-SRP does, so I > don't think it's complete. > > Fabrice > > > > Regards, > Shin > > > On Fri, Nov 8, 2013 at 1:20 AM, Fabrice Gautier > 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 >> 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 > > >> > 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: >> >> Date: Wed, Sep 4, 2013 at 6:26 PM >> >> Subject: New Version Notification for draft-shin-tls-augpake-01.txt >> >> To: Kazukuni Kobara , SeongHan Shin >> >> >> >> >> >> >> >> >> >> 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 > ------------------------------------------------------------------ > > -- ------------------------------------------------------------------ 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 ------------------------------------------------------------------ --001a1133e9dc6679d304f18f1a84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fabrice,

I'm sorry for this = delay.

>I haven't seen anything in the TLS1.3 flows document = that would allow that.
I meant that the cached domain parameter se= t is used on client because the server has the password verifier, computed = with the parameter set.

>I guess you could only require the extra round trip for the fi= rst=20 connection and have the client cache the group parameters somehow.
Thank you!

>But then you probably need a way for the client to tell=20 the server which parameter it is using, so it can signal if the=20 parameters match without going through the whole handshake.
= One option may be to use the Supported Ellitpic Curves Extension [RFC4492] = though I did not describe AugPAKE over elliptic curve groups yet ^^;

>Also, your draft don't define new ciphersuites, like TLS-SRP do= es, so I don't think it's complete.
New ciphersuites would be added later.

Best regards,
Shin


On Fri, Nov 8, 2013 at 7:37 AM, Fabrice <fabrice.gautier= @gmail.com> wrote:
On Nov 7, 2013, at 10:36, SeongHan Shin <seonghan.shin@aist.go.jp> wrote:
Hi Fabrice,<= br>
Thank you for your comment!

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.


>How does the client knows which gro= up to use ?
As you pointed out, we need to change Secti= on 5.1 for the current tls version.
A n= aive 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 c= onnection and have the client cache the group parameters somehow.=A0

But then you probably need a way for the client to tell the = server which parameter it is using, so it can signal if the parameters matc= h without going through the whole handshake.=A0

Also, your draft don't define new ciphersuites, like TLS-SRP does, so I= don't think it's complete.=A0
<= div>
=A0 =A0Fabrice=A0



Rega= rds,
Shin


On Fri, Nov 8, 2013 at 1:20 AM, Fabrice Gaut= ier <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> wrot= e:
> 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 IE= EE
> 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the<= br> > 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 tha= n
> 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><= br> > wrote:
>>
>> Dear all,
>>
>> I submitted a new version of our I-D regarding augmented PAKE (Aug= PAKE)
>> 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.tx= t
>> 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: =A0 =A0 =A0 =A0draft-shin-tls-augpake
>> Revision: =A0 =A0 =A0 =A001
>> Title: =A0 =A0 =A0 =A0 =A0 Augmented Password-Authenticated Key Ex= change for
>> Transport Layer Security (TLS)
>> Creation date: =A0 2013-09-04
>> Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
>> Number of pages: 19
>> URL:
>> http://www.ietf.org/internet-drafts/draft-shi= n-tls-augpake-01.txt
>> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/d= oc/draft-shin-tls-augpake
>> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-= shin-tls-augpake-01
>> Diff:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-shin-tls-= augpake-01
>>
>> Abstract:
>> =A0 =A0This document describes an efficient augmented password-aut= henticated
>> =A0 =A0key exchange (AugPAKE) protocol where a user remembers a lo= w-entropy
>> =A0 =A0password and its verifier is registered in the intended ser= ver. =A0In
>> =A0 =A0general, the user password is chosen from a small set of di= ctionary
>> =A0 =A0whose space is within the off-line dictionary attacks. =A0T= he AugPAKE
>> =A0 =A0protocol described here is secure against passive attacks, = active
>> =A0 =A0attacks and off-line dictionary attacks (on the obtained me= ssages
>> =A0 =A0with passive/active attacks), and also provides resistance = to server
>> =A0 =A0compromise (in the context of augmented PAKE security). =A0= Based on the
>> =A0 =A0AugPAKE protocol, this document also specifies a new passwo= rd-only
>> =A0 =A0authentication handshake for Transport Layer Security (TLS)= protocol.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> 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 : +8= 1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------
<= br>

--
---= ---------------------------------------------------------------
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 : +8= 1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------
--001a1133e9dc6679d304f18f1a84-- From seonghan.shin@aist.go.jp Tue Feb 4 00:30:59 2014 Return-Path: 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 5497E1A03A4 for ; Tue, 4 Feb 2014 00:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 E8Srndnv8ATV for ; Tue, 4 Feb 2014 00:30:56 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8821D1A03AB for ; Tue, 4 Feb 2014 00:30:55 -0800 (PST) Received: from mail-la0-f44.google.com ([209.85.215.44]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUvClP33wKAJHU3VCUBnJWrk0pNGxI3xo@postini.com; Tue, 04 Feb 2014 00:30:55 PST Received: by mail-la0-f44.google.com with SMTP id hr13so2544238lab.17 for ; Tue, 04 Feb 2014 00:30:53 -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=6SOql1HHg2zF0izBgdp798s4fgoDLJja4N6DS+CGtos=; b=ep50tB0DyvMkMVJTavfiJBphXiouEk9/gkbxTrhBMMvYQLOldBrTU1noKn3luo897e hwU0t6cW3812KcRQXgNZa3VA/5aGKqoFyS90AoduqbJV2ZSK/SrZOSDn9aalS32osFC3 w1l0V88MWWcyxbw/3shcwjECsrB3FOiR/pLtk= 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=6SOql1HHg2zF0izBgdp798s4fgoDLJja4N6DS+CGtos=; b=Rfr4qo4/ZjWN0L+WFixc5jTeCGNU4mYB14jMDgwMLMwznjGsnAG4w4jUQblaxfelHW Cdv9JSWFZCrkUFuQPXkqaoUoWIZ2IIEw9WTVUCnfupylDGd7bQLdAVnzszcEZxPM9slx YGP0/tnjeziaNhVizsnw5pkWcihZ60ph+YSL5yQSfr2dA6GAv/XjQP8KJBIAtyVGkNbK Tm07sWe6KnZKUkuItWA58+t/afwv9JzaKFDVWnOtz7rbAe8jGgFxeMkJeIr7PLw2pZns W9/9Zlen+U63OUT73Y9MVgHxOy6GRGtxjsChnKUIrrra/U9146dcqyl3JNO6LtqerNCz xIfQ== X-Gm-Message-State: ALoCoQlwc9mPCwWIUMdFDbcsaQbcMEocsWumhsj6IJ1vvr178PIogDisayNT9Hy27YArHNyZflkJa5tYyplKc3wa/HjUKsYBH606GhTY5/Ey51ybGuLsSgS9ChwsQpjDrZzlGUTn4hjUZ5Obkk/aeRxaxwKUPw/Cww== X-Received: by 10.152.30.68 with SMTP id q4mr831553lah.44.1391502653913; Tue, 04 Feb 2014 00:30:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.30.68 with SMTP id q4mr831538lah.44.1391502653733; Tue, 04 Feb 2014 00:30:53 -0800 (PST) Received: by 10.112.164.35 with HTTP; Tue, 4 Feb 2014 00:30:53 -0800 (PST) In-Reply-To: References: <20130906074540.19067.67943.idtracker@ietfa.amsl.com> Date: Tue, 4 Feb 2014 17:30:53 +0900 Message-ID: From: SeongHan Shin To: Trevor Perrin Content-Type: multipart/alternative; boundary=089e0160b42c614e5f04f1907524 Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= , cfrg@ietf.org, "tls@ietf.org" Subject: Re: [TLS] [Cfrg] I-D Action: draft-irtf-cfrg-augpake-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 08:30:59 -0000 --089e0160b42c614e5f04f1907524 Content-Type: text/plain; charset=ISO-8859-1 Hi Trevor, I am sorry for this delay. > - There's obvious similarities with SRP. Do you think the AugPAKE >proof techniques could be used to make a security proof for SRP? I don't think so because the security of SRP cannot be reduced to the SDH assumption. >(For >an elliptic curve SRP, you could imagine using the SRP verifier with >Elligator to encrypt the g^b value, instead of SRP's traditional "B = >kv + g^b"). In case of SRP5 (EC version of SRP6), I think it may be possible. >taken in your TLS draft [1]). The latest version of SRP [2] was able >to remove this constraint. Is it possible to do the same for AugPAKE? The same approach does not work for AugPAKE. >or >requires the client to assume the group and use no salt (the approach >taken in your TLS draft [1]). One option may be to use the Supported Elliptic Curve Extension [RFC4492] though the tls-augpake draft does not specify over ec groups. Best regards, Shin On Tue, Dec 10, 2013 at 4:41 AM, Trevor Perrin wrote: > Hi Shin, > > Just to be clear - I was making fun of Kevin Igoe, not yourself - > AugPAKE seems like a great piece of work. > > Couple questions: > > - There's obvious similarities with SRP. Do you think the AugPAKE > proof techniques could be used to make a security proof for SRP? (For > an elliptic curve SRP, you could imagine using the SRP verifier with > Elligator to encrypt the g^b value, instead of SRP's traditional "B = > kv + g^b"). > > - There seems to be an ordering constraint between AugPAKE's client > and server messages, requiring the client to go first. For TLS at > least, such a constraint is awkward. It either requires an extra > round-trip for the server to communicate the salt and group values, or > requires the client to assume the group and use no salt (the approach > taken in your TLS draft [1]). The latest version of SRP [2] was able > to remove this constraint. Is it possible to do the same for AugPAKE? > > > Trevor > > > [1] http://tools.ietf.org/html/draft-shin-tls-augpake-01 > > [2] > http://tools.ietf.org/html/rfc5054 > http://srp.stanford.edu/design.html > http://srp.stanford.edu/srp6.ps > > > On Fri, Dec 6, 2013 at 12:26 PM, Trevor Perrin wrote: > > I really like this idea & can find no problems. > > > > Since a single cursory opinion counts for CFRG consensus [1,2], > > consider this approved by CFRG and our NSA overseers. > > > > Thanks, come again! > > > > > > Trevor > > > > > > P.S. The treatment of random numbers could be improved, consider > > referencing NIST SP 800-90A. > > > > (psst Kevin ^^^ THIS is how it's done. *FINESSE*, or you'll never > > work the big leagues!) > > > > > > [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html > > [2] http://www.ietf.org/proceedings/84/minutes/minutes-84-tls > > > > > > On Sun, Sep 29, 2013 at 11:18 PM, SeongHan Shin > > wrote: > >> Dear all, > >> > >> We submitted our I-D regarding augmented PAKE > >> that provides extra protection to server compromise compared to balanced > >> PAKE. > >> (Of course, it can be easily converted to the balanced one) > >> > >> Any comments are welcome! > >> > >> Best regards, > >> Shin > >> > >> > >> On Fri, Sep 6, 2013 at 4:45 PM, wrote: > >>> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>> directories. > >>> This draft is a work item of the Crypto Forum Research Group Working > >>> Group of the IETF. > >>> > >>> Title : Augmented Password-Authenticated Key Exchange > >>> (AugPAKE) > >>> Author(s) : SeongHan Shin > >>> Kazukuni Kobara > >>> Filename : draft-irtf-cfrg-augpake-00.txt > >>> Pages : 17 > >>> Date : 2013-09-06 > >>> > >>> Abstract: > >>> This document describes a secure and highly-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). Also, this > >>> protocol provides resistance to server compromise in the context > that > >>> an attacker, who obtained the password verifier from the server, > must > >>> at least perform off-line dictionary attacks to gain any advantage > in > >>> impersonating the user. The AugPAKE protocol is not only provably > >>> secure in the random oracle model but also the most efficient over > >>> the previous augmented PAKE protocols (SRP and AMP). > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00 > >>> > >>> > >>> 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/ > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> http://www.irtf.org/mailman/listinfo/cfrg > >> > >> > >> > >> > >> -- > >> ------------------------------------------------------------------ > >> 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 > >> ------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Cfrg mailing list > >> Cfrg@irtf.org > >> http://www.irtf.org/mailman/listinfo/cfrg > >> > -- ------------------------------------------------------------------ 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 ------------------------------------------------------------------ --089e0160b42c614e5f04f1907524 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Trevor,

I am sorry for this delay.
> - There's obvious similarities with SRP. =A0Do you think the = AugPAKE
>proof techniques could be used to make a security proof for SRP?
I don't think so because the security= of SRP cannot be reduced to the SDH assumption.

>(For
>an elliptic curve SRP, you could imagine using the SRP verifier with >Elligator to encrypt the g^b value, instead of SRP's traditional &q= uot;B =3D
>kv + g^b").
In case of SRP5 (E= C version of SRP6), I think it may be possible.


>taken in your TLS draft [1]). =A0The latest version of SRP [2] was = able
>to remove this constraint. =A0Is it possible to do the same for AugPAKE= ?
The same approach does not work for A= ugPAKE.

>or
>requires the client to assume the group and use no salt (the approach >taken in your TLS draft [1]).
One = option may be to use the Supported Elliptic Curve Extension [RFC4492]
though the tls-augpake draft does not specif= y over ec groups.

Best regards,
Shin


On Tue, Dec 10, 2013= at 4:41 AM, Trevor Perrin <trevp@trevp.net> wrote:
Hi Shin,

Just to be clear - I was making fun of Kevin Igoe, not yourself -
AugPAKE seems like a great piece of work.

Couple questions:

=A0- There's obvious similarities with SRP. =A0Do you think the AugPAKE=
proof techniques could be used to make a security proof for SRP? =A0(For an elliptic curve SRP, you could imagine using the SRP verifier with
Elligator to encrypt the g^b value, instead of SRP's traditional "= B =3D
kv + g^b").

=A0- There seems to be an ordering constraint between AugPAKE's client<= br> and server messages, requiring the client to go first. =A0For TLS at
least, such a constraint is awkward. =A0It either requires an extra
round-trip for the server to communicate the salt and group values, or
requires the client to assume the group and use no salt (the approach
taken in your TLS draft [1]). =A0The latest version of SRP [2] was able
to remove this constraint. =A0Is it possible to do the same for AugPAKE?

Trevor


[1] http://tools.ietf.org/html/draft-shin-tls-augpake-01

[2]
=A0http://= tools.ietf.org/html/rfc5054
=A0http:/= /srp.stanford.edu/design.html
=A0http://srp= .stanford.edu/srp6.ps


On Fri, Dec 6, 2013 at 12:26 PM, Trevor Perrin <trevp@trevp.net> wrote:
> I really like this idea & can find no problems.
>
> Since a single cursory opinion counts for CFRG consensus [1,2],
> consider this approved by CFRG and our NSA overseers.
>
> Thanks, come again!
>
>
> Trevor
>
>
> P.S. The treatment of random numbers could be improved, consider
> referencing NIST SP 800-90A.
>
> (psst Kevin ^^^ THIS is how it's done. =A0*FINESSE*, or you'll= never
> work the big leagues!)
>
>
> [1] http://www.ietf.org/mail-archive/web/cfrg/curre= nt/msg03047.html
> [2] http://www.ietf.org/proceedings/84/minutes/minutes-84= -tls
>
>
> On Sun, Sep 29, 2013 at 11:18 PM, SeongHan Shin
> <seon= ghan.shin@aist.go.jp> wrote:
>> Dear all,
>>
>> We submitted our I-D regarding augmented PAKE
>> that provides extra protection to server compromise compared to ba= lanced
>> PAKE.
>> (Of course, it can be easily converted to the balanced one)
>>
>> Any comments are welcome!
>>
>> Best regards,
>> Shin
>>
>>
>> On Fri, Sep 6, 2013 at 4:45 PM, <internet-drafts@ietf.org> wrote:
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Dr= afts
>>> directories.
>>> =A0This draft is a work item of the Crypto Forum Research Grou= p Working
>>> Group of the IETF.
>>>
>>> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Augmented Password= -Authenticated Key Exchange
>>> (AugPAKE)
>>> =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : SeongHan Shin
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kazukuni K= obara
>>> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-irtf-cfrg-augp= ake-00.txt
>>> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 17
>>> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-09-06
>>>
>>> Abstract:
>>> =A0 =A0This document describes a secure and highly-efficient a= ugmented
>>> =A0 =A0password-authenticated key exchange (AugPAKE) protocol = where a user
>>> =A0 =A0remembers a low-entropy password and its verifier is re= gistered in
>>> =A0 =A0the intended server. =A0In general, the user password i= s chosen from a
>>> =A0 =A0small set of dictionary whose space is within the off-l= ine dictionary
>>> =A0 =A0attacks. =A0The AugPAKE protocol described here is secu= re against
>>> =A0 =A0passive attacks, active attacks and off-line dictionary= attacks (on
>>> =A0 =A0the obtained messages with passive/active attacks). =A0= Also, this
>>> =A0 =A0protocol provides resistance to server compromise in th= e context that
>>> =A0 =A0an attacker, who obtained the password verifier from th= e server, must
>>> =A0 =A0at least perform off-line dictionary attacks to gain an= y advantage in
>>> =A0 =A0impersonating the user. =A0The AugPAKE protocol is not = only provably
>>> =A0 =A0secure in the random oracle model but also the most eff= icient over
>>> =A0 =A0the previous augmented PAKE protocols (SRP and AMP). >>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-a= ugpake
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00=
>>>
>>>
>>> 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/
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.o= rg
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------------=
>> 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
>> ------------------------------------------------------------------=
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>>



--
---------------------------------------------= ---------------------
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 : +8= 1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan.shin@aist.go.jp
------------------------------------------------------------------
--089e0160b42c614e5f04f1907524-- From seonghan.shin@aist.go.jp Tue Feb 4 01:23:20 2014 Return-Path: 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 DF4D91A03CC for ; Tue, 4 Feb 2014 01:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 HeL_EFYI2QR4 for ; Tue, 4 Feb 2014 01:23:18 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 62B401A03C7 for ; Tue, 4 Feb 2014 01:23:18 -0800 (PST) Received: from mail-lb0-f179.google.com ([209.85.217.179]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUvCxhqBtxor8y7EyBcwwbHt2jSujP98M@postini.com; Tue, 04 Feb 2014 01:23:18 PST Received: by mail-lb0-f179.google.com with SMTP id l4so6300827lbv.10 for ; Tue, 04 Feb 2014 01:23:16 -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=oBcNQNMO8TuHZ9W/H3WJE/Bdpdtr7dBmxumyATFlxC8=; b=oF2jZ3+l9djj1lHWaUn/q5BObX6gsOeLxCxEINslOFI2R91CWenx+bv367fyeVbkYI 0bpmpb6tfQiv8c2nU4zoeiH+Atkg1aP3Tp3rb/qD1kf8OX81VH51vurmEuK0c4kbmuP4 fgJww25RzGbfCV4hOHZgI+BYrs4TqZCGQNrbQ= 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=oBcNQNMO8TuHZ9W/H3WJE/Bdpdtr7dBmxumyATFlxC8=; b=cmubuBkF86ffbJ8Wz+ifE7+xkFEiRtbYngmZLlIpyner40FLHRu4aJwGJVd7Ylt1/N dcfm4z0/AX17pYJgCXWLP8BFBpCSbgosrZFe/+h9NkWMMr2ZboBfTOCXKkIKmw4meHz9 2OJGG6d+GsMxWKcm0ggN2UO1KPcw+2vcUXbg6mR0rLfQdjacKXsS7X0CJ846Qxs4QSko SYP8WywlgmRu0BMOe3t2Sed20S5wW3jvfvLZ/WgzTb3hQnXYTFGJ5x8PPKrY4D9ZgTxL PaxV0eusC8oZRdX3E1HggRo7ZpEPsBaSZoCUGRjQztkitnxLEByB2FGMY24njKOYw8+z 9REw== X-Gm-Message-State: ALoCoQkQ4jyGf8rFnNWVa79FBWQVUcPartD9kzYsXOkX0t+ICidCzm6YtPDFml+qv2COoJg0z0GmR5sinku/kcg7mByemT24lwEO+kD2vrDEIAJlMUYSnCKNYociUOlttPCfjNGFrNAwTF1BfGE0vJtQSkLJMx+TVw== X-Received: by 10.112.97.173 with SMTP id eb13mr253363lbb.65.1391505796350; Tue, 04 Feb 2014 01:23:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.97.173 with SMTP id eb13mr253358lbb.65.1391505796278; Tue, 04 Feb 2014 01:23:16 -0800 (PST) Received: by 10.112.164.35 with HTTP; Tue, 4 Feb 2014 01:23:16 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Feb 2014 18:23:16 +0900 Message-ID: From: SeongHan Shin To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1133e9dcb0b95604f19130ba Cc: "tls@ietf.org" Subject: Re: [TLS] Remarks on draft-shin-tls-augpake-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:23:21 -0000 --001a1133e9dcb0b95604f19130ba Content-Type: text/plain; charset=ISO-8859-1 Hi Watson, Thank you for your comments! A simple way to make AugPAKE to be group agnostic is to convert AugPAKE to balanced one. Of course, I need to think about other ways. A description of AugPAKE over ec groups would be added after the 89th meeting. Best regards, Shin On Wed, Jan 8, 2014 at 3:11 AM, Watson Ladd wrote: > Given that Dragonfly refuses to die, I think it is worth considering > AugPAKE. I've changed my mind about the necessity: the IoT people want > it badly, and if we don't do this, it will be Dragonfly. > > The only issue I see is the draft needs to be made group agnostic and > work on some sufficiently big ECC group. That's a straightforward, if > tedious, change of notation. > > Sincerely, > Watson Ladd > _______________________________________________ > 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 ------------------------------------------------------------------ --001a1133e9dcb0b95604f19130ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Watson,

Than= k you for your comments!
A simple way to make AugPAKE to be group = agnostic is to convert AugPAKE to balanced one.
Of course, I need = to think about other ways.

A description of AugPAKE over ec groups would be added after the = 89th meeting.

Best regards,
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 : +8= 1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan= .shin@aist.go.jp
------------------------------------------------------------------
--001a1133e9dcb0b95604f19130ba-- From ilari.liusvaara@elisanet.fi Tue Feb 4 04:50:07 2014 Return-Path: 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 9401D1A0415 for ; Tue, 4 Feb 2014 04:50:07 -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 onhes9BEukJW for ; Tue, 4 Feb 2014 04:50:05 -0800 (PST) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id 522E11A03E5 for ; Tue, 4 Feb 2014 04:50:05 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 29A6F6998D; Tue, 4 Feb 2014 14:50:02 +0200 (EET) Date: Tue, 4 Feb 2014 14:50:02 +0200 From: Ilari Liusvaara To: SeongHan Shin Message-ID: <20140204125002.GA30862@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: "tls@ietf.org" Subject: Re: [TLS] Remarks on draft-shin-tls-augpake-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 12:50:07 -0000 On Tue, Feb 04, 2014 at 06:23:16PM +0900, SeongHan Shin wrote: > Hi Watson, > > Thank you for your comments! > A simple way to make AugPAKE to be group agnostic is to convert AugPAKE to > balanced one. > Of course, I need to think about other ways. I think Watson meant generalizing AugPAKE over arbitrary group with appropriate hardness properties. Especially elliptic-curve ones. I see nothing that wouldn't map in straightforward manner into elliptic curves and only bn2bin(X) that wouldn't map in straightforward manner to completely arbitrary group. As for the -1, 0, 1 check, that can be replaced with check that: a) The element is valid (e.g. nonzero or satisfies curve equation) AND b) The order of element has prime factor of at least q Those checks are quite cheap with most actually used elliptic curves. Also, some misc feedback: - What's the endian of bn2bin(X)? Big endian? - How are X and Y encoded on the wire? bn2bin? - Maybe expand on consequences of terminating on invalid username (allowing probing of valid usernames)? -Ilari From sm@elandsys.com Tue Feb 4 11:25:41 2014 Return-Path: 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 D18C21A0203 for ; Tue, 4 Feb 2014 11:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 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.535] 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 Cq2qYvZRYixs for ; Tue, 4 Feb 2014 11:25:40 -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 07D2E1A01F6 for ; Tue, 4 Feb 2014 11:25:39 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.156.211]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s14JPLJv009974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Feb 2014 11:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1391541939; bh=pGDCMScgTi4VVgJadZZUXEGkxwOWdW1I/QZxwLZXLoI=; h=Date:To:From:Subject; b=ky+g/fRtjRy4I+mToI6qQayXtnf3mYPciiDMBHt9vnYK95CTTenrxzCcJc6fnFU9f SUQ4TiPoteggRxPPZlveO3/MxulkIGKzLoOsV8Ej1CGbKevH3YB67LE65cfUZXx0X5 XiBkrM1cSXl2ixacCnN0TMv6bAKUCVKijDwpdI9M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1391541939; i=@elandsys.com; bh=pGDCMScgTi4VVgJadZZUXEGkxwOWdW1I/QZxwLZXLoI=; h=Date:To:From:Subject; b=gqGBkJNsVKWjNKAF3iZd1fcmVKLvJclxpikQO4G/4m0BOACAHUJeekLz+y0ftcHSX eJLPKmBuzwqUGsLGLG3EtKjIH7WaJFAVTHdRybPW6pXQ9ikDGti5wPkDRAb0zTHW5X J4N0PiEd5cH61wuT7MYL2zM9Ywk0tHgBd7xq2c4M= Message-Id: <6.2.5.6.2.20140204112043.0aec9fd8@elandsys.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 04 Feb 2014 11:20:57 -0800 To: tls@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [TLS] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:25:42 -0000 Hello, As a FYI: The Ed25519 signature algorithm has recently been implemented in OpenSSH. This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519. http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-00 Regards, S. Moonesamy From seonghan.shin@aist.go.jp Tue Feb 4 22:32:51 2014 Return-Path: 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 CD2031A004C for ; Tue, 4 Feb 2014 22:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 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, RCVD_IN_DNSWL_MED=-2.3, 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 zEtdSC-JXLGN for ; Tue, 4 Feb 2014 22:32:50 -0800 (PST) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id 947911A004A for ; Tue, 4 Feb 2014 22:32:49 -0800 (PST) Received: from mail-lb0-f182.google.com ([209.85.217.182]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUvHbEGd+/RdKkM4ojdJ0uhlRFox8oBZA@postini.com; Tue, 04 Feb 2014 22:32:49 PST Received: by mail-lb0-f182.google.com with SMTP id w7so7383456lbi.27 for ; Tue, 04 Feb 2014 22:32:47 -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=tIbQz4/Pl0Fsx/A8D72lw9yiOjn24ZCf0Ak2fm8s+3w=; b=rohVITxwJKAR5norlYQnRwNP04wQrdQbURKukJhuyX2nUY3fFpmjN0PBtfAqw0WXZg QRCOzo0uZz+EZ1taERQ5r0iKyC9vg3Luc3UTAmwOTbFgapykmuRNfBHIbMXSL2MzvxcG GkvdxHq8vNlgUZTt6MjUCD0B/1eGwWgzFo9WI= 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=tIbQz4/Pl0Fsx/A8D72lw9yiOjn24ZCf0Ak2fm8s+3w=; b=TcPqcUCdrVgpfIO4JlWmMo9B6m0GLLzBcUfqiStz9aC56sYKgw1wPUZywipG2qzcOa EYGzouE2dwz3jVlicAMddBIMhDr09gaLfmpERLVoZEeTTp1fYo5zR8MLqiD8+WTuYNRf IdehAEsxaxy7fOfxfYvxYu4lBFDZ8I0q0Ym+GnLTUSgtTByOesD3fLSN508TwrrDMqFz uTTDomNSKLg/WKQhmpsAimaDY5jBUmrGEmr98vCUm/1CkjZYSVpAB7qighpdPgKxHElA DJlOgAR/Ds+cgetxsGExWilziyDJtvjQ05hSdbUHPO4Ug49Vtiv7yTSW4jShJtMWMx3I kuRA== X-Gm-Message-State: ALoCoQlxN012XJaTtnzvYY8pL20HxizuFMdqcZSOMWcMqPNmHW3BPVhzJ8vENgOaj0E+PycB7lR6GkuQOijoPD7rGke6Sog1DybUMRG5ogQU1sRkuUIx4TF+3yWxR8/Wz693H7s9DB3YbK4UjlnDLckZ4MjR0ImvGA== X-Received: by 10.152.170.135 with SMTP id am7mr20890198lac.23.1391581967429; Tue, 04 Feb 2014 22:32:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.170.135 with SMTP id am7mr20890187lac.23.1391581967346; Tue, 04 Feb 2014 22:32:47 -0800 (PST) Received: by 10.112.164.35 with HTTP; Tue, 4 Feb 2014 22:32:47 -0800 (PST) In-Reply-To: <20140204125002.GA30862@LK-Perkele-VII> References: <20140204125002.GA30862@LK-Perkele-VII> Date: Wed, 5 Feb 2014 15:32:47 +0900 Message-ID: From: SeongHan Shin To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=089e0122797ad6fcaf04f1a2ec32 Cc: "tls@ietf.org" Subject: Re: [TLS] Remarks on draft-shin-tls-augpake-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 06:32:52 -0000 --089e0122797ad6fcaf04f1a2ec32 Content-Type: text/plain; charset=ISO-8859-1 Hi llari, Thank you for your clarity and feedbacks. >- What's the endian of bn2bin(X)? Big endian? >- How are X and Y encoded on the wire? bn2bin? The draft does not specify the above points because these depend on implementations. >- Maybe expand on consequences of terminating on invalid username I think the current check on authenticators is fine. > (allowing probing of valid usernames)? An orthodox way is to use DHE for encrypting usernames. This will be added in "Security Considerations" section. Best regards, Shin On Tue, Feb 4, 2014 at 9:50 PM, Ilari Liusvaara wrote: > On Tue, Feb 04, 2014 at 06:23:16PM +0900, SeongHan Shin wrote: > > Hi Watson, > > > > Thank you for your comments! > > A simple way to make AugPAKE to be group agnostic is to convert AugPAKE > to > > balanced one. > > Of course, I need to think about other ways. > > I think Watson meant generalizing AugPAKE over arbitrary group with > appropriate hardness properties. Especially elliptic-curve ones. > > > I see nothing that wouldn't map in straightforward manner into elliptic > curves and only bn2bin(X) that wouldn't map in straightforward manner > to completely arbitrary group. > > > As for the -1, 0, 1 check, that can be replaced with check that: > a) The element is valid (e.g. nonzero or satisfies curve equation) AND > b) The order of element has prime factor of at least q > > Those checks are quite cheap with most actually used elliptic curves. > > > Also, some misc feedback: > - What's the endian of bn2bin(X)? Big endian? > - How are X and Y encoded on the wire? bn2bin? > - Maybe expand on consequences of terminating on invalid username > (allowing probing of valid usernames)? > > > > -Ilari > -- ------------------------------------------------------------------ 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 ------------------------------------------------------------------ --089e0122797ad6fcaf04f1a2ec32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi llari,

Thank you for your clarity and= feedbacks.

>- What's th= e endian of bn2bin(X)? Big endian?
>- How are X and Y encoded on the wire? bn2bin?
The draft does not specify the above points because these depen= d on implementations.

>- Maybe expand on consequences of terminat= ing on invalid username
I think the current check on authenticator= s is fine.

>=A0 (allowing probing of valid usernames)?
<= div class=3D"gmail_extra">An orthodox way is to use DHE for encrypting user= names.
This will be added in "Security Consi= derations" section.

Best regar= ds,
Shin

On Tue, Feb 4, 2014 at 9:50 PM, Ilari Liusva= ara <ilari.liusvaara@elisanet.fi> wrote:
On Tue, Feb 04, 2014 at 06:23:16PM +0900, SeongHan Shin w= rote:
> Hi Watson,
>
> Thank you for your comments!
> A simple way to make AugPAKE to be group agnostic is to convert AugPAK= E to
> balanced one.
> Of course, I need to think about other ways.

I think Watson meant generalizing AugPAKE over arbitrary group with appropriate hardness properties. Especially elliptic-curve ones.


I see nothing that wouldn't map in straightforward manner into elliptic=
curves and only bn2bin(X) that wouldn't map in straightforward manner to completely arbitrary group.


As for the -1, 0, 1 check, that can be replaced with check that:
a) The element is valid (e.g. nonzero or satisfies curve equation) AND
b) The order of element has prime factor of at least q

Those checks are quite cheap with most actually used elliptic curves.


Also, some misc feedback:
- What's the endian of bn2bin(X)? Big endian?
- How are X and Y encoded on the wire? bn2bin?
- Maybe expand on consequences of terminating on invalid username
=A0 (allowing probing of valid usernames)?



-Ilari



--
--------------------------------------------= ----------------------
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 : +8= 1-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : seonghan= .shin@aist.go.jp
------------------------------------------------------------------
--089e0122797ad6fcaf04f1a2ec32-- From iesg-secretary@ietf.org Thu Feb 6 08:41:51 2014 Return-Path: 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 02B951A03FB; Thu, 6 Feb 2014 08:41:51 -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 U9yVeNqTdngx; Thu, 6 Feb 2014 08:41:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2141A0431; Thu, 6 Feb 2014 08:41:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206164140.25549.54952.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 08:41:40 -0800 Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-oob-pubkey-11.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 16:41:51 -0000 The IESG has approved the following document: - 'Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' (draft-ietf-tls-oob-pubkey-11.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ Technical Summary This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation Working Group Summary In general the consensus around the document is strong. The main area of contention was in the reuse of the certificate type registry. This has been satisfactorily resolved. Document Quality There are a number of implementations of the protocol in progress. This document has had review by members of the DANE working group and the LWIG working group. Personnel Joseph Salowey is the Document Shepherd. Sean Turner is the Responsible Area Director. From iesg-secretary@ietf.org Fri Feb 7 10:03:02 2014 Return-Path: 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 736CE1A03E1; Fri, 7 Feb 2014 10:03:02 -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 QpSDXfDbf_E9; Fri, 7 Feb 2014 10:02:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F06DB1AC7F0; Fri, 7 Feb 2014 10:02:58 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207180258.26073.51442.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 10:02:58 -0800 Cc: tls WG Subject: [TLS] WG Action: Rechartered Transport Layer Security (tls) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 18:03:02 -0000 The Transport Layer Security (tls) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Transport Layer Security (tls) ------------------------------------------------ Current Status: Active WG Chairs: Eric Rescorla Joseph Salowey Eric Rescorla Technical advisors: Allison Mankin Assigned Area Director: Sean Turner Mailing list Address: tls@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: http://www.ietf.org/mail-archive/web/tls/ Charter: The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0, v1.1, and v1.2 and DTLS (Datagram TLS) v1.2 as well as extensions to the protocols and ciphersuites. The primary purpose of the working group is to develop (D)TLS v1.3. Some of the main design goals are as follows, in no particular order: o Develop a mode that encrypts as much of the handshake as is possible to reduce the amount of observable data to both passive and active attackers. o Develop modes to reduce handshake latency, which primarily support HTTP-based applications, aiming for one roundtrip for a full handshake and one or zero roundtrip for repeated handshakes. The aim is also to maintain current security features. o Update record payload protection cryptographic mechanisms and algorithms to address known weaknesses in the CBC block cipher modes and to replace RC4. o Reevaluate handshake contents, e.g.,: Is time needed in client hello? Should signature in server key exchange cover entire handshake? Are bigger randoms required? Should there be distinct cipher list for each version? Are additional mechanisms needed to prevent version rollback needed? o The WG will consider the privacy implications of TLS1.3 and where possible (balancing with other requirements) will aim to make TLS1.3 more privacy-friendly, e.g. via more consistent application traffic padding, more considered use of long term identifying values, etc. A secondary purpose is to maintain previous version of the (D)TLS protocols as well as to specify the use of (D)TLS, recommendations for use of (D)TLS, extensions to (D)TLS, and cipher suites. However, changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. With these objectives in mind, the TLS WG will also place a priority in minimizing gratuitous changes to TLS. Milestones: Jan 2014 - CBC Fixes to IESG May 2014 - RC4 replacement to IESG Nov 2014 - (D)TLS 1.3 to IESG From yngve@spec-work.net Sun Feb 9 08:41:07 2014 Return-Path: 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 60E371A0184 for ; Sun, 9 Feb 2014 08:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 KfdZeXl7bCxm for ; Sun, 9 Feb 2014 08:41:04 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id B2A661A0144 for ; Sun, 9 Feb 2014 08:41:03 -0800 (PST) Received: from 157.168.202.84.customer.cdi.no ([84.202.168.157]:65470 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WCXRG-0006fN-FP; Sun, 09 Feb 2014 17:41:02 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Bodo Moeller" References: Date: Sun, 09 Feb 2014 17:40:53 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 16:41:07 -0000 Hi, Sorry about the delay, I did not have the data available until this week, due to hardware problems. On Mon, 27 Jan 2014 12:03:29 +0100, Bodo Moeller wrote: >> 2) The use of this SCSV require both client and server to be updated to >> understand the SCSV. The deployment of such a fix is going to take a >> minimum of 5-10 years (The renego patch, fixing a major security >> vulnerability, have only recently passed 80%, more than 3 years after it >> was released). I would prefer a solution that only require one party, >> the >> client, to be updated. >> > > Your 5-10 year estimate is for wide deployment. Narrower deployment can > happen much quicker: once you update your client, you get the expected > protection for all connections to those servers that have been updated. > Even if that's just 1% of *all* servers, that 1% might include those > servers you care about most. A percentage of servers isn't a very useful > metric (and even a percentage of appropriately specified "sessions" > couldn't do justice to the fact that security will be much more important > for some of these than for others). This depends on whether they are on your list of most important sites. Taking the renego deployment as an example, at present, 4 years after publication of RFC 5746, 16.7% of the 526000 servers I sampled yesterday are not patched (54.7% vulnerable). In the Alexa top million segment the unpatched rate was 17.97% (51% vulnerable), in the top 1% (10K) the unpatched rate is 25.7% (44% vulnerable). For reference, a year after the publication of RFC 5746 52% of (327K) servers were unpatched, 67.7% of Alexa top 10K and 77% of top 100 weren't. Based on the current patch rate, 7.3% per year, we are looking at at least another 2.5 years before all servers are patched. That is 6.5 years after release of the RFC, for what can be considered a critical patch. I doubt this SCSV will be considered a critical patch, so it will be most likely be considered something that is added to the newest versions of servers, probably versions that is rolled out a year or (more likely) two years after publication of the RFC, and not backported as patches to older versions. Adoption rate will probably be more like the phasing out of SSL v3-only servers (currently 0.88% of servers (0.97% 3 years ago), 1.04% of Alexa top million, 1.4% of Aleaxa top 10K, although none in Alexa top 100), which have been going on for 15 years now, and if we just extrapolate based on the reduction rate and assume client vendors don't put any pressure on sites, it will probably take another 30 years to complete the phaseout. Assuming that the Alexa list is a fair representation of which sites are important to most users, this does not exactly fill me with confidence that the posited 1% SCSV patched sites will include the ones a security minded user will consider important. As for how many servers are intolerant (of SSL v3-only servers in parenthesis) [of Renego patched in square brackets, all servers]: Version intolerance TLS 1.0-TLS 1.2 : 0.7% (4.9%)[0.20%] Version intolerance TLS 1.3+ : 2.6% (5.4%)[1.18%] Extension intolerance TLS 1.0-TLS 1.2: 0.98% (19.7%)[0.29%] Extension or version intolerance TLS 1.0-TLS 1.2: 1.07% (19.8%)[0.41%] Renego patched SSL v3-only: 42% For further reference, below is a sample of the top domains that have servers that are NOT patched for the renego issue as of yesterday. Keep in mind that my sample list includes many servers that are not the main front line servers; they may, for example, have patched "www", "login" and other frontline servers, but not other servers that the user may encounter in their perusal of the site, and which may handle important aspects of their transactions. Yahoo.com + national domains Amazon.com + national domains ebay.com + national domains linkedin.com microsoft.com mail.ru 163.com fc2.com paypal.com craiglist.com ask.com apple.com imdb.com bbc.co.uk aol.com adobe.com rakuten.co.jp liverdoor.com netflix.com uol.com.br alibaba.com -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From yngve@spec-work.net Wed Feb 12 16:38:54 2014 Return-Path: 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 0BED01A0054 for ; Wed, 12 Feb 2014 16:38:54 -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 uANIP1PezBqu for ; Wed, 12 Feb 2014 16:38:46 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 745451A0047 for ; Wed, 12 Feb 2014 16:38:46 -0800 (PST) Received: from 157.168.202.84.customer.cdi.no ([84.202.168.157]:60812 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1WDkKC-0006uE-VF for tls@ietf.org; Thu, 13 Feb 2014 01:38:44 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: <20140213003542.4443.6488.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 01:38:32 +0100 To: "tls@ietf.org" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20140213003542.4443.6488.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/12.16 (Win32) Subject: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-03.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 00:38:54 -0000 Hi, FYI, I have refreshed my draft describing the prevention of rollback using the Renego indication extension as a proxy indication of version and extension tolerance. ------- Forwarded message ------- From: internet-drafts@ietf.org To: "Yngve N. Pettersen" Cc: Subject: New Version Notification for draft-pettersen-tls-version-rollback-removal-03.txt Date: Thu, 13 Feb 2014 01:35:42 +0100 A new version of I-D, draft-pettersen-tls-version-rollback-removal-03.txt has been successfully submitted by Yngve N. Pettersen and posted to the IETF repository. Name: draft-pettersen-tls-version-rollback-removal Revision: 03 Title: Managing and removing automatic version rollback in TLS Clients Document date: 2014-02-13 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-pettersen-tls-version-rollback-removal-03.txt Status: https://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal/ Htmlized: http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-pettersen-tls-version-rollback-removal-03 Abstract: Ever since vendors started deploying TLS 1.0 clients, these clients have had to handle server implementations that do not tolerate the TLS version supported by the client, usually by automatically signaling an older supported version instead. Such version rollbacks represent a potential security hazard, if the older version should become vulnerable to attacks. The same history repeated when TLS Extensions were introduced, as some servers would not negotiate with clients that sent these protocol extensions, forcing clients to reduce protocol functionality in order to maintain interoperability. This document outlines a procedure to help clients decide when they may use version rollback to maintain interoperability with legacy servers, under what conditions the clients should not allow version rollbacks, such as when the server has indicated support for the TLS Renegotiation Information extension. The intention of this procedure is to limit the use of automatic version rollback to legacy servers and eventually eliminate its use. 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 -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From agl@google.com Thu Feb 13 07:53:05 2014 Return-Path: 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 8E3921A0294 for ; Thu, 13 Feb 2014 07:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 49Ds_LL6tXcb for ; Thu, 13 Feb 2014 07:53:04 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E5D061A01F7 for ; Thu, 13 Feb 2014 07:53:03 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so8250845vcb.17 for ; Thu, 13 Feb 2014 07:53:02 -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:content-transfer-encoding; bh=8swj3+2Rhfk75WYeC0I6at4HhL9zHoZFCZvyqZK5fb4=; b=odGc1gKS6Q057fE+f2dvI7tT27/U0/tYk7okNZVbrsqtXgo10NPkZ7g6opSE48DVfM G2R/Q2CFA9WVduMg2J0Ae8C0o0IaxuSaXTVMh3v7kg+c8mCRkkcxb8NfsC7VDpFiFVah N0OlNzeruFwNyNryhUlHJFLLbrE4uCRCYWYXhO8HqSblxUmG7g126Fr85b/35FVwT9zm yUrKxhvSn6x/9IusMCW7ZMZp1KoZMFrMEuIqULR+V66pOusmjcuZHzSjDg185ak55v3N BVAE010QN9gxS8Lf2MyKGK7qremp4MG12XdL5xRM9dyeg7JFJtuHZS1NeZmdh3ZHTX/w JItQ== 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=8swj3+2Rhfk75WYeC0I6at4HhL9zHoZFCZvyqZK5fb4=; b=kxIKpDnp2NE4G9JFAoSnphuv6Bvr3YXc/u8vZEwH92GjwaqFzX6bXKKFE1fWzRAyuf 2LJV8kLSLVPLpI0s29QFbj9RQWGnf29JV+ZMggtX6uQWGRX/nIDt3Tb2zjNpra1HhbWb MLQOTxP//KhKn8NyY+Fhet+dQ+rtU1gqydwTbUzuabAZXQF8snK5eITPuPZcZw90zpL3 zFPN8e2f8VLokqDji6JIV5DVlSj8SqytL2PLt4hYSLlzYyHlNEfp9ksMKgh4Sx7S4Ijf jvKQyqIXem5iC1oq1v09EGRRt4KkfF9LfMTewPeoTOlGSOxI2Vp4PM3wUGpdNeNg2nSa 70AA== X-Gm-Message-State: ALoCoQkN3AfzHDm2adj1bJNrkcY5N2AEZoa6A5UXtJ5WOziX00fQGRb6lCPmMCak+SS1cnay+P99rd372C3v7WgfA83PDkjD8CFzm21ssJkS2vGYDM4CQ9tra9lsOOIuhD/5w0lAGmlgbJhaRUYiarnmyGi+Xpw4MTiaxPHZyPGnrAxiQd46IqhW217JeHdsjOLfXbNNa1Vc X-Received: by 10.58.48.133 with SMTP id l5mr654444ven.36.1392306782516; Thu, 13 Feb 2014 07:53:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Thu, 13 Feb 2014 07:52:42 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Thu, 13 Feb 2014 10:52:42 -0500 Message-ID: To: =?UTF-8?Q?Niels_M=C3=B6ller?= , Nikos Mavrogiannopoulos , Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:53:05 -0000 On Thu, Feb 13, 2014 at 5:11 AM, Niels M=C3=B6ller w= rote: > 1. It would be nice with a couple of additional test cases for > AEAD_CHACHA20_POLY1305. In particular for the corner cases of empty > associated data and/or empty plaintext. Ack. Yoav pulled out the AEAD bit into https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01 so that it's not TLS specific and that's probably the place for this now. > 2. The input to the poly1305mac is defined as > > ad | length(ad) | cryptotext | length(cryptotext) > > As far as I understand, this is a bit redundant, since the second > length field is sufficient to make the encoding injective. Does using > two length fields increase security in some subtle way? I don't believe so, it was just habit to put a length on each piece. (The lengths were originally prefixes of the data. wtc suggested moving them to the end so that the AEAD could be computed without knowing the length of the data apriori. Although this does lead to the possibility of "streaming" APIs which I would discourage as they release unauthenticated plaintext and force others to also.) > At least in my implementantation, the length(ad) field causes some > additional complexity, so Could you elaborate on why knowing the length of the AD is problematic? > 3. Do you think reduced round variants of chacha make sense? If not, > the name "chacha-poly1305" is nicer than "chacha20-poly1305". I suspect that some folks will want reduced round variants since it's faster and the reduced round versions are holding up to analysis. Cheers AGL From nobody Thu Feb 13 10:25:53 2014 Return-Path: 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 F0CDB1A03A4 for ; Thu, 13 Feb 2014 10:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 e1lpIO6Ehu8B for ; Thu, 13 Feb 2014 10:25:50 -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 6004A1A0370 for ; Thu, 13 Feb 2014 10:25:50 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id g10so8633040vbg.0 for ; Thu, 13 Feb 2014 10:25:49 -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:content-transfer-encoding; bh=vOCnmZVoG+lBolIp4uTkn2iJ7HeDZT1mQtIEfiuP8PA=; b=aTjAb+TKwp3TpdNqyeKSG0vyLEJTxKdAtDxKqdRdjqtZnEVA1Hc6tI9pJq/FpzbrC0 IP6g0EWUlfYcrNjLN8zp8CIdyReH+WGPVtVpZq1hNNquEcmixU8ODZc+kKn4nt4a8VW5 fUZAeahkeUg0R0feSICtkImwK7c4oqhtXPrRQSL4vBuj4ovxQHvL0oBmfFWK+Fl7PfLU uirFLeCygN5NbGIijjS1IPaYLnFzVI9qj9cFJteCAST9e9O9bO1TNEtc5Q9AJ50Sz5Z1 Foeh7zebX3vVd1iuBdqyiQ8RW/QvTdihAHI0I6Nuxcoc1eUPtkjtZHFNxwqmk7mnqhAE jQ6g== 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 :content-transfer-encoding; bh=vOCnmZVoG+lBolIp4uTkn2iJ7HeDZT1mQtIEfiuP8PA=; b=BenipSR11zc750XrMd4K8VlLUkcaH73eSFwVru2mARyA7mdC23X/N1cPR01ei3xGG+ 0nmxNE+gjrFr6lppWFuLLiBa9THikfrHqArYUcBZYYjRvaeA3tIw+L/iKPEdPg0DIMai rDOQbavrvzz/POaeAoFYoefy/nJLTj7X3WcIaFkbJYpxLfWlSFr9sZSDuDDGBTtleZt0 UmRWkdsMRPZuPaA3XeiOwqm/X5+/8R/HnhXUUQ3t1cv3rbuFB7f3nDYhz6PZ/6TI+vxY a+qfanER+7IOSCSKh1VLHwtlO+cYrQGp97Eh9AVe46C3cmlIa08zsFgID0HF16zdir9z dbjg== X-Gm-Message-State: ALoCoQnn1FCfD1CTYe81GaOlDwWj+qZ0+5EObLM0ZvLPABK0BgrYneAoe5887dZm5fnq6oROHl2mXjxGhReTa3BzPZdzrOa1J4sFvoniS6Oa5bfyPbRl/X89xNwuNzasuHTf2b9a8sGPArbs77DM2Cf7ezdH3LEr6XSmBZTFPI/2zwjMcgSQ/9p+WPynKmp5NxPglWXy1UY9 MIME-Version: 1.0 X-Received: by 10.220.99.7 with SMTP id s7mr1750204vcn.19.1392315948914; Thu, 13 Feb 2014 10:25:48 -0800 (PST) Received: by 10.52.109.101 with HTTP; Thu, 13 Feb 2014 10:25:48 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 10:25:48 -0800 Message-ID: From: Wan-Teh Chang To: =?UTF-8?Q?Niels_M=C3=B6ller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lYaIp62uZiYVWZiEcYxgekZNFVk Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:25:52 -0000 Hi Niels, Adams already answered all of your questions. I'll just provide some additional info. draft-agl-tls-chacha20poly1305 has been merged into http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-01. But the specification of the ChaCha20-Poly1305 AEAD cipher suites did not change. On Thu, Feb 13, 2014 at 2:11 AM, Niels M=C3=B6ller w= rote: > > 2. The input to the poly1305mac is defined as > > ad | length(ad) | cryptotext | length(cryptotext) > > As far as I understand, this is a bit redundant, since the second > length field is sufficient to make the encoding injective. You are right. I suspect this may have been modeled after GCM. (GCM may have used two lengths to just to fill up a block for GHASH.) draft-mcgrew-aead-aes-cbc-hmac-sha2-02 does it in the way you suggested: T =3D MAC(MAC_KEY, A || S || AL), except that they use the length of the associated data (AL) instead. (A is the associated data. S is the ciphertext.) > At least in my implementantation, the length(ad) field causes some > additional complexity, so > > ad | cryptotext | length(cryptotext) > > would be preferable. I'm also curious to know why. What about ad | cryptotext | length(ad) ? Wan-Teh From nisse@lysator.liu.se Thu Feb 13 02:12:09 2014 Return-Path: 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 386171A0159 for ; Thu, 13 Feb 2014 02:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] 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 F2cLa2BFWaUc for ; Thu, 13 Feb 2014 02:12:06 -0800 (PST) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA991A011C for ; Thu, 13 Feb 2014 02:12:04 -0800 (PST) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s1DABxjW022630; Thu, 13 Feb 2014 11:11:59 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s1DABw5u022629; Thu, 13 Feb 2014 11:11:58 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: agl@google.com, wtc@google.com Date: Thu, 13 Feb 2014 11:11:58 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 14 Feb 2014 06:48:50 -0800 Cc: tls@ietf.org Subject: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:13:53 -0000 Hi, I have a couple of comments on https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/?include_text=1 I hope cc:ing the tls ietf list is appropriate (I'm not involved in this wg). 1. It would be nice with a couple of additional test cases for AEAD_CHACHA20_POLY1305. In particular for the corner cases of empty associated data and/or empty plaintext. 2. The input to the poly1305mac is defined as ad | length(ad) | cryptotext | length(cryptotext) As far as I understand, this is a bit redundant, since the second length field is sufficient to make the encoding injective. Does using two length fields increase security in some subtle way? At least in my implementantation, the length(ad) field causes some additional complexity, so ad | cryptotext | length(cryptotext) would be preferable. I'm not sure if this draft should be read as proposing a new aead construction, or if it documents an algorithm which is already deployed; in the latter case changes like this can't be made easily, of course. 3. Do you think reduced round variants of chacha make sense? If not, the name "chacha-poly1305" is nicer than "chacha20-poly1305". Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Fri Feb 14 06:48:55 2014 Return-Path: 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 7D2F11A0136 for ; Fri, 14 Feb 2014 00:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] 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 hgB5zA5w2Ryx for ; Fri, 14 Feb 2014 00:42:44 -0800 (PST) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id 08CA41A014C for ; Fri, 14 Feb 2014 00:42:43 -0800 (PST) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s1E8gS0f004574; Fri, 14 Feb 2014 09:42:28 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s1E8gOnG004573; Fri, 14 Feb 2014 09:42:24 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Fri, 14 Feb 2014 09:42:23 +0100 In-Reply-To: (Adam Langley's message of "Thu, 13 Feb 2014 10:52:42 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v0DYiBXyMsjhiOoc6y1269SbMN8 X-Mailman-Approved-At: Fri, 14 Feb 2014 06:48:52 -0800 Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 08:42:47 -0000 Adam Langley writes: > On Thu, Feb 13, 2014 at 5:11 AM, Niels Möller wrote: >> 1. It would be nice with a couple of additional test cases for >> AEAD_CHACHA20_POLY1305. In particular for the corner cases of empty >> associated data and/or empty plaintext. > > Ack. Yoav pulled out the AEAD bit into > https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01 so > that it's not TLS specific and that's probably the place for this now. Thanks for the pointer. This specifies a 96-bit nonce, both for chacha and chacha20-poly1305. I'm a bit confused by the different definition of chacha, with a 32-bit counter and 96-bit nonce, rather than 64 bits each like in the chacha spec. This discrepancy gives me the feeling that I definitely should consider my implementation as experimental, and not promise any compatibility until the dust settles. > (The lengths were originally prefixes of the data. wtc suggested > moving them to the end so that the AEAD could be computed without > knowing the length of the data apriori. Although this does lead to the > possibility of "streaming" APIs which I would discourage as they > release unauthenticated plaintext and force others to also.) I agree that most applications shouldn't use streaming operation, at least for decryption. But I also think there are valid usecases for streaming operation, e.g., processing a large file where you really want a single indication of autenticity for the complete file. In GNU Nettle, which is a general purpose but pretty low level crypto library, I'd like to support aead streaming operation whenever possible. >> At least in my implementantation, the length(ad) field causes some >> additional complexity, so > > Could you elaborate on why knowing the length of the AD is problematic? Knowing it is not a problem, but inserting it at that place in the poly1305 input is an annoyingly large proportion of the implementation, even if the total code size and complexity is pretty small. I have a low-level streaming interface (I'm considering adding a less general but more easy to use interface on top), with basically these functions for encryption (decryption is similar), to be called in order: set_key set_nonce (one or more times per key) update (process ad, zero or more times per nonce) encrypt (process plaintext, zero or more times per nonce digest (produce the authentication tag, once per nonce) Note that to keep this interface simple, there's no explicit function to mark the end of the ad; calling either of encrypt or digest implies the end of the associated data. Doing a final length field is very straighforward, it is added unconditionally by the digest function. However, inserting the ad length, between the ad and the crypto text, gets a bit more scattered. If encrypt is ever called, inserting the ad length has to be done for the first call to encrypt (or more precisely, I do it on the first call to encrypt providing a non-empty segment of plaintext, since for the bookkeeping I need to ensure that the ad length has been inserted if and only if the amount of processed plaintext is non-zero). But in case plaintext is empty, the ad length instead has to be inserted by the digest function. For some numbers, my current implementation is 101 non-comment lines of C (on top of chacha and poly1305 building blocks). Of those, 20% of the lines and 80% of the if statements are for the insertion of the ad length. See https://git.lysator.liu.se/nettle/nettle/blobs/master/chacha-poly1305.c (And I'm currently *not* confident that this code is correct, since I lack tests for the corner cases). > I suspect that some folks will want reduced round variants since it's > faster and the reduced round versions are holding up to analysis. I see. Vaguely related question: Do you see any need for 128-bit chacha keys? They're not really in the very short chacha paper, but they are in the reference implementation. Wan-Teh Chang writes: > draft-agl-tls-chacha20poly1305 has been merged into > http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-01. But > the specification of the ChaCha20-Poly1305 AEAD cipher suites did not > change. Thanks for the pointer. And here, chacha and chacha-poly1305 are both specified with a 64-bit nonce. > I'm also curious to know why. What about > > ad | cryptotext | length(ad) Adequately explained above, I hope. And the variant you propose should be as nice and simple to implement as ad | cryptotext | length(cryptotext). Or for that matter, ad | cryptotext | length(ad) | length(cryptotext) with both lenghts at the end, if for some reason including both length fields really is desirable. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Fri Feb 14 07:06:06 2014 Return-Path: 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 3186C1A027F for ; Fri, 14 Feb 2014 07:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] 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 KPhn4Erywo7w for ; Fri, 14 Feb 2014 07:05:58 -0800 (PST) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 797381A028B for ; Fri, 14 Feb 2014 07:05:58 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:42120 helo=[192.168.7.9]) by relay12.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1WEKKx-000527-7Z for tls@ietf.org (return-path ); Fri, 14 Feb 2014 15:05:55 +0000 Message-ID: <52FE30D0.9020200@drh-consultancy.co.uk> Date: Fri, 14 Feb 2014 15:05:52 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t3SANV_vU6D3bHHYGJgMT1WfAaI Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:06:00 -0000 On 14/02/2014 08:42, Niels Möller wrote: > Adam Langley writes: > >> (The lengths were originally prefixes of the data. wtc suggested >> moving them to the end so that the AEAD could be computed without >> knowing the length of the data apriori. Although this does lead to the >> possibility of "streaming" APIs which I would discourage as they >> release unauthenticated plaintext and force others to also.) > > I agree that most applications shouldn't use streaming operation, at > least for decryption. But I also think there are valid usecases for > streaming operation, e.g., processing a large file where you really want > a single indication of autenticity for the complete file. In GNU Nettle, > which is a general purpose but pretty low level crypto library, I'd like > to support aead streaming operation whenever possible. > Though not relevant to TLS there are also use cases where the whole length of the data is not known is advance. A couple of examples would be reading from a pipe or where the stream is obtained from an ASN1 BER decoder (CMS for example). 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 nobody Fri Feb 14 07:41:59 2014 Return-Path: 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 1907E1A025E; Fri, 14 Feb 2014 07:41:59 -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 4r5hwZ9HjZDA; Fri, 14 Feb 2014 07:41:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 103381A0242; Fri, 14 Feb 2014 07:41:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214154157.17975.11226.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 07:41:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hQrB4WwEKQxdGMy54IMN2yyQisI Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-16.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:41:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) Cached Information Extension Authors : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-16.txt Pages : 10 Date : 2014-02-14 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA). This document defines an extension that allows a TLS client to inform a server of cached information, allowing the server to omit already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-16 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 nobody Fri Feb 14 09:45:46 2014 Return-Path: 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 C3E6D1A0214 for ; Fri, 14 Feb 2014 09:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 NeV8Y5Q2YcJe for ; Fri, 14 Feb 2014 09:45:43 -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 3C8C11A02A5 for ; Fri, 14 Feb 2014 09:45:43 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so10202365veb.27 for ; Fri, 14 Feb 2014 09:45:41 -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:content-transfer-encoding; bh=g3xaSd4rcfeh/skc0LI47GgBwqWmO8u9AfNboxPwf54=; b=kjLYmv0TLemWPfgDxAotdS/Tpmm4bjK0Pxt8xMFGSAbthGmUmX5Fw0LyQrA+ZX/3VT vpfYBDbmwD/7ywfQa0xqWg36Ibue8D2Y6GQKaPvUvIgcgphLym9ydDB4vdQfpwCO3Gwa B3hbKQ0w1wfto700R00I1Rh0EPjL+UIG/UcoIUT/bYwV8nYBk2Z3gYvGtYUqL3wRWyOd PpKADVYy3a4VMGa98ArBjFXRgURPOPc5f6ajK39Lw8ci7kERMzgIqCPFU7IX18upUkEK jyxh4AiBYTTn0uKgB/tjlckUI5dVqxcNl7lMxJHTevkHGj2e0AIVAYskhzUyuhCsbalZ 2kLQ== 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=g3xaSd4rcfeh/skc0LI47GgBwqWmO8u9AfNboxPwf54=; b=PcWwaFnsTzSe1dfIuqsSiDhx6AQqM2VL3mTi4OaY07Ht+HfYpbDxY8UkApynRgH82d FPnUQyNmdaWuM5I8JI8FWUzyX79Zvjq80a20ow9NQjk4YMba/LlFNug3wR0+HPLzs+nb XTKvybWkvL29mK5kLr17xPzYQmJ5N7lgrEC74Jp8t1A93BBsJp9zHvt76ybXieVVxdRa Xe3m3hg6Sqo2pd/oZNmvUynL1/gsSsDkukjL+W2SMrirFRUXglCRvCc6lSw+Zhdv0eaA VvzCGdtiuRNswlw3ojv7HIQ7CO0Sk07ilytC0q2jan4gIf7TyygAwYO6Kph86jqw4PC8 zeGg== X-Gm-Message-State: ALoCoQl3DPGgODvM5sG3DtQzYIsmXOS6lCWtBJVKlegdzHhhx766gsSWLRRMKTbM2vuQZdC5Bi/jTAUeq3VTsHHRnbOKRuYhQE8OjSmIcHkum5G6bWpHCoqpVSN75nA4/ypkESD7cImcAol/epBQ1eEErM+IDaQgFhVcVoEqIVV4UI45C8h68aGcqiAt0HfjAOFGTleBmy0D X-Received: by 10.52.30.167 with SMTP id t7mr1622212vdh.36.1392399941385; Fri, 14 Feb 2014 09:45:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Fri, 14 Feb 2014 09:45:21 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 14 Feb 2014 12:45:21 -0500 Message-ID: To: =?UTF-8?Q?Niels_M=C3=B6ller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BQXaDD1LT2xjmr9MmJDQRorBO6Y Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:45:45 -0000 On Fri, Feb 14, 2014 at 3:42 AM, Niels M=C3=B6ller w= rote: > Thanks for the pointer. This specifies a 96-bit nonce, both for chacha > and chacha20-poly1305. I'm a bit confused by the different definition > of chacha, with a 32-bit counter and 96-bit nonce, rather than 64 bits > each like in the chacha spec. It appears that IPSec wants the extra 32 bits of nonce. Although this is an important change in definition it doesn't actually change the wire-format for TLS because the record-length limit means that those bits are always zero anyway in both cases. > I agree that most applications shouldn't use streaming operation, at > least for decryption. But I also think there are valid usecases for > streaming operation, e.g., processing a large file where you really want > a single indication of autenticity for the complete file. In GNU Nettle, > which is a general purpose but pretty low level crypto library, I'd like > to support aead streaming operation whenever possible. Keep in mind that it affects more than just your users. By making streaming designs easy you allow people to make bad designs (like CMS) that force streaming designs on others in order to handle large files. The point of AEADs is that it's an easier primitive to use. It would be doubly unfortunate if they ended up with a sharp edge by returning unauthenticated plaintext. > For some numbers, my current implementation is 101 non-comment lines of > C (on top of chacha and poly1305 building blocks). Of those, 20% of the > lines and 80% of the if statements are for the insertion of the ad > length. Thanks. I understand why omitting the length would be easier for you and it doesn't deeply bother me either way. The WG can figure it out. However, my preference would be to leave it as is because I've already got code that does it that way and I don't believe that streaming is something that should be made easy. > I see. Vaguely related question: Do you see any need for 128-bit chacha > keys? They're not really in the very short chacha paper, but they are in > the reference implementation. Since they are no faster I don't believe that anyone will want to support them. However, I may be wrong about that. Cheers AGL From nobody Fri Feb 14 09:45:50 2014 Return-Path: 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 5C30E1A030E for ; Fri, 14 Feb 2014 09:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=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 hG7uBEQMoHtA for ; Fri, 14 Feb 2014 09:45:44 -0800 (PST) Received: from zproxy120.enst.fr (zproxy120.enst.fr [137.194.52.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4365D1A02E1 for ; Fri, 14 Feb 2014 09:45:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zproxy120.enst.fr (Postfix) with ESMTP id 3326E10DBE2 for ; Fri, 14 Feb 2014 18:45:41 +0100 (CET) X-Virus-Scanned: amavisd-new at zproxy120.enst.fr Received: from zproxy120.enst.fr ([127.0.0.1]) by localhost (zproxy120.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbLQrv+BJvBx for ; Fri, 14 Feb 2014 18:45:40 +0100 (CET) Received: from [137.194.27.87] (dhcp27-087.enst.fr [137.194.27.87]) by zproxy120.enst.fr (Postfix) with ESMTPSA id A710110DBE0 for ; Fri, 14 Feb 2014 18:45:39 +0100 (CET) Message-ID: <52FE562C.9080103@telecom-paristech.fr> Date: Fri, 14 Feb 2014 18:45:16 +0100 From: =?UTF-8?B?RnJhbsOnb2lzIExvbmM=?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140214170030.8100.74818.idtracker@ietfa.amsl.com> In-Reply-To: <20140214170030.8100.74818.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140214170030.8100.74818.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050008020304000801030001" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rvmZV6f9AemZtuHA4Cw9IaxLw5s Subject: [TLS] Fwd: New Version Notification for draft-lonc-tls-certieee1609-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:45:47 -0000 This is a multi-part message in MIME format. --------------050008020304000801030001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I just published this draft about using other certificates (namely ETSI TS-103-097 and IEEE 1609.2) with TLS. As it defines a new TLS extension I think it would fit in this group, but I'm brand new here so I might be mistaken. The envisioned application is ITS (as in Intelligent Transportation System) in Europe (therefore the ETSI). I am aware that draft-ietf-tls-oob-pubkey proposes a similar TLS mechanism, but since the goals and applications seem very different, I thought it would still be worth submitting. Thanks in advance for your comments and suggestions. Regards, François Lonc P.S. Not sure of the etiquette here but Hey! I'm a cybersecurity grad student in Paris, France and very happy to read you. -------- Message original -------- Sujet: New Version Notification for draft-lonc-tls-certieee1609-00.txt Date : Fri, 14 Feb 2014 09:00:30 -0800 De : internet-drafts@ietf.org Pour : Brigitte Lonc , Houda Labiod , Ahmed Serhrouchni , F. Lonc , Houda Labiod , Brigitte Lonc , Mohammed Badra , Mohamad Badra , Ahmed Serhrouchni , Francois Lonc A new version of I-D, draft-lonc-tls-certieee1609-00.txt has been successfully submitted by Francois Lonc and posted to the IETF repository. Name: draft-lonc-tls-certieee1609 Revision: 00 Title: Transport Layer Security (TLS) Client authentication Using IEEE 1609-2 Certificate Document date: 2014-02-14 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-lonc-tls-certieee1609-00.txt Status: https://datatracker.ietf.org/doc/draft-lonc-tls-certieee1609/ Htmlized: http://tools.ietf.org/html/draft-lonc-tls-certieee1609-00 Abstract: This document describes two types of certificates to authenticate TLS entities, the first type enables the use of a certificate specified by the Institute of Electrical and Electronics Engineers (IEEE) and the second by the European Telecommunications Standards Institute (ETSI). This document defines a new extension to enable TLS entities authentication using one of the aforementioned certificate types. 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 --------------050008020304000801030001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,
I just published this draft about using other certificates (namely ETSI TS-103-097 and IEEE 1609.2) with TLS. As it defines a new TLS extension I think it would fit in this group, but I'm brand new here so I might be mistaken.

The envisioned application is ITS (as in Intelligent Transportation System) in Europe (therefore the ETSI).

I am aware that draft-ietf-tls-oob-pubkey proposes a similar TLS mechanism, but since the goals and applications seem very different, I thought it would still be worth submitting.

Thanks in advance for your comments and suggestions.

Regards,
François Lonc

P.S. Not sure of the etiquette here but Hey! I'm a cybersecurity grad student in Paris, France and very happy to read you.


-------- Message original --------
Sujet: New Version Notification for draft-lonc-tls-certieee1609-00.txt
Date : Fri, 14 Feb 2014 09:00:30 -0800
De : internet-drafts@ietf.org
Pour : Brigitte Lonc <brigitte.lonc@renault.com>, Houda Labiod <houda.labiod@telecom-paristech.fr>, Ahmed Serhrouchni <ahmed.serhrouchni@telecom-paristech.fr>, F. Lonc <francois.lonc@telecom-paristech.fr>, Houda Labiod <houda.labiod@telecom-paristech.fr>, Brigitte Lonc <brigitte.lonc@renault.com>, Mohammed Badra <badra@isima.fr>, Mohamad Badra <badra@isima.fr>, Ahmed Serhrouchni <ahmed.serhrouchni@telecom-paristech.fr>, Francois Lonc <francois.lonc@telecom-paristech.fr> 


A new version of I-D, draft-lonc-tls-certieee1609-00.txt
has been successfully submitted by Francois Lonc and posted to the
IETF repository.

Name:		draft-lonc-tls-certieee1609
Revision:	00
Title:		Transport Layer Security (TLS) Client authentication Using IEEE 1609-2 Certificate
Document date:	2014-02-14
Group:		Individual Submission
Pages:		5
URL:            http://www.ietf.org/internet-drafts/draft-lonc-tls-certieee1609-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lonc-tls-certieee1609/
Htmlized:       http://tools.ietf.org/html/draft-lonc-tls-certieee1609-00


Abstract:
   This document describes two types of certificates to authenticate TLS
   entities, the first type enables the use of a certificate specified
   by the Institute of Electrical and Electronics Engineers (IEEE)
   and the second by the European Telecommunications
   Standards Institute (ETSI).  This document defines a new
   extension to enable TLS entities authentication using one of the
   aforementioned certificate types.

                                                                                  


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


--------------050008020304000801030001-- From nobody Fri Feb 14 10:52:27 2014 Return-Path: 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 9B05A1A0368 for ; Fri, 14 Feb 2014 10:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] 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 LHdY7gjN5hPh for ; Fri, 14 Feb 2014 10:52:21 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5002E1A02EE for ; Fri, 14 Feb 2014 10:52:21 -0800 (PST) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 3C787F984; Fri, 14 Feb 2014 13:52:17 -0500 (EST) Message-ID: <52FE65E2.2020002@fifthhorseman.net> Date: Fri, 14 Feb 2014 13:52:18 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?RnJhbsOnb2lzIExvbmM=?= , tls@ietf.org References: <20140214170030.8100.74818.idtracker@ietfa.amsl.com> <52FE562C.9080103@telecom-paristech.fr> In-Reply-To: <52FE562C.9080103@telecom-paristech.fr> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fG4s4MttCvskN3uG5u7C2g9sUo0q1U5qP" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G_YNsCOb9QIXL_Cj8bo6sNjiV5A Subject: Re: [TLS] Fwd: New Version Notification for draft-lonc-tls-certieee1609-00.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:52:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fG4s4MttCvskN3uG5u7C2g9sUo0q1U5qP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Fran=C3=A7ois-- On 02/14/2014 12:45 PM, Fran=C3=A7ois Lonc wrote: > I just published this draft about using other certificates (namely ETSI= > TS-103-097 and IEEE 1609.2) with TLS. As it defines a new TLS extension= > I think it would fit in this group, but I'm brand new here so I might b= e > mistaken. >=20 > The envisioned application is ITS (as in Intelligent Transportation > System) in Europe (therefore the ETSI). >=20 > I am aware that draft-ietf-tls-oob-pubkey > proposes a= > similar TLS mechanism, but since the goals and applications seem very > different, I thought it would still be worth submitting. A clear explanation of how the goals and applications differ from existing work would be useful in understanding why a new draft is needed.= Also, this draft seems similar to RFC 6091, which already has a registry of certificate types. Have you considered adding another entry or two to that registry, rather than defining a new extension mechanism? Barring that, a few notes follow: The list of enumerated types for SupportedCertType and AcceptedCertType seems to be identical. is there any chance that they might differ? if not, why not collapse them into a single enum? your IANA considerations section seems to be missing any reference to the enumerated type list. is this a registry you'd expect IANA to maintain? if not, how would it be extended? The security considerations section seems too thin. what characteristics are relevant to these two different certificate formats? from a basic skim and search: the ETSI reference is 33 pages, and has security as one of its top-level keywords and several pages about security policy considerations. are none of these relevant to this draft? I couldn't find a freely-available copy of IEEE 1609.2, so i couldn't evaluate what kinds of security considerations might come into play for this. Are there trust anchors, pre-loaded lists, standard verification policies, TOFU approaches, or other regimes for validating these certificates? which approaches are the recommended ones? If the draft plans to punt on certificate validation, or to refer to some other document for "best practices" for certificate validation, it should probably do so explicitly. in what contexts would someone want to use one of these different certificate types instead of an X.509 certificate or an OpenPGP certificate or a raw public key? If there are multiple possible encodings, how are these new certificate formats packaged on the wire when they are included in the Server Certificate or Client Certificate message? the ETSI document suggests that ETSI keys can be either ecdsa_nistp256_with_sha256 or ecies_nistp256. how do those key types interact with the various key exchange mechanisms? For example, i would guess that an ecdsa_nistp256_with_sha256 key should only be used with a DHE ciphersuite, presumably ECDHE_ECDSA (https://tools.ietf.org/html/rfc4492#section-2.2) Will the signed_params object in the ServerKeyExchange algorithm use the same signature mechanism and structure as would have been produced by the same key packaged in an ECDSA X.509 certificate, or would it structure the signature as in ETSI's =C2=A74.2.10? Is there any interaction between the use of an ETSI cert and the ECC extensions listed in rfc 4492? What should happen in a TLS handshake where neither peer offers any of the extensions from 4492 but they want to negotiate this new extension? (i'm asking about ETSI here because the spec is available gratis, but i suspect similar questions are relevant to IEEE 1609.2) The extension_data explanation doesn't identify a top-level structure that explains how the data will be packed into the extension. in particular, it looks like the certificate_authorities object is dangling to me. how does the server indicate to the client which of the client's "supported" certificate types it is willing to accept? Can you clarify the difference between "supported" and "accepted"? I think "supported" means "i have a private key and a certificate that matches one of these certificate types" and "accepted" means "i am able to parse one of these certificate types from my peer", but it's probably better to be explicit about it. hth, --dkg --fG4s4MttCvskN3uG5u7C2g9sUo0q1U5qP 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 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS/mXiXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpci6wQAKDvH1S+83zcgm4GL0yIiVDA owBiexKUtDaQ39+jhMngU9IU599QdU/lQYUKFxUfmk/U0XMdnABrFudVrheJ2dSB EjDBsHwLBrFIygavQDYie10Kg3HA02UxcgvDMhcm0m2iL4CJJ4tQds+3Jf5mK+s/ QMJp3AqFVdp7ZhXKFLvPvBom4P3rW+njVG6VQOJ3mH9HdfosQ37RqX/v/vNpMq2f b9Scss7uWLe7zdQYWHvIP/QijQrYS1xUAqnQM5K5fGdHpRzVTLqYcN5qTS/u/0kW +lVZ//lhvAnAMFFk4ifrcLVTWz5utTtPyHBerOz27WTnzUXoKKwXys9/bMqoHVax mEtbG8L5pPn+GrtDL7SjDPZG8cQ5L4RrImYRA3bwFZhjbZ5WXpxgwBPo/xyVht0B o56NuwbgYaxgwrUbnloMcNZHCRK9bI++ouvrZLXElFboGPjXqnn/hBVuDOjn2AxH KBynfGl0yU9jrzFh0+gxddcz7FmWULdwEMihik1BgE0iS9l2OXVMgvpBdMxsc15o 8Ys8I3KnlBJBA2nbhruFWO+Cay6UKq621nurfxoH71DDTWdWUfQtC3NMekfU6tlF FUNHobri2ZZxDozviQmkjEFWHHVxcRHxvXxqC5OvsCLKcBeIgP828UeP5qIo6jAe KVnO5U45VkXJRl9l0OlK =fcQ3 -----END PGP SIGNATURE----- --fG4s4MttCvskN3uG5u7C2g9sUo0q1U5qP-- From nobody Fri Feb 14 10:57:53 2014 Return-Path: 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 95DEC1A02D0 for ; Fri, 14 Feb 2014 10:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] 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 4q0wFgSjqUWG for ; Fri, 14 Feb 2014 10:57:46 -0800 (PST) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id D38041A02E4 for ; Fri, 14 Feb 2014 10:57:45 -0800 (PST) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s1EIvU28008018; Fri, 14 Feb 2014 19:57:30 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s1EIvSSN008010; Fri, 14 Feb 2014 19:57:28 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Fri, 14 Feb 2014 19:57:28 +0100 In-Reply-To: (Adam Langley's message of "Fri, 14 Feb 2014 12:45:21 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G_zPKZEq8Dw0fIphaIZlUcPtGKg Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:57:48 -0000 Adam Langley writes: > It appears that IPSec wants the extra 32 bits of nonce. Although this > is an important change in definition it doesn't actually change the > wire-format for TLS because the record-length limit means that those > bits are always zero anyway in both cases. Right, with some care both views these input words could perhaps coexist. And a 32-bit counter (256 GB message size, if I manage to get the powers right) ought to be sufficient for almost all applications. But I'm afraid it might to slow adoption of chacha if there are multiple slightly incompatible specifications. And my current focus is more on what the chacha programming interface should look like, not wire format of any particular protocol. > Keep in mind that it affects more than just your users. By making > streaming designs easy you allow people to make bad designs (like CMS) > that force streaming designs on others in order to handle large files. > The point of AEADs is that it's an easier primitive to use. By streaming, I don't advocate you do the decryption in a pipe line; that's clearly a dangerous habit. Usecase is more like on one machine running src-machine$ tar -cf - foo-dir | aead-encrypt | send to send the encrypted data over some untrusted link. And on the receiving side target-machine$ recv | aead-decrypt -o foo.tar The point of the "streaming" here is that there's no need to store any copy of plaintext or cryptotext at the source, and at the receiver, at least there's no need to store a copy of the ciphertext. (And with some more care, and a paranoid enough tar program, it's even possibly to safely extract the received tar file in a pipe, avoiding storing a copy of the tar file, *if* one arranges to handle the aead-decrypt exit code properly). If I want to encrypt a large file (say, with key derived from a passphrase, or with an random and RSA-encrypted session key), I see no clearly better or easier way to do that than as a single large AEAD message processed using a streaming/incremental API. Sure, I could divide the data into reasonably sized shorter blocks and process each block as a separate message with AEAD, but then I would have to think about how to do sequence numbers and a properly authenticated EOF indication, to prevent reorder and truncation. And to me, that's also very much against the spirit of AEAD as a safe and easy-to-use mechanism. > However, my preference would be to leave it as is because I've already > got code that does it that way I'm afraid that's the answer that I expected... > and I don't believe that streaming is something that should be made > easy. We'll probably just have to disagree on that. >> I see. Vaguely related question: Do you see any need for 128-bit chacha >> keys? > > Since they are no faster I don't believe that anyone will want to > support them. However, I may be wrong about that. Thanks. (I currently do support them in my development version, but I'm considering removing that feature, for simplicity, before release). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Fri Feb 14 11:51:30 2014 Return-Path: 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 AB7E91A02B9 for ; Fri, 14 Feb 2014 11:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 crMZkTvyVu6L for ; Fri, 14 Feb 2014 11:51:24 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD491A0394 for ; Fri, 14 Feb 2014 11:50:00 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ld13so9462362vcb.4 for ; Fri, 14 Feb 2014 11:49:58 -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:content-transfer-encoding; bh=ErLvlr370rWOGqp0bJfVThnI3GChRQg2nD8LggM27lg=; b=GWeIHw42tvhKgnxkoup61v6EtvWvWkBKl2wZiAj+wLgXiaR0e8jgYqU/6GVKAPHsEu +4KNYyZS+icqqmD7CASk4OpE6wUeq5doSUJquCWdW9PvxIPbaBYO1XWF/5tE6VAgjQDa YTgemCCyCisf6DGhBy0Uv4JpWi6MAKcQP2noEDaqpj5s9iE44J0je6eHpiUcksXpdEwZ mnUGSDR+RNfaQqGL7ajC6ZQfYQ+EWVqFtPOQo15qdY7m4WZAO0XQadQgeCdeDliJW39S cw1ptvpwfLm40yFJ8jw4tj6eigqZ5aJydDppEBe/nfOJ3oOpvbTiqq3aFAmfi/bQWTkO kASA== 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=ErLvlr370rWOGqp0bJfVThnI3GChRQg2nD8LggM27lg=; b=I3Vt+UnE/fDdsLNrz1L1hu3VZ5HelPWTC14dUyKtaSbIg5Q8mnnS57TXu8OFvqGb5P Gi9FvHTRylmIBwBcZSZU9mKNT/LgotCVQty6vb4cggxYpkRdIqFUhpYN3+VwqdQ/fq+/ RAHt1fI3rMpj/F5i4bhW3yh9BE7KxbOrZwcAxj5yYh5rzK0vsiRakPj+m8ipIn6CCXvD U9xb35fpx0Lfq8jNCt0Dl4E3z8dVj67ahvi8dHbr/jI5U0esmzduyppU+NpsGR+PJs6H HFtA4yuSt5F4LPPOIDYM6yAtQ5yYop74jiidIl3vjhJONkWbW1ciJ/PwL/+heV+OCsJ2 Gffg== X-Gm-Message-State: ALoCoQnqjZvvebOq44lQAbINJdPUDU6bhDsme2Lx8VVQFs3YULib0vaCGkCt0u0sSZfqb4zXMysgCQhCeaHXcV+ehR4TmfZBk3RQc16P/N/uaAntEKo3GVnpKBHVQLCActrEVsGGS/bP8T0Bw8+yTyWRNTvLbqIndjPwKrJsGZWfYNn5PsmoX+O8J+hj2MYOtfN6O4er+Mhq X-Received: by 10.52.186.230 with SMTP id fn6mr5613927vdc.14.1392407398642; Fri, 14 Feb 2014 11:49:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Fri, 14 Feb 2014 11:49:38 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 14 Feb 2014 14:49:38 -0500 Message-ID: To: =?UTF-8?Q?Niels_M=C3=B6ller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ULJbYdCDaycBGBUI_hye3SSo2ok Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:51:27 -0000 On Fri, Feb 14, 2014 at 1:57 PM, Niels M=C3=B6ller w= rote: > Right, with some care both views these input words could perhaps > coexist. And a 32-bit counter (256 GB message size, if I manage to get > the powers right) ought to be sufficient for almost all applications. > But I'm afraid it might to slow adoption of chacha if there are multiple > slightly incompatible specifications. I intend for the 64/64 bit version to be dead at this point. I think everyone can agree on the 96/32 split. I wouldn't want there to be two versions if it can be avoided. > By streaming, I don't advocate you do the decryption in a pipe line; > that's clearly a dangerous habit. Usecase is more like on one machine > running > > src-machine$ tar -cf - foo-dir | aead-encrypt | send This use of streaming is fine by my criteria, assuming that "aead-encrypt" is chunking the input into different blocks and applying the AEAD to each block. This is perfectly fine with a one-shot(*), AEAD API at the core. > If I want to encrypt a large file (say, with key derived from a > passphrase, or with an random and RSA-encrypted session key), I see no > clearly better or easier way to do that than as a single large AEAD > message processed using a streaming/incremental API. Sure, I could > divide the data into reasonably sized shorter blocks and process each > block as a separate message with AEAD, but then I would have to think > about how to do sequence numbers and a properly authenticated EOF > indication, to prevent reorder and truncation. And to me, that's also > very much against the spirit of AEAD as a safe and easy-to-use > mechanism. I disagree here and this seems to contradict your statement above that decryption in a pipeline is a "dangerous habit". Wouldn't your streaming/incremental API return unauthenticated plaintext to the caller and thus encourage just this habit? Certainly I have much sympathy with the problem of giving the user a simple API for dealing with large files. However, I think such an API should, under the covers, chunk the data and apply an AEAD to each chunk. That design can avoid holding large amounts of plaintext or ciphertext in memory and also avoid returning unauthenticated plaintext. There is still the need to handle unexpected truncation, but I think that's fundamental when one cannot hold the whole file in memory at once. So I think that what you want is an "AEAD chunking format" which is a higher level concept than an AEAD and that our disagreement arises from merging what I see as two different layers. (*) by one-shot I mean that it does the whole operation in one call. I.e.: ssize_t EVP_AEAD_CTX_seal(const EVP_AEAD_CTX *ctx, unsigned char *out, size_t max_out_len, const unsigned char *nonce, size_t nonce_len, const unsigned char *in, size_t in_len, const unsigned char *ad, size_t ad_len); Cheers AGL From nobody Fri Feb 14 12:50:17 2014 Return-Path: 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 8FC3B1A03E0 for ; Fri, 14 Feb 2014 12:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] 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 szTqf_0uG2kR for ; Fri, 14 Feb 2014 12:50:00 -0800 (PST) Received: from bacon.lysator.liu.se (bacon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::ce]) by ietfa.amsl.com (Postfix) with ESMTP id EC0571A03E1 for ; Fri, 14 Feb 2014 12:49:38 -0800 (PST) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s1EKnOpA010608; Fri, 14 Feb 2014 21:49:24 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s1EKnLh8010607; Fri, 14 Feb 2014 21:49:21 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Adam Langley References: Date: Fri, 14 Feb 2014 21:49:21 +0100 In-Reply-To: (Adam Langley's message of "Fri, 14 Feb 2014 14:49:38 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4wpEOLqgBa6kqPqPtg36h-xxpFU Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:50:09 -0000 Adam Langley writes: > I disagree here and this seems to contradict your statement above that > decryption in a pipeline is a "dangerous habit". Wouldn't your > streaming/incremental API return unauthenticated plaintext to the > caller and thus encourage just this habit? The proper way is to process the file incrementally (with bounded RAM), write the result to a temporary file on disk (preferably hidden, if supported by the OS). At the end of data, check authentication, and either rename the file and advertise it, or delete it and return a failure exit code. And I think this is the right way to do it no matter of you use plain AEAD or some "AEAD chunking format" (more on truncation below). > So I think that what you want is an "AEAD chunking format" which is a > higher level concept than an AEAD and that our disagreement arises > from merging what I see as two different layers. Under the assumption that processing of a truncated version or "prefix" of the authenticated file is somehow safe, an AEAD chunking format has an advantage over plain AEAD, in that it can provide prefixes of the authenticated file early. But in the case that you really want proper authentication of the *complete* file before you start processing it, I think an AEAD chunking format is additional complexity with no benefit over plain AEAD, since plain AEAD provides exactly the type of autentication needed. I'd prefer not assume that prefixes are safe. I don't have any very concrete example, but I think that in general handling a truncated file should be considered dangerous. As one example, I think pdf files have some kind of master index at the end, and also some possibility to edit earlier contents by appending data and a new index at the end (intended for adding notes on top of a signed pdf, iirc). > (*) by one-shot I mean that it does the whole operation in one call. I.e.: > > ssize_t EVP_AEAD_CTX_seal(const EVP_AEAD_CTX *ctx, > unsigned char *out, size_t max_out_len, > const unsigned char *nonce, size_t nonce_len, > const unsigned char *in, size_t in_len, > const unsigned char *ad, size_t ad_len); I intend to provide an interface like that in the Nettle library; the streaming/incremental interface will not be the only one. And I expect that the one-shot functions will be the right choice for most applications. But since the one-shot functions will be implemented on top of the lower-level incremental interface I described earlier, any additional complexity there is relevant also for applications exlusively using the one-shot interface. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Fri Feb 14 14:05:43 2014 Return-Path: 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 1C73D1A015A for ; Fri, 14 Feb 2014 14:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, 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 pKMj3X4N5Gpt for ; Fri, 14 Feb 2014 14:05:34 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 87B061A0039 for ; Fri, 14 Feb 2014 14:05:32 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id ie18so9542132vcb.26 for ; Fri, 14 Feb 2014 14:05:30 -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:content-transfer-encoding; bh=EVxQOGx7f8t/XWmy26qroOW6DlS6c5JAhY/uZEtUpWw=; b=UxkGBnrcYKXzdieW+PRIhTtKU1zL7w11gL4rr6/muHUNVSJy+MnCul0XxAT6NSdsd8 mTW5BtUtoIhvciPALAQeeq2XWSMKaSSnB1e8YDZ/IZF1pqdfYDfC7U/oL0pH8vo/ZKye zsXoSNkDNI/+eVnnGTM3nXA5TB97AFjXg6/dwZPH8LfMSlVtVBEhO9VERJQUdgKdC/AX oR/4Dv0R08bEAPJd2pRg8dFFsrD9A9GxH0eP3xIg0h5fOULR6yolix/E/8qQtYhvKERH AGnHtb9eat/SyHBrApfz2EFKzjxBd4+auA6/0heTm+ja+mGdJd9suWZK49ILBo3LXePc NLXA== 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=EVxQOGx7f8t/XWmy26qroOW6DlS6c5JAhY/uZEtUpWw=; b=NAyUzB6R7MFtrQnsyJuAZVxmCGFWPqTx+frpWc+RW7iddjdahbJza5TN8qCQgFzHv2 DsI6gyQ6iYMa3Bez5pnEnbbm+ONxyi37pUaByzDhMAND9zunMh2zNmiT61PNCtVY3+Cy algdq/rkNt3uyh524WHuRuPD5jLuT6aCakQo0cDr0uJM1RzgqnRjD14s1SUah/USVwq8 Jc36fMCIqBwGb3tI38hF+9nUhMaxHFBESiZEUBYDOkd/UYpS2bNRUM6CbTeMRBgXXoT5 aP/XxMAS5tPLpVuXICQcGW8ybGIxwayaU+sNgIchd9u3aHFQ3A93fd8SwAkNVUM4R29O CD3w== X-Gm-Message-State: ALoCoQm/jOhHBOkjFx/X5YP6L2YhMgzRkmFd+AbGg9YqMrtZ1BXiC85/mm7XID7OoxV+XvmwA4Yb6SS7h9JOhvBwV6KaSeZUMf/YfIuZ3gyEpPG1q88sdummiixDDOHeohPEuOVjFwkoOTy79OM/+g1a3sBmYAmg6LS5neXyHhBBVGX6lZJbqjOtwSMEpG6IU/J2sO4aA2fN X-Received: by 10.52.171.39 with SMTP id ar7mr5828496vdc.5.1392415530775; Fri, 14 Feb 2014 14:05:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Fri, 14 Feb 2014 14:05:10 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 14 Feb 2014 17:05:10 -0500 Message-ID: To: =?UTF-8?Q?Niels_M=C3=B6ller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UpH61JwS6dWS5dmhhPtzm-jSU9c Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:05:36 -0000 On Fri, Feb 14, 2014 at 3:49 PM, Niels M=C3=B6ller w= rote: > The proper way is to process the file incrementally (with bounded RAM), > write the result to a temporary file on disk (preferably hidden, if > supported by the OS). At the end of data, check authentication, and > either rename the file and advertise it, or delete it and return a > failure exit code. I think that's a fine API to expose if you can limit it to operations like that. However, I fear requirements creep will will set in as data needs to be further processed and one ends up evincing a "streaming" API that has the unauthenticated plaintext problems that I worry about. For example, in my favourite, recreational language of the moment (Go), the convention for layering transforms like decryption is to do it in a streaming fashion via a minimal interface that provides a read() like, virtual function. Using a temp file in a library would be considered poor form, although it does solve the truncation problem. I admit that I'm hypothesising with little evidence which implies that the argument can be dismissed with little effort. Although, if you were to implement just an API like that then you could require that update be called exactly once, since it wouldn't be public API anyway, and that would solve your AD length problems. > But in the case that you really want proper authentication of the > *complete* file before you start processing it, I think an AEAD chunking > format is additional complexity with no benefit over plain AEAD, since > plain AEAD provides exactly the type of autentication needed. I think the benefit is that one doesn't have to worry about possibly exposing an unsafe, streaming API. Everything can be composed from a one-shot, AEAD function and we don't have to worry about littering header files with more comments describing the superficially correct, but unsafe, ways that the functions shouldn't be used. But just because it's not my personal preferences doesn't mean that it's unreasonable. Cheers AGL From nobody Fri Feb 14 15:29:24 2014 Return-Path: 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 3E0931A04E6 for ; Fri, 14 Feb 2014 15:29:21 -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 5HVFfn4coKEY for ; Fri, 14 Feb 2014 15:29:18 -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 9F1461A04D8 for ; Fri, 14 Feb 2014 15:29:18 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id jw12so2982752veb.18 for ; Fri, 14 Feb 2014 15:29: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:from:date:message-id:subject:to :content-type; bh=2SyDK4oIokYKUU1Gn4CQaPvbiyHqRHjWHqc5GYnzO2s=; b=PoPy29kbBbwPV6ERVEKA9E5mKd2oR0HbPrkOxW6u7/VvBetXTpv2FkFlzE/opPicr6 ZK/o28UWOLsjtHsAH9kpJZfSRf8HxaGMsYqq2qRcck5Nzwp18Hqq9c9Zfxq/1JI1TBuN mRyXUUrN6KiyK3mZlzDndfjucpYOSAoW6Y1sk7iWRVvNobrhey3LEfSKZu4sgGC6j8YB +XiJ3HCKrWY0kPT3T608vW/N9DUNWAqqsNflA3FW/5u9NP0jEWigvsVSC8z1Sb+YGygh o385kWkCbupNnwyZpgoAf6xcrDO9cgArhHID8eucbZEOWANWwc8/k0oU6LUlGg/pLeIp eNkg== X-Gm-Message-State: ALoCoQkmM/cGOf6oZ8siPFzYzNiYyWVXUvpKWnsEo4l1gpqySVroTUxWFFXeo6YOxOYYlSl1RgoQ X-Received: by 10.221.30.14 with SMTP id sa14mr241667vcb.44.1392420556643; Fri, 14 Feb 2014 15:29:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.198.12 with HTTP; Fri, 14 Feb 2014 15:28:36 -0800 (PST) X-Originating-IP: [50.193.20.145] From: Eric Rescorla Date: Fri, 14 Feb 2014 15:28:36 -0800 Message-ID: To: "rtcweb@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11336a2ea8356b04f2662cdd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/le7B1Qb9Ae71BZqV_WZUYbLOWsY Subject: [TLS] Short Authentication String for TLS/DTLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:29:21 -0000 --001a11336a2ea8356b04f2662cdd Content-Type: text/plain; charset=ISO-8859-1 RTCWEB WG members may be interested in the following draft: http://tools.ietf.org/html/draft-miers-tls-sas-00 This draft specifies a Short Authentication String feature for TLS and DTLS which would allow a pair of communicating to compare SAS values computed from the TLS/DTLS handshake in order to detect active attack. -Ekr --001a11336a2ea8356b04f2662cdd Content-Type: text/html; charset=ISO-8859-1
RTCWEB WG members may be interested in the following draft:


This draft specifies a Short Authentication String feature for
TLS and DTLS which would allow a pair of communicating
to compare SAS values computed from the TLS/DTLS
handshake in order to detect active attack.

-Ekr

--001a11336a2ea8356b04f2662cdd-- From nobody Fri Feb 14 15:41:45 2014 Return-Path: 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 EE5ED1A038B for ; Fri, 14 Feb 2014 15:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 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.548, 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 koBJqnEBPRM2 for ; Fri, 14 Feb 2014 15:41:42 -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 E4BBE1A033B for ; Fri, 14 Feb 2014 15:41:41 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id oy12so10163663veb.37 for ; Fri, 14 Feb 2014 15:41:40 -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=gOLFnVrIz8W0qESzES9vHyqTT3yIcLTnwzobVe4FGzc=; b=CWzE/rI3PfzjQfJLdhkqLoxPu64RU7z5pZUgydIoQsTdqSapjyV3poJiptQXCK7SR5 ZSq9EXS8WDAoWKRQbQnHY8hh0eRSrB5LYaOsMmAURcKQUJDNf/NbDSLPUWvcUAHPakKm i3SySco+OxgfgG+t/LBh8T/5GM0pADSNBoAdYilcTSd9FrX4/RYzzTYIGmidWJZKDBfk ZeN3rBQ5r2oJRX0iixSnCsfAVbAFc/YPD3JnKVkcXxS6M7ptrs6zXRB32y+IJd1MXW9e 2/dtio8VWklLIEbSVxaxj3A/vkoLnbWhw+PMwRHQF4WNdWCHgxE1s1n04iRGm22ZFRp2 T68Q== 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=gOLFnVrIz8W0qESzES9vHyqTT3yIcLTnwzobVe4FGzc=; b=OVUgS7w96eBud8vIEQiXfb4XH8nwjBTPn6gaTRHjpUPEDtynTmWu1+AfNEmhK87R+F NXD6dH+qmadFbaFot7U6ynElp1rQ5yeCc8rhm0UzLRZFQjtQH0WJwdG0yaShQiP+dwFZ Yia4d31OcomDclPE/PVXS4AQgiGtv/e0EPSysnvmFQm+V++Yydh1SyN1NM3eQLpk8dez hk8VLnPR2Y5Q4RDlk07Y2ny98pbIwZ1tTV2AIp8MxWYHQCOZmPZJMzNf+5HqE6gUfiWE 7+IKm9oCNn512YQEd5S0jrglKYih1GQZrEZwzvEsA/2sT6HIfCmsa6iVTbmOieAcDUZT BdPQ== X-Gm-Message-State: ALoCoQmS1G4YTMR0YrN8Q7Aocz6xpMvwZcnAbarN2zX69wRRGDByJXi5/3Pro3xROGwUenMRMnhYBiSkGcOGljyBQ1IR3jnQBn9N1A9d7+dg7uVBylywbegOZIIOuoGHry42BMZ2LBMNOh1v0NcRY/rvf9bjsv3c8S2ra8N9Ai9UxccqftfsrD0dw9c5uTxIvDzzkZ/C7yJj X-Received: by 10.221.37.1 with SMTP id tc1mr3092138vcb.32.1392421300022; Fri, 14 Feb 2014 15:41:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Fri, 14 Feb 2014 15:41:18 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Fri, 14 Feb 2014 18:41:18 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cb7vQnzTMKtt5b1l3qdyawQShrs Cc: "rtcweb@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] Short Authentication String for TLS/DTLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 23:41:44 -0000 On Fri, Feb 14, 2014 at 6:28 PM, Eric Rescorla wrote: > RTCWEB WG members may be interested in the following draft: > > http://tools.ietf.org/html/draft-miers-tls-sas-00 > > This draft specifies a Short Authentication String feature for > TLS and DTLS which would allow a pair of communicating > to compare SAS values computed from the TLS/DTLS > handshake in order to detect active attack. I think the draft should discuss why a channel binding doesn't work. It's hinted at in the introduction but it's a subtle point because they are otherwise very similar. Given that I see M. Green as an author, should I assume that the requirement for 64 bytes of randomness for a /short/ authentication string is to ensure that users of Dual_EC DRBG have no problems leaking the necessary entropy to a passive observer? :) Cheers AGL From nobody Sun Feb 16 08:04:44 2014 Return-Path: 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 BCC371A03EE for ; Sun, 16 Feb 2014 08:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 YkM21FigPjpm for ; Sun, 16 Feb 2014 08:04:41 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C086E1A0256 for ; Sun, 16 Feb 2014 08:04:40 -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 s1GG4bgx020983 for ; Sun, 16 Feb 2014 18:04:37 +0200 X-CheckPoint: {5300DA07-A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.228]) by DAG-EX10.ad.checkpoint.com ([169.254.3.110]) with mapi id 14.03.0123.003; Sun, 16 Feb 2014 18:04:38 +0200 From: Yoav Nir To: "tls@ietf.org list" Thread-Topic: [TLS] Short Authentication String for TLS/DTLS Draft Thread-Index: AQHPKdyhdYwVIvejE0O5XjEq2cW4tZq1R0MAgAKlEAA= Date: Sun, 16 Feb 2014 16:04:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.121] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7kmKZ_HsRBasAHVyRl42rYvwcnc Subject: Re: [TLS] Short Authentication String for TLS/DTLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:04:43 -0000 On Feb 15, 2014, at 1:41 AM, Adam Langley wrote: > On Fri, Feb 14, 2014 at 6:28 PM, Eric Rescorla wrote: >> RTCWEB WG members may be interested in the following draft: >>=20 >> http://tools.ietf.org/html/draft-miers-tls-sas-00 >>=20 >> This draft specifies a Short Authentication String feature for >> TLS and DTLS which would allow a pair of communicating >> to compare SAS values computed from the TLS/DTLS >> handshake in order to detect active attack. >=20 > I think the draft should discuss why a channel binding doesn't work. > It's hinted at in the introduction but it's a subtle point because > they are otherwise very similar. Adam reads deeper between the lines that I do, but yes, this seems like a t= hird way of generating a session-specific shared key, after channel binding= s and TLS extractors. So stating why neither will do seems like a good idea= . I see that the key generated in this solution is not tied to the session ke= ying material, and is not secret. Secrecy may not be needed here, but is th= e lack of secrecy a requirement? Yoav = From nobody Mon Feb 17 00:10:12 2014 Return-Path: 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 18DEB1A0041 for ; Mon, 17 Feb 2014 00:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 rlyDus6zpTWF for ; Mon, 17 Feb 2014 00:10:09 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 19E5A1A008D for ; Mon, 17 Feb 2014 00:10:08 -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 s1H89q2r029590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Feb 2014 03:09:52 -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 s1H89mPn009990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 17 Feb 2014 03:09:49 -0500 Message-ID: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Adam Langley Date: Mon, 17 Feb 2014 09:09:48 +0100 In-Reply-To: References: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4dVnEva2oyUKfF7dnJQU2-6xFzs Cc: Niels =?ISO-8859-1?Q?M=F6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 08:10:11 -0000 On Fri, 2014-02-14 at 14:49 -0500, Adam Langley wrote: > > By streaming, I don't advocate you do the decryption in a pipe line; > > that's clearly a dangerous habit. Usecase is more like on one machine > > running > > src-machine$ tar -cf - foo-dir | aead-encrypt | send > This use of streaming is fine by my criteria, assuming that > "aead-encrypt" is chunking the input into different blocks and > applying the AEAD to each block. This is perfectly fine with a > one-shot(*), AEAD API at the core. I'd pretty much agree with the chunked approach, but I now realize that it is more hard to get it right than the streaming one. In the chunked approach one would need to implement sequence numbers (could be implicit as additional data) and a termination block. So both approaches have quite some disadvantages. The streaming approach allows for misuse of the API which may cancel the benefits of AEAD, and the chunked approach requires the developer to create a safe protocol over AEAD. If the idea is for AEAD to be used by an average developer, it seems we need even a higher abstraction than that; even for such a simple use-cases. regards, Nikos From nobody Mon Feb 17 07:45:56 2014 Return-Path: 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 E1D8A1A03F6 for ; Mon, 17 Feb 2014 07:45:54 -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 73-M373SP7Ma for ; Mon, 17 Feb 2014 07:45:52 -0800 (PST) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id AE6F01A04DE for ; Mon, 17 Feb 2014 07:45:51 -0800 (PST) Received: by mail-yh0-f54.google.com with SMTP id z6so14184953yhz.13 for ; Mon, 17 Feb 2014 07:45:49 -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=e6X925jWEtn+abSSc0H2BhDNd/i4G3h2xEDjXJXtaSw=; b=lMmVR/b6TJW3K0WiKuMqRKxpED+tiMFH7OsFnOu/V5/Xdcf8Gk3DeFXy6RUdRNTke1 dP1OoxocPkN81ftLYSd1rRYZDLfuM5dgs65RBVkcOUdHqoATBpJ38ulUHZodekAkHdSG 8GiEHfdvZzL0SNPMyw6q0KfHAM7aQbsJqDVHBNv7lg6KCpnq8nehC0odRDlUy+NMF3VE ishu/v2GWVJqy1yz8qdsF3tcQOd1tRctFfn0Yv44D21fUIughgAEmU3icfmLpuPQeaV/ wYSggBI9UFHyKsV0djpQQ0SqxtegsCQzU/iB8gaciDHDLnEN/xGBK9oGh3Qv+DpvHdKL gCqQ== MIME-Version: 1.0 X-Received: by 10.236.130.138 with SMTP id k10mr23513945yhi.31.1392651949063; Mon, 17 Feb 2014 07:45:49 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 17 Feb 2014 07:45:48 -0800 (PST) In-Reply-To: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> References: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 17 Feb 2014 07:45:48 -0800 Message-ID: From: Watson Ladd To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K4NdjOQWkZg8e6jQ-tpoCWEpIVs Cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:45:55 -0000 On Mon, Feb 17, 2014 at 12:09 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-02-14 at 14:49 -0500, Adam Langley wrote: > >> > By streaming, I don't advocate you do the decryption in a pipe line; >> > that's clearly a dangerous habit. Usecase is more like on one machine >> > running >> > src-machine$ tar -cf - foo-dir | aead-encrypt | send >> This use of streaming is fine by my criteria, assuming that >> "aead-encrypt" is chunking the input into different blocks and >> applying the AEAD to each block. This is perfectly fine with a >> one-shot(*), AEAD API at the core. > > I'd pretty much agree with the chunked approach, but I now realize that > it is more hard to get it right than the streaming one. In the chunked > approach one would need to implement sequence numbers (could be implicit > as additional data) and a termination block. So both approaches have > quite some disadvantages. The streaming approach allows for misuse of > the API which may cancel the benefits of AEAD, and the chunked approach > requires the developer to create a safe protocol over AEAD. > > If the idea is for AEAD to be used by an average developer, it seems we > need even a higher abstraction than that; even for such a simple > use-cases. Let's back up a bit. The assumption is that we are sending a file over the network, and we want to encrypt and authenticate it. If we have an encrypted and authenticated channel all is good. Alternatively, we can encrypt the entire file as one big chunk and decrypt on receipt. I've still not found a case where one of these doesn't work. Sincerely, Watson Ladd > > 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 nobody Mon Feb 17 17:59:14 2014 Return-Path: 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 04AF01A043D for ; Mon, 17 Feb 2014 17:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 xjOSDXTaW3qh for ; Mon, 17 Feb 2014 17:59:09 -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 EAA051A0291 for ; Mon, 17 Feb 2014 17:59:08 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id w7so11643473lbi.41 for ; Mon, 17 Feb 2014 17:59:05 -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=t1qexm+0QC/BYCuhBDJxC3Pw++2OERoFigLkYhjeu2U=; b=pC94pPzM+oU/FE7efnLqrrFsgZDoqdX+S5UGCWZ9+0vX2Ip5yAqtZw2JVSipinyZOS eIy/lf8OHGHuwGst2z3M0NFN1l0WyqK4jY2VbKxzkO3DshNA5vi9M5XMwMyXc++JHf9B kiqgLDLIrhegX6u2Xp4g82BQEfLEb63Y67nr323KSScc6G8zjaMIdRvAtySPB91cG2jl KPYvcLTysCeYWhW1Mvw1aKYze49IlBcbSaZkwSgSWOpy7T5kzgv0rnBWM/I35Zi73NP9 UcAXrF/1ZDcZq83lxr3MWkmWwXgcQND95bO9XqFKJw+uXcHjhItmPNl3kkB9vIqEsa3c qK+Q== MIME-Version: 1.0 X-Received: by 10.112.138.233 with SMTP id qt9mr18885584lbb.34.1392688745537; Mon, 17 Feb 2014 17:59:05 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.33.199 with HTTP; Mon, 17 Feb 2014 17:59:05 -0800 (PST) In-Reply-To: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> References: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 17 Feb 2014 20:59:05 -0500 X-Google-Sender-Auth: REE6mXRhqP6HrkvHPzlU39NzxQI Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W3PTleLmZ_f-N99kZo6ud7JPrkM Cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 01:59:11 -0000 On Mon, Feb 17, 2014 at 3:09 AM, Nikos Mavrogiannopoulos wrote: > If the idea is for AEAD to be used by an average developer, it seems we > need even a higher abstraction than that; even for such a simple > use-cases. I certainly agree with this. In some sense we already have this in the shape of the TLS record protocol itself, but it doesn't lend itself to being reused in a non-transport setting very well. Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From nobody Mon Feb 17 18:05:51 2014 Return-Path: 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 37EF01A0431 for ; Mon, 17 Feb 2014 18:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 kIIKvvQkgvmQ for ; Mon, 17 Feb 2014 18:05:48 -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 8B7C81A02E4 for ; Mon, 17 Feb 2014 18:05:48 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id e16so11582294lan.26 for ; Mon, 17 Feb 2014 18:05:45 -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=xxWunYlq9B+Ns7u7lY5fjwE/2RyHuf0Zj4E7q8YbyVc=; b=tuBObRO0zZg+e28+dX29RANDxhRogARFhP9tzZZJUAi5eCTZKuWxvv9j8ko24XHvaN NCPa9FFp4H+FMh9N5fMsJ7e5xAbXRdJV9Fo6RJx+qFvfcpGBuOleVSi0W6eNX4p2ZtZI OqvuWnb/6dZTGdM0p23zKNvZApU2Mo6ScAeVMF6wFFSSYvXk0WGKc0XC4jm8sHtkR+gm RSgdk6X327vc7B9kwbaIvMj0uMn9HDzfKDcPTmvCo9ELwmI8LGjOkmKpGYqHdmVCYZA7 tr70YbB3FlDgw1Zel01q9c4C14hf2JhPyRCOvrpF+nHjxALA6ICe4kVx0iIFJR+vn97c Jwnw== MIME-Version: 1.0 X-Received: by 10.153.3.2 with SMTP id bs2mr19563652lad.5.1392689145040; Mon, 17 Feb 2014 18:05:45 -0800 (PST) Sender: alangley@gmail.com Received: by 10.112.33.199 with HTTP; Mon, 17 Feb 2014 18:05:44 -0800 (PST) In-Reply-To: References: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 17 Feb 2014 21:05:44 -0500 X-Google-Sender-Auth: SOnr1KCdFtPjNpvbBCHWUknqowY Message-ID: From: Adam Langley To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DdPqBHtMjMC-ukKXg_S4UDG3t_w Cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 02:05:50 -0000 On Mon, Feb 17, 2014 at 10:45 AM, Watson Ladd wrote: > Alternatively, we can > encrypt the entire file as one big chunk and decrypt on receipt. I've > still not found a case where one of these doesn't work. I don't believe that there's any disagreement about the fact that operating on the file as one, large chunk works, technically. The problem is that I believe that it results in dangerous APIs. For example, OpenPGP does this and I was very unhappy about it when writing this[1] implementation which returns unverified plaintext. I called the Reader "UnverifiedBody" and put a big comment in there but I think we should be able to do better. The point of AEADs was to provide a safer abstraction in the first place, no? (Niels suggested buffering everything before returning anything and that's certainly safe. But I feel that it's somewhat anti-social for a library to do so.) [1] https://code.google.com/p/go/source/browse/openpgp/read.go?repo=crypto#38 Cheers AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From nobody Mon Feb 17 21:00:34 2014 Return-Path: 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 3B37E1A05B1 for ; Mon, 17 Feb 2014 21:00:32 -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 ODg9dbiVKnaW for ; Mon, 17 Feb 2014 21:00:30 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9551A055A for ; Mon, 17 Feb 2014 21:00:30 -0800 (PST) Received: by mail-yk0-f173.google.com with SMTP id 10so32195340ykt.4 for ; Mon, 17 Feb 2014 21:00:27 -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=gIv0nPkYPTuBzYMQ06746F6ieGVUy81Mr9RtvtZp3iQ=; b=h/aHQ4ZeQnxcspZksxxH6lQHwlF2osYzyhbc0VekomBa+Nx7w2uKYesZA1c3C396z2 Ieh1NfucfXZ7I5EBW31dz6nAY4Rxnj9aO1wHX1lHrwA8wpIgatl9snRljbm/2WnM3YC0 CPnfpYLyOtp0mi0jf+TO7Mm/6RwPUOzYZkr+ABUL4O7VXJkvayeAl931SWAQlesCHIKx 6lhb6WDcy6eN3dFAyAP+AYQoc8vixxdfpusdVBxmBTIDooMd1eyl4st2aHxXgRksnMri jmAGTsJIpvTqjVvo0ae/B8JaTdCiHQfWmrhdNLEEOmvodqgodA6QxNR20dnt8jKXGy2a /EsA== MIME-Version: 1.0 X-Received: by 10.236.135.172 with SMTP id u32mr1321963yhi.107.1392699627686; Mon, 17 Feb 2014 21:00:27 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 17 Feb 2014 21:00:27 -0800 (PST) In-Reply-To: References: <1392624588.30995.10.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 17 Feb 2014 21:00:27 -0800 Message-ID: From: Watson Ladd To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Cm3Cq1nGJR0uy-U26cvSsfFwcZ4 Cc: =?UTF-8?Q?Niels_M=C3=B6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:00:32 -0000 On Mon, Feb 17, 2014 at 6:05 PM, Adam Langley wrote: > On Mon, Feb 17, 2014 at 10:45 AM, Watson Ladd wrote: >> Alternatively, we can >> encrypt the entire file as one big chunk and decrypt on receipt. I've >> still not found a case where one of these doesn't work. > > I don't believe that there's any disagreement about the fact that > operating on the file as one, large chunk works, technically. > > The problem is that I believe that it results in dangerous APIs. For > example, OpenPGP does this and I was very unhappy about it when > writing this[1] implementation which returns unverified plaintext. I > called the Reader "UnverifiedBody" and put a big comment in there but > I think we should be able to do better. The point of AEADs was to > provide a safer abstraction in the first place, no? > > (Niels suggested buffering everything before returning anything and > that's certainly safe. But I feel that it's somewhat anti-social for a > library to do so.) I don't think there is any way around that. If I want to ensure all read data has property P, and P depends on every byte of input, I need to look at all the input bytes before revealing any data. Sincerely, Watson Ladd > > [1] https://code.google.com/p/go/source/browse/openpgp/read.go?repo=crypto#38 > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org http://www.imperialviolet.org -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Feb 17 21:19:36 2014 Return-Path: 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 02B2B1A0346 for ; Mon, 17 Feb 2014 21:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 1T1k6flB0T0C for ; Mon, 17 Feb 2014 21:19:32 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 405111A0433 for ; Mon, 17 Feb 2014 21:19:30 -0800 (PST) Received: from [174.240.0.194] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WFd5V-0001QE-5e; Tue, 18 Feb 2014 00:19:22 -0500 Date: Mon, 17 Feb 2014 21:19:15 -0800 From: Bill Frantz To: Watson Ladd X-Priority: 3 In-Reply-To: Message-ID: 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79955ce535a38188e502f8b7671b00290b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.240.0.194 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3eXVPW0A85xLrGUMglYyWHBTxqE Cc: Adam Langley , =?UTF-8?Q?Niels_M=C3=B6ller?= , tls@ietf.org Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:19:34 -0000 On 2/17/14 at 9:00 PM, watsonbladd@gmail.com (Watson Ladd) wrote: >I don't think there is any way around that. If I want to ensure all >read data has property P, and P depends on every byte of input, I need >to look at all the input bytes before revealing any data. Well, you can work on sub-blocks of the whole chunk of data.=20 Either a MAC or digital signature on each sub-block would do.=20 Verify the sub-block and it can be released to the relying=20 application. If we are using a 32 byte MAC, then 3200 byte=20 blocks would only have 1% overhead for checking. There are very=20 few systems where a buffer size the order of 3200 would cause a=20 serious problem. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345=20 Englewood Ave www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nobody Mon Feb 17 21:39:03 2014 Return-Path: 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 17F4E1A00D3 for ; Mon, 17 Feb 2014 21:39:02 -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 1ox_KqhhbNtL for ; Mon, 17 Feb 2014 21:39:00 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 208EC1A02EE for ; Mon, 17 Feb 2014 21:39:00 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id z6so15033653yhz.30 for ; Mon, 17 Feb 2014 21:38:57 -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=fdE3TQ+bIoG/xcJ6TBqNbTLgCmvqZ7FtwUDL2dIGJBA=; b=NMthWmbCVFRrTSRKtk67LUBTJXxaSik1Obeoa9c2ZdpqRwpv72PN01Mqg27kJjsEpe YJ4rDdpznhUTUag65f5wXNUipOB/P/OVsogt28zEIvDrutqZTKsDL7LOBYFOzKotepPQ 7ioJsrYViTHjT+DHICqd4lhM4/daXftjOWuBhzjR+jpzqxNAuXfCvTUmiIkmClrnlVeQ Ua7lKil8hJgH0Mj2MmOcajoJN3VPCLNrU6QZWIidz/OUycIFFxM9mT74k+IdKKEiKFPE OQNaYJBj01YN4xS5Rt6wTVVtcMrJQf9OMCbr7lreMjTr/keUQtx0KZS5jMT2eAVb7cly OXfw== MIME-Version: 1.0 X-Received: by 10.236.137.14 with SMTP id x14mr31053282yhi.4.1392701937229; Mon, 17 Feb 2014 21:38:57 -0800 (PST) Received: by 10.170.92.85 with HTTP; Mon, 17 Feb 2014 21:38:57 -0800 (PST) In-Reply-To: References: Date: Mon, 17 Feb 2014 21:38:57 -0800 Message-ID: From: Watson Ladd To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uRja7ZF0N3i3cMDnwrl5YMpodGM Cc: Adam Langley , =?UTF-8?Q?Niels_M=C3=B6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:39:02 -0000 On Mon, Feb 17, 2014 at 9:19 PM, Bill Frantz wrote: > On 2/17/14 at 9:00 PM, watsonbladd@gmail.com (Watson Ladd) wrote: > >> I don't think there is any way around that. If I want to ensure all >> read data has property P, and P depends on every byte of input, I need >> to look at all the input bytes before revealing any data. > > > Well, you can work on sub-blocks of the whole chunk of data. Either a MAC or > digital signature on each sub-block would do. Verify the sub-block and it > can be released to the relying application. If we are using a 32 byte MAC, > then 3200 byte blocks would only have 1% overhead for checking. There are > very few systems where a buffer size the order of 3200 would cause a serious > problem. > The application has to be ready to accept truncations on arbitrary subblock boundaries for this to work out. That's not the same as semantics indicating the entire file is fine if you can read from it. Sincerely, Watson Ladd > Cheers - Bill > > ----------------------------------------------------------------------- > Bill Frantz |The nice thing about standards| Periwinkle > (408)356-8506 |is there are so many to choose| 16345 Englewood Ave > www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos, CA 95032 > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Feb 17 22:17:12 2014 Return-Path: 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 1DA821A05F1 for ; Mon, 17 Feb 2014 22:17:11 -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 iXcxokjkwEho for ; Mon, 17 Feb 2014 22:17:09 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9422E1A0609 for ; Mon, 17 Feb 2014 22:17:09 -0800 (PST) Received: from [174.240.0.194] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WFdzL-0002cS-Fi; Tue, 18 Feb 2014 01:17:05 -0500 Date: Mon, 17 Feb 2014 22:17:00 -0800 From: Bill Frantz To: Watson Ladd X-Priority: 3 In-Reply-To: Message-ID: 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79dc15266565d7107457b38c6e7776d783350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.240.0.194 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kQ0iL0wGYOF2Jm9gRFj5L3g9udU Cc: Adam Langley , =?UTF-8?Q?Niels_M=C3=B6ller?= , tls@ietf.org Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 06:17:11 -0000 On 2/17/14 at 9:38 PM, watsonbladd@gmail.com (Watson Ladd) wrote: >The application has to be ready to accept truncations on arbitrary >subblock boundaries for this to work out. >That's not the same as semantics indicating the entire file is fine if >you can read from it. However, it is a situation that any application that is reading=20 files needs to be prepared to handle. Disk errors and all=20 that... Not much different from losing the network connection=20 either. In fact, there is probably no way to assure the=20 application that it absolutely, no fail -- ever --, will be able=20 to read some data, even if the data is all in main memory. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"After all, if the conventional wisdom was=20 working, the 408-356-8506 | rate of systems being compromised would be=20 going down, www.pwpconsult.com | wouldn't it?" -- Marcus Ranum From nobody Tue Feb 18 02:15:30 2014 Return-Path: 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 CF5151A0625 for ; Tue, 18 Feb 2014 02:15:29 -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 trY8M0b0Ees0 for ; Tue, 18 Feb 2014 02:15:28 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E72F91A062C for ; Tue, 18 Feb 2014 02:15:27 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id g12so19099290oah.3 for ; Tue, 18 Feb 2014 02:15:25 -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=ry73kzWr/bDFVjkTVUcEeGBSzsj4EnQpuvqgHJvqYSg=; b=T/RNiP5P6blToNBGTNkcuaJAkQE1g3L6AHsr0Qchcg9Ku0rGG6J0tOYgq1JvHZ1I7P Ec6mYVpwO6yBUtC0kKBXf+tXcfVa0R9MeT7rXoV35tPa99VwESLgmKL+3RgwoHcjRtPC mvjBADKBzSou2uXrqrbbAy33+fK6hcfDpTTvw= 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=ry73kzWr/bDFVjkTVUcEeGBSzsj4EnQpuvqgHJvqYSg=; b=M8IZZoO5ykUahoBCkhj/v7NdH55+ovCuhiKJLb/liYQY7KDc2WvQV8l8m19i9Bh4iQ ra2TQp2bH6b1O5Dpf1has86MPZc5RVfouFU+DxqOYxmpBNUsxJdJU0dakqmXJ9qFflbl qbLY9Asusmj/Kllm476x1eNLz2rdsq+Jb+U3B9taqyQUboN3IXO8U6PHyRuekXpmYDKv Zq/uYEiYuJVu8S2k4OWzkTv+pjWiDcXUO7haUXsBSGeg4AdY1+tIyFNrqbXEWS5JZ7Wx OoYVeTukdMkk73jKbbixgXJmS1dv/jAM0F4dwIVaDV7SAxroaw3aI81ukfQiDhsFVCF0 9Xqg== X-Gm-Message-State: ALoCoQmiTVpPK9I56DVwKlqmiduLc8OkrW1ronQF2yebEUhxy+1muTkz5rgX6ePy44iKrOAmzjOZ MIME-Version: 1.0 X-Received: by 10.182.40.37 with SMTP id u5mr10750697obk.41.1392718524908; Tue, 18 Feb 2014 02:15:24 -0800 (PST) Received: by 10.76.10.102 with HTTP; Tue, 18 Feb 2014 02:15:24 -0800 (PST) X-Originating-IP: [128.93.188.195] In-Reply-To: References: Date: Tue, 18 Feb 2014 11:15:24 +0100 Message-ID: From: Alfredo Pironti To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gXqrBpwI853pDQo081tMCfhPYJo Cc: Adam Langley , =?UTF-8?Q?Niels_M=C3=B6ller?= , "tls@ietf.org" Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 10:15:30 -0000 On Tue, Feb 18, 2014 at 7:17 AM, Bill Frantz wrote: > On 2/17/14 at 9:38 PM, watsonbladd@gmail.com (Watson Ladd) wrote: > >> The application has to be ready to accept truncations on arbitrary >> subblock boundaries for this to work out. >> That's not the same as semantics indicating the entire file is fine if >> you can read from it. > > > However, it is a situation that any application that is reading files needs > to be prepared to handle. Disk errors and all that... Not much different > from losing the network connection either. In fact, there is probably no way > to assure the application that it absolutely, no fail -- ever --, will be > able to read some data, even if the data is all in main memory. TLS is indeed designed to distinguish between "fatal" closure and "graceful" closure. A "fatal" closure (fatal alert or network disruption) ensures that a *prefix* of the data sent by the peer are received; by comparison, "graceful" closure via full-duplex close_notify ensures that *all* data are received as sent by the peer. Even the standard socket and I/O functions make this distinction (although there's no integrity check there). Cheers, Alfredo > > Cheers - Bill > > --------------------------------------------------------------------------- > Bill Frantz |"After all, if the conventional wisdom was working, the > 408-356-8506 | rate of systems being compromised would be going down, > www.pwpconsult.com | wouldn't it?" -- Marcus Ranum > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 18 04:57:03 2014 Return-Path: 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 A35BA1A062F for ; Tue, 18 Feb 2014 04:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] 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 61wm5PA1VUnb for ; Tue, 18 Feb 2014 04:56:54 -0800 (PST) Received: from bacon.lysator.liu.se (vindbrygga.lysator.liu.se [IPv6:2001:6b0:17:f0a0::de]) by ietfa.amsl.com (Postfix) with ESMTP id 4812E1A047A for ; Tue, 18 Feb 2014 04:56:52 -0800 (PST) Received: from bacon.lysator.liu.se (localhost [127.0.0.1]) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5) with ESMTP id s1ICukr6023507; Tue, 18 Feb 2014 13:56:46 +0100 (MET) Received: (from nisse@localhost) by bacon.lysator.liu.se (8.14.5+Sun/8.14.5/Submit) id s1ICufkq023491; Tue, 18 Feb 2014 13:56:41 +0100 (MET) X-Authentication-Warning: bacon.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f From: nisse@lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=) To: Bill Frantz References: Date: Tue, 18 Feb 2014 13:56:41 +0100 In-Reply-To: (Bill Frantz's message of "Mon, 17 Feb 2014 22:17:00 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/95G_Nh1S8cNnDci4alldKPULoOw Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 12:56:56 -0000 Bill Frantz writes: > However, it is a situation that any application that is reading files > needs to be prepared to handle. Disk errors and all that... I think there's a difference between on one hand, truncation due to random failures of your own, reasonably trusted, hardware. And on the other hand, truncation caused the enemy attacking the communication channel for some evil purpose. If we really want to make progress with this discussion, I guess we must also distinguish between file types where appending data doesn't change the meaning of earlier data (e.g, a typical log file), and file types where appending data can change the meaning radically (e.g., consider a document format where you can add data at the end of the file which adds a mark "this document is fake" on top of every page when the file is displayed or printed). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From nobody Tue Feb 18 08:06:21 2014 Return-Path: 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 73AEF1A069B for ; Tue, 18 Feb 2014 08:06:19 -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 CY9_gaB_0OUd for ; Tue, 18 Feb 2014 08:06:14 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id E63001A06A5 for ; Tue, 18 Feb 2014 08:06:13 -0800 (PST) Received: from [10.70.10.63] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 13E94F984 for ; Tue, 18 Feb 2014 11:06:08 -0500 (EST) Message-ID: <530384E4.3050705@fifthhorseman.net> Date: Tue, 18 Feb 2014 11:05:56 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q8tB0Ge1K5wc7gXnDBALsIQhbIm2JEmGk" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/py8U2D_ecTB_og6qql24bQlpcQk Subject: [TLS] dealing with AEAD partial delivery [was: Re: Comments on] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:06:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q8tB0Ge1K5wc7gXnDBALsIQhbIm2JEmGk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/18/2014 07:56 AM, Niels M=C3=B6ller wrote: > I think there's a difference between on one hand, truncation due to > random failures of your own, reasonably trusted, hardware. And on the > other hand, truncation caused the enemy attacking the communication > channel for some evil purpose. I agree that there is a difference between those cases in the abstract sense. But from the recipient's point of view, these cases are often indistinguishable from one another. I'm not sure that any AEAD api should try to distinguish between them. > If we really want to make progress with this discussion, I guess we mus= t > also distinguish between file types where appending data doesn't change= > the meaning of earlier data (e.g, a typical log file), and file types > where appending data can change the meaning radically (e.g., consider a= > document format where you can add data at the end of the file which add= s > a mark "this document is fake" on top of every page when the file is > displayed or printed). I think this distinction is also likely to be hard for generic tools (tools which want to be context-independent) to make. But, just going with a non-exhaustive, first-pass comparison approach, there are some unsettling results: text/html is a content-type that meets the "sensitive-append/risky-truncation" definition, since new html elements (not to mention javascript) can effectively obscure or override previous html elements, at least in common visual renderers; text/plain arguably meets the "insensitive-append/safe-truncation" definition, since new elements never directly collide with old elements (though a postscript to a human-drafted document that says "PS ha ha just kidding" changes the semantics of the earlier content significantly). Looking at the behavior of modern browsers using https with GCM (ECDHE-RSA-AES128-GCM-SHA256), they render both text/html and text/plain data streams as they receive them, and they do not provide any indication to the user that they believe the data to be truncated, even when receiving an early TCP connection termination, or when a Content-Length: header is not satisfied, or when (in the case of text/html) the html document is not properly closed. So content truncation attacks appear to be already possible in current implementations, despite any guarantees provided by AEAD. Note that I haven't tried to attack the AEAD itself at the TLS record layer, but i'm observing that common utilities like browsers don't propagate truncation errors up to the user already. :( Perhaps this angle on the issue is best moved over to the uta working group, since it's about what to do in the application layer with certain kinds of TLS failures. --dkg --q8tB0Ge1K5wc7gXnDBALsIQhbIm2JEmGk 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 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTA4TkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc7MgP/1lfAtzkIvEA/JRvjCs0YEvd QWcdQCthixkoAZJ1T3Zaxtq6xhaTR/YHbYM3+EcQ24ArrsSitAUTWq61Pi9OLRQt BaVkUQ13QwtVWP8sq/ASICeczYv+m5dnTcQu42CjEkZgQDOZEI+4CVlBOQdxhZ8E LgKHDii0mKnQppSXx8yqvTFANStPE2+Qeq7TNfSm2VrWIHbZogytZFUUCdfsHSAK 1JWBaMcfeu/oxmezQKPReUiN7D/2dQVFkE91XFhlwvkecsgs85PZT9GH7jWlY4ti 3fJLn2zQ83zoOofUPJPc+VbDp9sklqOzSbdXtXc+Oonz+oStbRUUrMzAQJiOyFiq IOEZm6BG090IOMHnEibBY02ZSoR/5ic4soQjHBDeJgpOrOHSR/hj8nSbtEFam3BM yqmrBqrwZGc410G92qhoNgk6QZMaWevHwS3CeC1FE4sJQkExx1RNNeLnEIjyrmny 1UnbQCP/Ca8s81FjrOKVkRSnLdUM+ahaIl6MHcJS7VgvoXa35gRoX8hIfRvAVlI5 Y9+UpSh6waXypfMxDHvdwHc5Jpwgc/SvLxOImt5nkZdrgxjhB/vC8DwNT3+Kb8nv Od5PbTnI7jxvGcwTC58MCLuW4AgIe7QDR1Cq63+skpWGXak6Ve0ec6Hk+/irK38S LQJ42KVvZvmDJNHyvFIe =GKcU -----END PGP SIGNATURE----- --q8tB0Ge1K5wc7gXnDBALsIQhbIm2JEmGk-- From nobody Tue Feb 18 13:49:46 2014 Return-Path: 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 8BBC11A03F0 for ; Tue, 18 Feb 2014 13:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 zI5OJXj9n57Z for ; Tue, 18 Feb 2014 13:49:43 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id D50F21A02B9 for ; Tue, 18 Feb 2014 13:49:42 -0800 (PST) Received: from [174.234.1.147] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WFsXp-0001iD-O1; Tue, 18 Feb 2014 16:49:38 -0500 Date: Tue, 18 Feb 2014 13:49:36 -0800 From: Bill Frantz To: Niels =?iso-8859-1?Q?M=F6ller?= X-Priority: 3 In-Reply-To: Message-ID: 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec790745ea710b67ac215d0b58704dc93b67350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.234.1.147 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z405R0uMOzKgER1qLsaN5anCHzU Cc: Adam Langley , tls@ietf.org Subject: Re: [TLS] Comments on 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:49:44 -0000 On 2/18/14 at 4:56 AM, nisse@lysator.liu.se (Niels M=C3=B6ller) wrote: >Bill Frantz writes: > >>However, it is a situation that any application that is reading files >>needs to be prepared to handle. Disk errors and all that... > >I think there's a difference between on one hand, truncation due to >random failures of your own, reasonably trusted, hardware. And on the >other hand, truncation caused the enemy attacking the communication >channel for some evil purpose. From the point of view of an application, there isn't much=20 difference. In both cases, it receives notification from the=20 infrastructure that the read couldn't complete because an error occurred. System managers certainly want to know if they are under attack,=20 but even just knowing that there was a MAC verification failure=20 is not solidly definitive. There could have been an undetected=20 failure in the transmission which only showed up because of the=20 MAC failure -- since the MAC is a stronger check than the checks=20 in TCP/IP. IF I were that manager, one failure -- be on high=20 alert for attackers. Two failures -- try to located the=20 attackers and deal with them. :-) >If we really want to make progress with this discussion, I guess we must >also distinguish between file types where appending data doesn't change >the meaning of earlier data (e.g, a typical log file), and file types >where appending data can change the meaning radically (e.g., consider a >document format where you can add data at the end of the file which adds >a mark "this document is fake" on top of every page when the file is >displayed or printed). I see no need to make such a distinction at our level. We will=20 give the application an error that says we couldn't give it all=20 the data. How it handles the error is not our problem. Handling=20 this error like any other "couldn't read the rest of the file"=20 error seems right in all cases. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | Re: Computer reliability, performance, and security: 408-356-8506 | The guy who *is* wearing a parachute is=20 *not* the www.pwpconsult.com | first to reach the ground. - Terence Kelly From nobody Wed Feb 19 12:41:27 2014 Return-Path: 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 561941A022E for ; Wed, 19 Feb 2014 12:41:25 -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 A1D4IZnyGJsq for ; Wed, 19 Feb 2014 12:41:22 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4C10D1A051C for ; Wed, 19 Feb 2014 12:41:22 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id oy12so967020veb.37 for ; Wed, 19 Feb 2014 12:41:18 -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=NCniMNG4oDFYtbMM9gzz8FvuGhJuz3qNyawwYRRjS+U=; b=lCCG2ECM57i2gIwm0GN/O7fsQOmClNOnF9oiGyXzUjMqdFqYXcrvXg3J4dkPrWxiOv B6egtupwmboZltH6GKVIMfo5+o3Yhxld3Jw9RUxKCz5XlM31bL/hrnq8gT1Y4ysxIAqk cnGdybAaOHg7VXczMjrwuherlhTuW0A1y9UAjRVmt3c93WcHvEJFJ/GvF1TST6nmZjpD zFP0XKkhJVfzGMsY37A3NVvvE1vxeFj2qsHeirUTQcIYUqEFsjlA3QlNTsbmhAYgNgDm c370zJqJJDROipUxnqN1u7FjWXHShGykqEGF0bJdGr/jvwZGJmbmIshjHLZLxJI/SHtw Ta7g== X-Gm-Message-State: ALoCoQntVNxLzGxCI+SRJVMU78b/WKGoEStMOnPa0RDhj8jjyBdc3rbq6zRK29yqjbmdIlZRXA1I X-Received: by 10.221.34.211 with SMTP id st19mr26790227vcb.5.1392842478418; Wed, 19 Feb 2014 12:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.198.12 with HTTP; Wed, 19 Feb 2014 12:40:38 -0800 (PST) X-Originating-IP: [74.95.2.168] From: Eric Rescorla Date: Wed, 19 Feb 2014 12:40:38 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1136516c2792cf04f2c869ac Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ym3sFaFLoiUNmSv9IVVyqOCMvLA Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:41:25 -0000 --001a1136516c2792cf04f2c869ac Content-Type: text/plain; charset=ISO-8859-1 Folks, I have prepared a new version of the TLS 1.3 flows document which should appear in the repository shortly and in the meantime can be found at: https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt This version fleshes out a "recommended" set of flows: - 2-RTT where the client has no knowledge of the server's capabilities. - 1-RTT where the client knows the server's semi-permanent DHE/ECDHE key pair. - 0-RTT where the client and the server have shared anti-replay state. There are still a number of open issues, but this should be clear enough to see the direction I am trying to go. These flows are structured so that the 1-RTT case is the base case with the 2-RTT and 0-RTT versions being variants of the basic 1-RTT handshake. All variants encrypt the client extensions that are not required to define the cryptographic processing (e.g., SNI is encrypted but curve negotiation is not). I think the high order bit here is whether we want to have encrypted SNI, because that dictates the position of the DHE exchanges with respect to the server's messages. There are three options here: - Never - Sometimes - Always The flows in this draft take the position of "Always" which is simple. "Never" is actually simpler. "Sometimes" is the most complicated. There are two cases where we could shave off latency if we were willing to disclose the SNI to passive attackers (and in cases where the client and server have never talked before.) My sense of recent discussion is that people feel it's important to have modes that protect SNI even if those are not the only modes. However, that means that if we want to have non-SNI protecting modes, they are additional complexity. Please let me know if I have misread the WG here. Here are some other things to keep in mind as you read the document. - Per my sense of the list, I have totally removed static RSA. If people strongly object to that, please speak up and let me know. - There has been no real security analysis of this material other than at the hand-wavy level. We clearly need that, but the first thing we need is to be clear on whether this is approximately the right set of points in the complexity/performance/privacy tradeoff space and then make sure that the security properties are correct. So, if you see something that looks wrong or even grievously wrong, don't panic (but do point it out). - There is no currently defined support for any kind of resumption. We need to decide if resumption is still an important feature in light of the trend towards more PFS and faster processors. I'm particularly looking for input from the IoT/DICE guys here. - We will probably need to work out some of the details for DTLS, but I wanted to get TLS nailed down first. - We also need to do some work on the symmetric crypto, e.g., to make encrypt-then-MAC the default, perhaps to deprecate some ciphers, compression, etc. I haven't forgotten that, but I want to deal with the handshakes first. - As before, this incorporates ideas from a lot of different people (and many times the same idea from different people). If you think you should acknowledged in the text and/or acknowledgements differently, please let me know. Thanks and comments welcome -Ekr --001a1136516c2792cf04f2c869ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,

I have prepared a new= version of the TLS 1.3 flows document which
should appear in the= repository shortly and in the meantime can be
found at:


This version fleshe= s out a "recommended" set of flows:

- 2-RTT where the client has no knowledge of the
<= div>=A0 server's capabilities.

- 1-RTT where t= he client knows the server's semi-permanent
=A0 DHE/ECDHE key= pair.

- 0-RTT where the client and the server have shared ant= i-replay
=A0 state.

There are still a nu= mber of open issues, but this should be clear
enough to see the d= irection I am trying to go. These flows are
structured so that the 1-RTT case is the base case with the 2-RTT and<= /div>
0-RTT versions being variants of the basic 1-RTT handshake. All
variants encrypt the client extensions that are not required
to define the cryptographic processing (e.g., SNI is encrypted
but curve negotiation is not).

I think the high= order bit here is whether we want to have
encrypted SNI, because= that dictates the position of the DHE
exchanges with respect to the server's messages.

There are three options here:

- Never
- Sometimes
- Always

The flows in = this draft take the position of "Always" which is
simple. "Never" is actually simpler. "Sometimes" i= s the most
complicated. =A0There are two cases where we could sha= ve off latency if
we were willing to disclose the SNI to passive = attackers (and in cases
where the client and server have never talked before.) My sense of
recent discussion is that people feel it's important to have mod= es
that protect SNI even if those are not the only modes. However= , that
means that if we want to have non-SNI protecting modes, they are
=
additional complexity. Please let me know if I have misread the WG
here.

=A0
Here are some other thi= ngs to keep in mind as you read the document.

- Per my sense of the list, I have totally removed stat= ic RSA. =A0If
people strongly object to that, please speak up and= let me know.

- There has been no real security an= alysis of this material other than
at the hand-wavy level. We clearly need that, but the first thing we
need is to be clear on whether this is approximately the right set= of
points in the complexity/performance/privacy tradeoff space a= nd then
make sure that the security properties are correct. So, if you see
something that looks wrong or even grievously wrong, don't panic= (but
do point it out).
=A0
=A0
- T= here is no currently defined support for any kind of resumption.
We need to decide if resumption is still an important feature in light=
of the trend towards more PFS and faster processors. =A0I'm = particularly
looking for input from the IoT/DICE guys here.

- We will probably need to work out some of the details= for DTLS, but
I wanted to get TLS nailed down first.
<= br>
- We also need to do some work on the symmetric crypto, e.g.,= to make
encrypt-then-MAC the default, perhaps to deprecate some ciphers,
=
compression, etc. I haven't forgotten that, but I want to deal wit= h
the handshakes first.

- As before, thi= s incorporates ideas from a lot of different people
(and many times the same idea from different people). If you think
you should acknowledged in the text and/or acknowledgements
differently, please let me know.

Thanks and comm= ents welcome
-Ekr




=



=A0=A0



--001a1136516c2792cf04f2c869ac-- From nobody Wed Feb 19 13:54:53 2014 Return-Path: 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 C476E1A0226 for ; Wed, 19 Feb 2014 13:54:52 -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 vwKPRKv0DRdJ for ; Wed, 19 Feb 2014 13:54:50 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id D88651A01C1 for ; Wed, 19 Feb 2014 13:54:49 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id db12so1040852veb.39 for ; Wed, 19 Feb 2014 13:54:46 -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:content-type; bh=M9/Vz5Uj0s/YJqDMnVkscxPe7Z9eBL7FaEX8uFPKF+U=; b=DyTrZH4MimCOF+Cw1JWQ7nPcOB2nw9vz7eDGLm7NJCD3IjO6twQuScizuoanQYywPx mL9Rhi8cPo7sF3ib7+ZEjl9mFPtwvwTKe8MavWZSeH1/2KqVbxQe4Fg/xr9FdyTrJRNx bH/uBr2svn9t//bXpq17h7BDTTf0szkS4V8npGE+mip1GNRo2lBqKw6E05C5cDIzqTg0 mNvqtyrADdzgL4g85AeOdpSYKTvwMvJzcgbc8TfR04EFPAtuKLW+nEFrnSY02LZLxEAx vuGZp8FrAsvdB7t6nS2DclI5V2qEgdfMbt8r8GUVADtUhvPi6WOhphWiY+3NKdWscUr6 MtrQ== X-Gm-Message-State: ALoCoQncA9pSxrBJIY0vSFqAtDeGgs70IDUSFLxKOF6kz5QB3EI4tbaIZQ8T/SMUmc41kTpKs/pv X-Received: by 10.52.69.132 with SMTP id e4mr1623173vdu.91.1392846886255; Wed, 19 Feb 2014 13:54:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.198.12 with HTTP; Wed, 19 Feb 2014 13:54:06 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 19 Feb 2014 13:54:06 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf307abd91e1ecd104f2c96ff6 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qh08NxYsgFR5slZ5i5h5koWSam0 Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:54:52 -0000 --20cf307abd91e1ecd104f2c96ff6 Content-Type: text/plain; charset=ISO-8859-1 One more point that someone made to me offline. The flows in this document make multiple use of the same DH/ECDH share (i.e., pairing the client's ECDH share with two separate server shares.) This is in some respects like static DH and so we should provide appropriate security guidance. There's already some such guidance in RFC 5246 Section F.1.1.3: http://tools.ietf.org/html/rfc5246#appendix-F.1.1.3 We might also consider whether it makes sense to specify a fixed set of DH parameters (a la IKE and in the spirit of the specified curves in RFC 4492), thus avoiding any need for people to validate. That seems like something that might be valuable for all versions of TLS. Do we need anything else? -Ekr On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla wrote: > Folks, > > I have prepared a new version of the TLS 1.3 flows document which > should appear in the repository shortly and in the meantime can be > found at: > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt > > This version fleshes out a "recommended" set of flows: > > - 2-RTT where the client has no knowledge of the > server's capabilities. > > - 1-RTT where the client knows the server's semi-permanent > DHE/ECDHE key pair. > > - 0-RTT where the client and the server have shared anti-replay > state. > > There are still a number of open issues, but this should be clear > enough to see the direction I am trying to go. These flows are > structured so that the 1-RTT case is the base case with the 2-RTT and > 0-RTT versions being variants of the basic 1-RTT handshake. All > variants encrypt the client extensions that are not required > to define the cryptographic processing (e.g., SNI is encrypted > but curve negotiation is not). > > I think the high order bit here is whether we want to have > encrypted SNI, because that dictates the position of the DHE > exchanges with respect to the server's messages. > > There are three options here: > > - Never > - Sometimes > - Always > > The flows in this draft take the position of "Always" which is > simple. "Never" is actually simpler. "Sometimes" is the most > complicated. There are two cases where we could shave off latency if > we were willing to disclose the SNI to passive attackers (and in cases > where the client and server have never talked before.) My sense of > recent discussion is that people feel it's important to have modes > that protect SNI even if those are not the only modes. However, that > means that if we want to have non-SNI protecting modes, they are > additional complexity. Please let me know if I have misread the WG > here. > > > Here are some other things to keep in mind as you read the document. > > - Per my sense of the list, I have totally removed static RSA. If > people strongly object to that, please speak up and let me know. > > - There has been no real security analysis of this material other than > at the hand-wavy level. We clearly need that, but the first thing we > need is to be clear on whether this is approximately the right set of > points in the complexity/performance/privacy tradeoff space and then > make sure that the security properties are correct. So, if you see > something that looks wrong or even grievously wrong, don't panic (but > do point it out). > > > - There is no currently defined support for any kind of resumption. > We need to decide if resumption is still an important feature in light > of the trend towards more PFS and faster processors. I'm particularly > looking for input from the IoT/DICE guys here. > > - We will probably need to work out some of the details for DTLS, but > I wanted to get TLS nailed down first. > > - We also need to do some work on the symmetric crypto, e.g., to make > encrypt-then-MAC the default, perhaps to deprecate some ciphers, > compression, etc. I haven't forgotten that, but I want to deal with > the handshakes first. > > - As before, this incorporates ideas from a lot of different people > (and many times the same idea from different people). If you think > you should acknowledged in the text and/or acknowledgements > differently, please let me know. > > Thanks and comments welcome > -Ekr > > > > > > > > > > > > --20cf307abd91e1ecd104f2c96ff6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One more point that someone made to me offline.

The flows in this document make multiple use of the same DH/ECDH
share (i.e., pairing the client's ECDH share with two separate= server
shares.) This is in some respects like static DH and so we should
provide appropriate security guidance. There's already some such<= /div>
guidance in RFC 5246 Section F.1.1.3:



We might also consider whether it makes sen= se to specify a fixed
set of DH parameters (a la IKE and in the spirit of the specified
curves in RFC 4492), thus avoiding any need for people to
v= alidate. That seems like something that might be valuable for
all versions of TLS.

Do we need anything else?

-Ekr








On Wed, Feb 19, = 2014 at 12:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Folks,

<= /div>
I have prepared a new version of the TLS 1.3 flows document which=
should appear in the repository shortly and in the meantime can be
found at:


This version fleshes out a "recommended" set of flows:

- 2-RTT where the client has no knowledge of the
<= div>=A0 server's capabilities.

- 1-RTT where t= he client knows the server's semi-permanent
=A0 DHE/ECDHE key= pair.

- 0-RTT where the client and the server have shared ant= i-replay
=A0 state.

There are still a nu= mber of open issues, but this should be clear
enough to see the d= irection I am trying to go. These flows are
structured so that the 1-RTT case is the base case with the 2-RTT and<= /div>
0-RTT versions being variants of the basic 1-RTT handshake. All
variants encrypt the client extensions that are not required
to define the cryptographic processing (e.g., SNI is encrypted
but curve negotiation is not).

I think the high= order bit here is whether we want to have
encrypted SNI, because= that dictates the position of the DHE
exchanges with respect to the server's messages.

There are three options here:

- Never
- Sometimes
- Always

The flows in = this draft take the position of "Always" which is
simple. "Never" is actually simpler. "Sometimes" i= s the most
complicated. =A0There are two cases where we could sha= ve off latency if
we were willing to disclose the SNI to passive = attackers (and in cases
where the client and server have never talked before.) My sense of
recent discussion is that people feel it's important to have mod= es
that protect SNI even if those are not the only modes. However= , that
means that if we want to have non-SNI protecting modes, they are
=
additional complexity. Please let me know if I have misread the WG
here.

=A0
Here are some other thi= ngs to keep in mind as you read the document.

- Per my sense of the list, I have totally removed stat= ic RSA. =A0If
people strongly object to that, please speak up and= let me know.

- There has been no real security an= alysis of this material other than
at the hand-wavy level. We clearly need that, but the first thing we
need is to be clear on whether this is approximately the right set= of
points in the complexity/performance/privacy tradeoff space a= nd then
make sure that the security properties are correct. So, if you see
something that looks wrong or even grievously wrong, don't panic= (but
do point it out).
=A0
=A0
- T= here is no currently defined support for any kind of resumption.
We need to decide if resumption is still an important feature in light=
of the trend towards more PFS and faster processors. =A0I'm = particularly
looking for input from the IoT/DICE guys here.

- We will probably need to work out some of the details= for DTLS, but
I wanted to get TLS nailed down first.
<= br>
- We also need to do some work on the symmetric crypto, e.g.,= to make
encrypt-then-MAC the default, perhaps to deprecate some ciphers,
=
compression, etc. I haven't forgotten that, but I want to deal wit= h
the handshakes first.

- As before, thi= s incorporates ideas from a lot of different people
(and many times the same idea from different people). If you think
you should acknowledged in the text and/or acknowledgements
differently, please let me know.

Thanks and comm= ents welcome
-Ekr




=



=A0=A0




--20cf307abd91e1ecd104f2c96ff6-- From nobody Wed Feb 19 14:10:36 2014 Return-Path: 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 E23131A0438 for ; Wed, 19 Feb 2014 14:10:33 -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_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 IdhDgHLEcf7C for ; Wed, 19 Feb 2014 14:10:31 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 127541A02A1 for ; Wed, 19 Feb 2014 14:10:31 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 5D7235AA001; Wed, 19 Feb 2014 23:10:26 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 3424D1FE016D; Wed, 19 Feb 2014 23:10:26 +0100 (CET) Date: Wed, 19 Feb 2014 23:10:26 +0100 From: Kurt Roeckx To: Eric Rescorla Message-ID: <20140219221025.GA15593@roeckx.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BzzYpy3qVp0nv788FbloRdQDYPM Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:10:34 -0000 On Wed, Feb 19, 2014 at 12:40:38PM -0800, Eric Rescorla wrote: > Folks, > > I have prepared a new version of the TLS 1.3 flows document which > should appear in the repository shortly and in the meantime can be > found at: > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt > > This version fleshes out a "recommended" set of flows: > > - 2-RTT where the client has no knowledge of the > server's capabilities. > > - 1-RTT where the client knows the server's semi-permanent > DHE/ECDHE key pair. > > - 0-RTT where the client and the server have shared anti-replay > state. So reading this, one of the points I see if that you could distribute this semi-permanent DHE/ECDHE key pair via DNS for instance. I think that the presence of that information in DNS could indicate that the server does support it and I currently don't see why: - You can't do 0-RTT - SNI needs common crypto parameters The only reason I can find in your document is to prevent replay, but I currently don't see how this is a problem. I'd also like to point out that you might be leaking the site you're connecting to via DNS. Kurt From nobody Wed Feb 19 14:24:57 2014 Return-Path: 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 0BAB51A0405 for ; Wed, 19 Feb 2014 14:24:55 -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 0xS0JXrNthip for ; Wed, 19 Feb 2014 14:24:52 -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 5EF271A0226 for ; Wed, 19 Feb 2014 14:24:52 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id u56so884062wes.3 for ; Wed, 19 Feb 2014 14:24:48 -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=kI1lLNaZeNCloy0fYEKJCFWjkMPn7L2SkfKGCUFMnPg=; b=FEp3JeZG4SNCwSufhfupXyw5trRAVz2FUu0ILIxF7zwzupuuZXzXWoKme1J8kCyIwG X+pSGna+CdgkCwMgOM0JQR3tn+Zy4qcCeCuw4OYBzU6cpnMBMtadc7XY6qhRoe/qEe88 6vYxeaq8+CO9lJi0MhhkBfIdA+HGevauniN9T8xy8/dI8hL48G4/ZspH4C+HuL27pQHv 4uDlQPYdMPb/HuyA6V4KtdxTNInMfEVsAL0retNcar2ArxnCltaHKR6OoM6a0DegDtc8 XlBPmeb0VKPsjb0Z2SqBpvz1QpVpti78jxB6NNJxcfIPkoB1NM45GzHMXk4x4YP4fhep /TiQ== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr3861359wiw.50.1392848688511; Wed, 19 Feb 2014 14:24:48 -0800 (PST) Received: by 10.227.10.196 with HTTP; Wed, 19 Feb 2014 14:24:48 -0800 (PST) In-Reply-To: <20140219221025.GA15593@roeckx.be> References: <20140219221025.GA15593@roeckx.be> Date: Wed, 19 Feb 2014 14:24:48 -0800 Message-ID: From: Martin Thomson To: Kurt Roeckx Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9RXdIx33YE5FOhQqVwekPcRiO-g Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:24:55 -0000 You could put half of the first round trip in DNS, but that's a fairly major change to the protocol. Note however that the ServerParameters described in the draft is something that could be discovered through other channels, definitely. No one is checking where PredictedParameters came from, just that it is correct. On 19 February 2014 14:10, Kurt Roeckx wrote: > The only reason I can find in your document is to prevent replay, > but I currently don't see how this is a problem. If I had any reason to believe that your first flight included non-idempotent HTTP requests of interest to me (e.g., transfer $X to account Y) then replay protection is extremely interesting. > I'd also like to point out that you might be leaking the site > you're connecting to via DNS. There's already been a fair amount of discussion on why some people are interested in protecting SNI, and that point was addressed there. I'll point out that confidentiality protection for DNS queries is being discussed. From nobody Wed Feb 19 14:36:34 2014 Return-Path: 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 865491A04D2 for ; Wed, 19 Feb 2014 14:36:33 -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 mNOFu2N3Qkw5 for ; Wed, 19 Feb 2014 14:36:30 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 51A381A0412 for ; Wed, 19 Feb 2014 14:36:25 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id pa12so1094354veb.2 for ; Wed, 19 Feb 2014 14:36:21 -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=JnHD3ODmiLLBnvMEiLShJl+Bu0prXcBZxq50qvP1p8A=; b=BQo0cjK4z/wQaxnp0ZESBDOjzU9em+7q12wYrl03HUnnZ1Gwtif1rgaGTZkKx4yjV4 +veMkGh5Y3JhEzo2OOi9f9FuxCbZbtqOW7UJDA5zHojjSnUxOuPHeAfAce5w0Anlh7+U 2phn6CxIqUMr9jQATmNTYQRKuBrFDdwetX4Xiw3Qi03AHhIqDAmoDkMhFluP932pN6gi txG8p5UpdK8Ew2jH8f1x6CE0GYfgzm4BmPZsP/iHrMNvvp2h86BSkBznPVQNSNu5Oo/t +ySbcyqHchV/LC5/lH3aq6+ZJSXBTFk2cOTGRA1tVeJ43JIkQXbbW/D/jkf2PWnvAu5b 4yqA== X-Gm-Message-State: ALoCoQk7O2Cc1fSzBX8+35x+TsYenWfLtImSz199OBgqyTnejxocfbdSaPHYtuQ3h61HcKbtF0VR X-Received: by 10.221.40.10 with SMTP id to10mr22442801vcb.22.1392849381589; Wed, 19 Feb 2014 14:36:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.198.12 with HTTP; Wed, 19 Feb 2014 14:35:41 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <20140219221025.GA15593@roeckx.be> References: <20140219221025.GA15593@roeckx.be> From: Eric Rescorla Date: Wed, 19 Feb 2014 14:35:41 -0800 Message-ID: To: Kurt Roeckx Content-Type: multipart/alternative; boundary=001a113375769dc50304f2ca0477 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/60fDEbEaT-IPKH8meKUvySSTvHM Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 22:36:33 -0000 --001a113375769dc50304f2ca0477 Content-Type: text/plain; charset=ISO-8859-1 Kurt, Thanks for your comments. Responses below. On Wed, Feb 19, 2014 at 2:10 PM, Kurt Roeckx wrote: > On Wed, Feb 19, 2014 at 12:40:38PM -0800, Eric Rescorla wrote: > > Folks, > > > > I have prepared a new version of the TLS 1.3 flows document which > > should appear in the repository shortly and in the meantime can be > > found at: > > > > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt > > > > This version fleshes out a "recommended" set of flows: > > > > - 2-RTT where the client has no knowledge of the > > server's capabilities. > > > > - 1-RTT where the client knows the server's semi-permanent > > DHE/ECDHE key pair. > > > > - 0-RTT where the client and the server have shared anti-replay > > state. > > So reading this, one of the points I see if that you could > distribute this semi-permanent DHE/ECDHE key pair via DNS for > instance. Absolutely. This is contemplated in: http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.1 > I think that the presence of that information > in DNS could indicate that the server does support it and I > currently don't see why: > - You can't do 0-RTT > - SNI needs common crypto parameters > > The only reason I can find in your document is to prevent replay, > but I currently don't see how this is a problem > Generally replay is a problem whenever the server might take some action based on the client's messages. E.g., I'm buying something and I don't want to buy four of them. The reason for SNI requiring common crypto parameters is that otherwise the attacker can observe which crypto parameters you use and thus determine which virtual server you are trying to contact. I'd also like to point out that you might be leaking the site > you're connecting to via DNS. Absolutely. In order to hide which virtual server one is talking to you need to hide both: - The DNS query - The SNI and cert There are other people working on the first of these (and in many cases the attacker will only be positioned to see the SNI because of DNS caching), so hiding SNI is a bet on that other work being done. -Ekr > > Kurt > > --001a113375769dc50304f2ca0477 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kurt,

Thanks for your comments. Respons= es below.


On Wed, Feb 19, 2014 at 2:10 PM, Kurt Roeckx <kurt@roeckx.be>= wrote:
On Wed, Feb 19, 2014 at 12:40:38PM -0800, = Eric Rescorla wrote:
> Folks,
>
> I have prepared a new version of the TLS 1.3 flows document which
> should appear in the repository shortly and in the meantime can be
> found at:
>
> https://github.com/tlswg/tls13-spec/blob= /master/draft-rescorla-tls-1.3.txt
>
> This version fleshes out a "recommended" set of flows:
>
> - 2-RTT where the client has no knowledge of the
> =A0 server's capabilities.
>
> - 1-RTT where the client knows the server's semi-permanent
> =A0 DHE/ECDHE key pair.
>
> - 0-RTT where the client and the server have shared anti-replay
> =A0 state.

So reading this, one of the points I see if that you could
distribute this semi-permanent DHE/ECDHE key pair via DNS for
instance.

Absolutely. This is contemplated= in:


=A0
I think that the prese= nce of that information
in DNS could indicate that the server does support it and I
currently don't see why:
- You can't do 0-RTT
- SNI needs common crypto parameters

The only reason I can find in your document is to prevent replay,
but I currently don't see how this is a problem
Generally replay is a problem whenever the server might take
some action based on the client's messages. E.g., I'm buyi= ng
something and I don't want to buy four of them.

The reason for SNI requiring common crypto parameters is that
<= div>otherwise the attacker can observe which crypto parameters you
use and thus determine which virtual server you are trying to
contact.


I'd also like to point out that you might be leaking the site
you're connecting to via DNS.

Absolutel= y. In order to hide which virtual server one is talking to you
ne= ed to hide both:

- The DNS query
- The S= NI and cert

There are other people working on the first of these (a= nd in many
cases the attacker will only be positioned to see the = SNI because
of DNS caching), so hiding SNI is a bet on that other= work being
done.

-Ekr



Kurt


--001a113375769dc50304f2ca0477-- From nobody Wed Feb 19 15:03:30 2014 Return-Path: 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 6D4FF1A0504 for ; Wed, 19 Feb 2014 15:03:29 -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_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 NBPs1m3MAkEo for ; Wed, 19 Feb 2014 15:03:25 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEEC1A02A1 for ; Wed, 19 Feb 2014 15:03:25 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 6953B5AA001; Thu, 20 Feb 2014 00:03:21 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 3FB3C1FE016D; Thu, 20 Feb 2014 00:03:21 +0100 (CET) Date: Thu, 20 Feb 2014 00:03:21 +0100 From: Kurt Roeckx To: Martin Thomson Message-ID: <20140219230321.GA17551@roeckx.be> References: <20140219221025.GA15593@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wxhF__-BO8oaEazI9n3GI0oxT5w Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 23:03:29 -0000 On Wed, Feb 19, 2014 at 02:24:48PM -0800, Martin Thomson wrote: > You could put half of the first round trip in DNS, but that's a fairly > major change to the protocol. Note however that the ServerParameters > described in the draft is something that could be discovered through > other channels, definitely. No one is checking where > PredictedParameters came from, just that it is correct. I'm not saying that it's the only way, but it could be a way that some sites might want to use. I also think this doesn't add any additional RTT on DNS, you can run 2 or more queries at the same time. > On 19 February 2014 14:10, Kurt Roeckx wrote: > > The only reason I can find in your document is to prevent replay, > > but I currently don't see how this is a problem. > > If I had any reason to believe that your first flight included > non-idempotent HTTP requests of interest to me (e.g., transfer $X to > account Y) then replay protection is extremely interesting. I was only looking at this from the client side for some reason. At the server side I ussually deal with this at the application level instead. Kurt From nobody Fri Feb 21 06:46:39 2014 Return-Path: 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 03A701A0316 for ; Fri, 21 Feb 2014 06:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, 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 KLrzOYakgyPr for ; Fri, 21 Feb 2014 06:46:35 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 25C111A03E8 for ; Fri, 21 Feb 2014 06:46:35 -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 s1LEkUlt029471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Feb 2014 09:46:30 -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 s1LEkSRW016041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 09:46:29 -0500 Message-ID: <1392993987.4494.46.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Fri, 21 Feb 2014 15:46:27 +0100 In-Reply-To: References: 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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PzRMBqY8IbCqXNEB0o-fMJ-jZZY Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 14:46:37 -0000 On Wed, 2014-02-19 at 12:40 -0800, Eric Rescorla wrote: > Folks, > I have prepared a new version of the TLS 1.3 flows document which > should appear in the repository shortly and in the meantime can be > found at: Hello, I haven't read it yet to comment, but may I suggest something procedural? I think it would be better to first agree on the list of issues that TLS 1.3 will fix, and the list of features it will bring, and the security requirements for this protocol; as the charter is very high level for that. I believe you have already done that as part of your presentation in IETF 88, and there was some discussions on the list some time ago, but I don't know what was considered or discarded. It would be nice to have a draft that sets the desired requirements for TLS 1.3. (I'd volunteer maintain one if that is the issue) Then it will be much more easy to check whether a proposed solution satisfies the requirements, and input from other unrelated groups such as CFRG would be more easy to get. regards, Nikos PS. As I believe that security protocol design is part of cryptography, I'm still of the opinion that we should more actively seek for external expertise (e.g., by a competition or other appropriate methods). From nobody Fri Feb 21 07:17:46 2014 Return-Path: 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 2697F1A03CF for ; Fri, 21 Feb 2014 07:17:46 -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 Khy3zt0_CuMh for ; Fri, 21 Feb 2014 07:17:44 -0800 (PST) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id CFCFB1A01AB for ; Fri, 21 Feb 2014 07:17:43 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id a41so2487977yho.1 for ; Fri, 21 Feb 2014 07:17:39 -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=OWlHDDmxjD16SvwL1OVH+5OehcGMnmYN9gVsJeL/2Ws=; b=A1oyMJ92zheqOQQ6lmz+lFiWqadcgOFuaN+wDiaJUnhXM5wT60OVddPS0Cw0hxkGZC y3nncNtr6o/eVL9gedBafz3JjkxwAjJfYCJYXbt5JNUb4t2ntVDiHN3aU2Vep63G7HYP /VZDAzaVgMIDz9VpxpISs/SAx64P4PXo491AFuq85xo2jzvAzbMg8ajUuNEOHLE/TsjB 5RGbrddc81gDoqmiZO03FluqChtxSMEYfCd16/CsyYy8U0I+2ameWxu+iX/vC/dX0g0O /CczdoU8N8MhPCV+6GLFgPtmLTk52+YBlWqk7UcZyPN0PN1L+gScfUYa7NAbwrt9avoE MdmA== X-Gm-Message-State: ALoCoQkiiMJNhdIWCT0+sfWcnBWagyFAcY2SMCQ/xAbznFsqCIBm2bNiZtDCiQwcnJsg8ug6BHcg X-Received: by 10.236.135.172 with SMTP id u32mr11590559yhi.107.1392995859745; Fri, 21 Feb 2014 07:17:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.173.205 with HTTP; Fri, 21 Feb 2014 07:16:58 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <1392993987.4494.46.camel@dhcp-2-127.brq.redhat.com> References: <1392993987.4494.46.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Fri, 21 Feb 2014 07:16:58 -0800 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=20cf301af77364fdb404f2ec1f31 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H9qWXnvaCw-Znuxpp9_2_Vy3_Cs Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 15:17:46 -0000 --20cf301af77364fdb404f2ec1f31 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 21, 2014 at 6:46 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-02-19 at 12:40 -0800, Eric Rescorla wrote: > > Folks, > > I have prepared a new version of the TLS 1.3 flows document which > > should appear in the repository shortly and in the meantime can be > > found at: > > Hello, > I haven't read it yet to comment, but may I suggest something > procedural? I think it would be better to first agree on the list of > issues that TLS 1.3 will fix, and the list of features it will bring, > and the security requirements for this protocol; as the charter is very > high level for that. > > I believe you have already done that as part of your presentation in > IETF 88, and there was some discussions on the list some time ago, but I > don't know what was considered or discarded. It would be nice to have a > draft that sets the desired requirements for TLS 1.3. (I'd volunteer > maintain one if that is the issue) > > Then it will be much more easy to check whether a proposed solution > satisfies the requirements, and input from other unrelated groups such > as CFRG would be more easy to get. > I'm certainly sympathetic to this, but I don't think it's really practical to do detailed requirements first. That's always a hard approach in IETF, but it's especially hard here because there are a lot of tradeoffs to be made in terms of feature set and once you get beyond the trivial mandatory elements it's hard to make them without understanding the implications of opting to include or not include any given features without understanding the effect they have on the protocol in some detail. So, instead we've been doing this as a cyclical design process, with the charter as the very high level goals and then trying to work downward. After Vancouver, I had a lot of feedback to the effect that we needed to work out the mechanisms more so that people could make an informed decision, so that's what I've tried to do here. What I'm hoping we can do in London is to use these more worked out mechanisms to reach informed decisions on a number of the big requirements questions (static RSA, encrypted SNI, resumption, etc.) and then we can work on a refined design that matches those requirements. -Ekr regards, > Nikos > > PS. As I believe that security protocol design is part of cryptography, > I'm still of the opinion that we should more actively seek for external > expertise (e.g., by a competition or other appropriate methods). > --20cf301af77364fdb404f2ec1f31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 21, 2014 at 6:46 AM, Nikos Mavrogiannopoulos <nmav@redh= at.com> wrote:
On Wed, 2014-02-19 at 12:40 = -0800, Eric Rescorla wrote:
> Folks,
> I have prepared a new version of the TLS 1.3 flows document which
> should appear in the repository shortly and in the meantime can be
> found at:

Hello,
=A0I haven't read it yet to comment, but may I suggest something
procedural? I think it would be better to first agree on the list of
issues that TLS 1.3 will fix, and the list of features it will bring,
and the security requirements for this protocol; as the charter is very
high level for that.

I believe you have already done that as part of your presentation in
IETF 88, and there was some discussions on the list some time ago, but I don't know what was considered or discarded. It would be nice to have a=
draft that sets the desired requirements for TLS 1.3. (I'd volunteer maintain one if that is the issue)

Then it will be much more easy to check whether a proposed solution
satisfies the requirements, and input from other unrelated groups such
as CFRG would be more easy to get.

I= 9;m certainly sympathetic to this, but I don't think it's really pr= actical
to do detailed requirements first. That's always a ha= rd approach in
IETF, but it's especially hard here because there are a lot of tra= deoffs
to be made in terms of feature set and once you get beyond= the
trivial mandatory elements it's hard to make them withou= t
understanding the implications of opting to include or not include
any given features without understanding the effect they have on
the protocol in some detail. So, instead we've been doing this
as a cyclical design process, with the charter as the very high
<= div>level goals and then trying to work downward.

= After Vancouver, I had a lot of feedback to the effect that we
needed to work out the mechanisms more so that people could
make = an informed decision, so that's what I've tried to do here.
What I'm hoping we can do in London is to use these more worked
out mechanisms to reach informed decisions on a number of the
big requirements questions (static RSA, encrypted SNI, resumption,
<= div>etc.) and then we can work on a refined design that matches
those requirements.

-Ekr

=
regards,
Nikos

PS. As I believe that security protocol design is part of cryptography,
I'm still of the opinion that we should more actively seek for external=
expertise (e.g., by a competition or other appropriate methods).


--20cf301af77364fdb404f2ec1f31-- From nobody Sat Feb 22 08:39:02 2014 Return-Path: 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 7FD221A012E for ; Sat, 22 Feb 2014 08:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 ZxgmsoMrggx8 for ; Sat, 22 Feb 2014 08:38:59 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6699B1A0127 for ; Sat, 22 Feb 2014 08:38:59 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so4742339pbb.37 for ; Sat, 22 Feb 2014 08:38:55 -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=Qb2KN1mzYcPM0O1WYYY7mGJaOYy6QfxxRJNcEKYBVCI=; b=0M9AyfnZH/YMk93EBeS+7CgmE1OGUWvfX06KDwJUO9oJWdtgNke1ESGr79+nzVCqtF eZ9hhVOuMAFjP/XMS3C4TdaBqsll6iucF4D5bpEBt3jqZC+c+StS07NvQHd1VsfghVMt NzfllBa3orD3KP4jISLuTI7+FxW25saRl8tVg= 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=Qb2KN1mzYcPM0O1WYYY7mGJaOYy6QfxxRJNcEKYBVCI=; b=fdjc76vCcgc8iVtZTKlRDtu0JyilJ2QDExttxIMxMsIPvAx6aDOFzfDQecPAWjL6FG 4RryYc3GdXzIU8Cf+cRR3Sqq/5kNrFX7UKh+94MdDjhG9yLcp/Kh54vSJyUiQidwCpJw YtQZHFpSM1Gg9ebwjA1w5/yEUrdJYjaTI1Y28toKkhKLl0R9nr8M/zSP1grmtZuhfAEm xrCVe4SyF7WPrPb+q4JuOgFXtP9zHvKpyBIgMOKmvvpbNNGeYeV9O0Hk3k/ezVBm5MGB WLwYRJQ89UHTIL24P5VgUfXmEO+OG6CDhjAsRVSdrDIVPefLTeOVMkLJ99vNGIeS0fCb VNSg== X-Gm-Message-State: ALoCoQlUn+haWRDC7MuTaEDTl1ClYXLdya1UuGk2AU9da2x9ndUOBkNbYYaPM0zbnoYE26YLT+0i X-Received: by 10.68.96.99 with SMTP id dr3mr4323923pbb.40.1393087135025; Sat, 22 Feb 2014 08:38:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Sat, 22 Feb 2014 08:38:34 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Sat, 22 Feb 2014 11:38:34 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/59TRxnru1M6DfA2Hm8afpbwmlc4 Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 16:39:01 -0000 On 19 February 2014 15:40, Eric Rescorla wrote: > Folks, > > I have prepared a new version of the TLS 1.3 flows document which > should appear in the repository shortly and in the meantime can be > found at: > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt Thanks Eric! > I think the high order bit here is whether we want to have > encrypted SNI, because that dictates the position of the DHE > exchanges with respect to the server's messages. > > There are three options here: > > - Never > - Sometimes > - Always > > The flows in this draft take the position of "Always" which is > simple. "Never" is actually simpler. "Sometimes" is the most > complicated. There are two cases where we could shave off latency if > we were willing to disclose the SNI to passive attackers (and in cases > where the client and server have never talked before.) My sense of > recent discussion is that people feel it's important to have modes > that protect SNI I agree with this. > even if those are not the only modes. However, that > means that if we want to have non-SNI protecting modes, they are > additional complexity. But not so much with this. TLS has suffered from the multitude of options and the complexity choosing them provides. If at all possible, I lean away from accommodating more modes in favor of fewer much more secure, but perhaps slightly more complicated modes. > Thanks and comments welcome Random: --------------------------------------------- On replays " o Once the client and server have communicated once, they can establish an anti-replay token which can be used by the client to do a 0-RTT handshake with the server in future. This is shown in Figure 5." This confused me, because from this paragraph alone, it seemed like the server was providing the client with a nonce, storing it, and when the client used it again, the server forgot it and thus invalidated it. This does prevent replay - but it's not what the draft actually describes. I would try and rephrase this. "Generally all of them require the server to give the client some identifier which is later replayed to the server to help it recover state and detect replays." I don't think this is accurate wording either. It implies a session resumption. I would describe all of them as "the client remembers the server's preferred parameters (ciphersuites, groups, orbit), and may include something unique the server is expected to remember and use to reject replays". Two techniques I'm aware of for rejecting replays are relatively simple. The first is the same as snap start, I'll mention that it's used by mixmaster. The server stores identifiers, and discards any message that has the same identifier or a timestamp older than X hours; discarding state older than X hours as well. The other is used by mixminion, and does not require roughly synchronized clocks. The server stores the packet identifiers, and rotates its keys every X hours, discarding the state and the keys upon rotate. The server can detect replayed packets using it's state up until discard and after discard, cannot decrypt any replayed packets at all. This also removes the need for an orbit. On the topic of 0-RT and PFS. It adds complexity, but I can envision an inline key exchange happening alongside the first few application data packets. I think this is what you mention on line 458, but I'm not sure I understand why you say it's too expensive on a regular basis? The client is doing two DH operations, the server similarly does two. Normal PFS handshakes today require a RSA decryption and a DH. A resumption is much cheaper, yes. Is this what you meant or did I miss it? --------------------------------------------- RE: No SNI and the issue on line 657 - I suspect, but testing would need to be done, that nearly all major sites and most in general will serve a valid default certificate if SNI is omitted. I suspect this would not be a difficult test for someone with a SSL scanning setup to run. -tom From nobody Sat Feb 22 12:24:29 2014 Return-Path: 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 F39871A016C for ; Sat, 22 Feb 2014 12:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 7HdY2TqcpA-u for ; Sat, 22 Feb 2014 12:24:25 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3FE1A0133 for ; Sat, 22 Feb 2014 12:24:25 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id jx11so4425572veb.7 for ; Sat, 22 Feb 2014 12:24:20 -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=VXKz8jDmONKVr6jyHUOXW9lPSVqtgHQvMzXBZI5emRg=; b=YGLyKBU/sB8t4/s0GKYlorzwVt6xYNJU07761u8+2wHtqHwPkgRYdyxRHH6LpvPlhy 7lR6hZxK6vL77zQlFG8ZIjD5kqlNBiBPdkVf33ZV9GZADvfoC5VW8x23RHVMwf/JwQYE +USjX6q6GLkz1qE67WFALQS5c5n151zYtmwpLiaHBBHXh5vqBNxPR4LICXzZFbIDRXuc HenU1hRum4sI90dNhOhciTGIO7xjbPpGqHGSrOvheaLOvI/Gs7Qw1BCB3A9hQOlQu9od XpfrbJY8TWbDH0XTFlvV+5hpTPgPBYxzzMMBLXncvgZHPNOQ+HJDb2ApdZpsf+BV+32r K8cA== X-Gm-Message-State: ALoCoQmr08eAFsh4l8kfU2/21kx42Lb5t7w4RFMKZkWtvIPFU17F+HMUrMmREphiaU+PfFD3YwTM X-Received: by 10.220.188.70 with SMTP id cz6mr8507257vcb.59.1393100660494; Sat, 22 Feb 2014 12:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.198.12 with HTTP; Sat, 22 Feb 2014 12:23:35 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Sat, 22 Feb 2014 12:23:35 -0800 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=089e0129512604461d04f30486e7 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7Hug1tE8ojr0asE5UXpYfiJk8Q4 Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 20:24:28 -0000 --089e0129512604461d04f30486e7 Content-Type: text/plain; charset=ISO-8859-1 Tom, Thanks for your comments. On Sat, Feb 22, 2014 at 8:38 AM, Tom Ritter wrote: > On 19 February 2014 15:40, Eric Rescorla wrote: > > even if those are not the only modes. However, that > > means that if we want to have non-SNI protecting modes, they are > > additional complexity. > > But not so much with this. TLS has suffered from the multitude of > options and the complexity choosing them provides. If at all possible, > I lean away from accommodating more modes in favor of fewer much more > secure, but perhaps slightly more complicated modes. > Can you unpack this a little for me? Are you saying we should always protect SNI or something else? > Thanks and comments welcome > > Random: > > --------------------------------------------- > On replays > > " o Once the client and server have communicated once, they can > establish an anti-replay token which can be used by the client to > do a 0-RTT handshake with the server in future. This is shown in > Figure 5." > > This confused me, because from this paragraph alone, it seemed like > the server was providing the client with a nonce, storing it, and when > the client used it again, the server forgot it and thus invalidated > it. This does prevent replay - but it's not what the draft actually > describes. I would try and rephrase this. > > "Generally all of them require the server to give > the client some identifier which is later replayed to the server to > help it recover state and detect replays." > > I don't think this is accurate wording either. It implies a session > resumption. I would describe all of them as "the client remembers the > server's preferred parameters (ciphersuites, groups, orbit), and may > include something unique the server is expected to remember and use to > reject replays". > > Two techniques I'm aware of for rejecting replays are relatively simple. > The first is the same as snap start, I'll mention that it's used by > mixmaster. The server stores identifiers, and discards any message > that has the same identifier or a timestamp older than X hours; > discarding state older than X hours as well. > The other is used by mixminion, and does not require roughly > synchronized clocks. The server stores the packet identifiers, and > rotates its keys every X hours, discarding the state and the keys upon > rotate. The server can detect replayed packets using it's state up > until discard and after discard, cannot decrypt any replayed packets > at all. This also removes the need for an orbit. > Yeah, this section is badly written. I was trying to characterize all the possible options with a single description and ended up characterizing them all in a confusing way. Once we select a design, we can just remove all the generic text and in the meantime I will try to clean this up. > On the topic of 0-RT and PFS. It adds complexity, but I can envision > an inline key exchange happening alongside the first few application > data packets. I think this is what you mention on line 458, but I'm > not sure I understand why you say it's too expensive on a regular > basis? The client is doing two DH operations, the server similarly > does two. Normal PFS handshakes today require a RSA decryption and a > DH. A resumption is much cheaper, yes. Is this what you meant or did > I miss it? > This is old text. When I wrote it it seemed to me that two DHs was a big deal, but I'm less sure now. Still, it's a nonzero cost and the WG should probably discuss it before we just decide to impose the cost. RE: No SNI and the issue on line 657 - I suspect, but testing would > need to be done, that nearly all major sites and most in general will > serve a valid default certificate if SNI is omitted. I suspect this > would not be a difficult test for someone with a SSL scanning setup to > run Agreed. I'll see if I can get someone to do that... Thanks, -Ekr --089e0129512604461d04f30486e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Tom,

Thanks for your comments.


On Sat, Feb 22, = 2014 at 8:38 AM, Tom Ritter <tom@ritter.vg> wrote:
On 19 February 2014 15:40, E= ric Rescorla <ekr@rtfm.com> wrote= :
> even if those are not the only modes. However, that
> means that if we want to have non-SNI protecting modes, they are
> additional complexity.

But not so much with this. =A0TLS has suffered from the multitude of<= br> options and the complexity choosing them provides. If at all possible,
I lean away from accommodating more modes in favor of fewer much more
secure, but perhaps slightly more complicated modes.
<= br>
Can you unpack this a little for me? Are you saying we should= always
protect SNI or something else?



> Thanks and comments welcome

Random:

---------------------------------------------
On replays

" =A0 o Once the client and server have communicated once, they can =A0 =A0 =A0 establish an anti-replay token which can be used by the client = to
=A0 =A0 =A0 do a 0-RTT handshake with the server in future. =A0This is show= n in
=A0 =A0 =A0 Figure 5."

This confused me, because from this paragraph alone, it seemed like
the server was providing the client with a nonce, storing it, and when
the client used it again, the server forgot it and thus invalidated
it. =A0This does prevent replay - but it's not what the draft actually<= br> describes. =A0I would try and rephrase this.

"Generally all of them require the server to give
=A0 =A0the client some identifier which is later replayed to the server to<= br> =A0 =A0help it recover state and detect replays."

I don't think this is accurate wording either. =A0It implies a session<= br> resumption. I would describe all of them as "the client remembers the<= br> server's preferred parameters (ciphersuites, groups, orbit), and may include something unique the server is expected to remember and use to
reject replays".

Two techniques I'm aware of for rejecting replays are relatively simple= .
The first is the same as snap start, I'll mention that it's used by=
mixmaster. The server stores identifiers, and discards any message
that has the same identifier or a timestamp older than X hours;
discarding state older than X hours as well.
The other is used by mixminion, and does not require roughly
synchronized clocks. The server stores the packet identifiers, and
rotates its keys every X hours, discarding the state and the keys upon
rotate. The server can detect replayed packets using it's state up
until discard and after discard, cannot decrypt any replayed packets
at all. =A0This also removes the need for an orbit.
Yeah, this section is badly written. I was trying to character= ize all the
possible options with a single description and ended = up characterizing
them all in a confusing way. Once we select a design, we can just
remove all the generic text and in the meantime I will try to clean t= his
up.

=A0
On the topic of 0-RT and PFS. It adds complexity, but I can envision
an inline key exchange happening alongside the first few application
data packets. =A0I think this is what you mention on line 458, but I'm<= br> not sure I understand why you say it's too expensive on a regular
basis? The client is doing two DH operations, the server similarly
does two. Normal PFS handshakes today require a RSA decryption and a
DH. =A0A resumption is much cheaper, yes. =A0Is this what you meant or did<= br> I miss it?

This is old text. When I wro= te it it seemed to me that two DHs was a big
deal, but I'= m less sure now. Still, it's a nonzero cost and the WG should
probably discuss it before we just decide to impose the cost.

RE: No SNI and the issue on line= 657 - I suspect, but testing would
need to be done, that nearly all major sites and most in general will
serve a valid default certificate if SNI is omitted. =A0I suspect this
would not be a difficult test for someone with a SSL scanning setup to
run

Agreed. I'll see if I can get someo= ne to do that...

Thanks,
-Ekr
=
--089e0129512604461d04f30486e7-- From nobody Sat Feb 22 20:47:12 2014 Return-Path: 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 D0DA31A02E3 for ; Sat, 22 Feb 2014 20:47:09 -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 MyLkQyL4xrj3 for ; Sat, 22 Feb 2014 20:47:08 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB31A02D0 for ; Sat, 22 Feb 2014 20:47:08 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id up15so5058334pbc.8 for ; Sat, 22 Feb 2014 20:47:03 -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=qJ/gp4p9IxJx4qpPhr5aZm4k6/AwA2ZlBTmw6OEbBW8=; b=Mg1LYWyrUoepVbvoO5cpYjW/CWXR66gA7fXtv1toYlGTo4WadTKM1qHpuLJAWPTnNT nL0ss/fS46ZZG+weeYhlp4c+mQV0sODLij8eM3GpYlnQvKkvZvSBJGQWvXGEjbmlMyxp erujFMbuv/vuodoUr3neWN8WKpvVBwFrN1NuM= 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=qJ/gp4p9IxJx4qpPhr5aZm4k6/AwA2ZlBTmw6OEbBW8=; b=igO+Ke3beWwITO71YW5B4utEngthLAS+Z1fWpliZcMgkoMP1Y2g20+/ghOAF0L3K4+ TAAso2UWu7cIeGd9HjYMGHwNEJmPfiMTtqFa+xSLo8wbjQ+7VVNS2D9a3xFb8E36D11K okxkOi4aFPSfQEIpSUZ4VDUnOVBuvO3tEIPpZDN4FsL3hnQEtmJVEg/JSsQQWGJae/9B Roep4a7u6WgCDfFuFgswJtejjAvCjr4z3IPHfBj6gUpKGIMhjWu5PLuwL9HLlN8BKus/ I9nUKffVcTZ8r4MKeVKOVMl9bYbAxIvs1ZBFl20KlLRq8wG/o0NcZaWIloppxRl7FUM0 7I0Q== X-Gm-Message-State: ALoCoQm+RfGNqgb1v4ltaOTTFupMPDAA8S4qdB5Aj1ho2irFg5CBA5RGbSIveFuuIrDn42ECW4yf X-Received: by 10.68.228.138 with SMTP id si10mr6413019pbc.13.1393130822944; Sat, 22 Feb 2014 20:47:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.198.68 with HTTP; Sat, 22 Feb 2014 20:46:42 -0800 (PST) In-Reply-To: References: From: Tom Ritter Date: Sat, 22 Feb 2014 23:46:42 -0500 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7bOaOrLbpRPXxb2D0nmzA9TrhYc Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 04:47:10 -0000 On 22 February 2014 15:23, Eric Rescorla wrote: > On Sat, Feb 22, 2014 at 8:38 AM, Tom Ritter wrote: >> >> On 19 February 2014 15:40, Eric Rescorla wrote: >> > even if those are not the only modes. However, that >> > means that if we want to have non-SNI protecting modes, they are >> > additional complexity. >> >> But not so much with this. TLS has suffered from the multitude of >> options and the complexity choosing them provides. If at all possible, >> I lean away from accommodating more modes in favor of fewer much more >> secure, but perhaps slightly more complicated modes. > > > Can you unpack this a little for me? Are you saying we should always > protect SNI or something else? Yes, that we should always protect SNI. Having options to protect or not protect introduces complexity, even moreso in my mind over having a single more complicated option that always protects. Likewise, if major software chooses the option not to protect - that's a very high percentage where the protection is not used, and the higher security option will stand out as unusual. -tom From nobody Sun Feb 23 12:13:09 2014 Return-Path: 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 4F3321A06FD for ; Sun, 23 Feb 2014 12:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 7mEspAIVx-8v for ; Sun, 23 Feb 2014 12:13:06 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D20801A06F1 for ; Sun, 23 Feb 2014 12:13:05 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id v1so4401632yhn.12 for ; Sun, 23 Feb 2014 12: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=tJ6JQypzHS6u7eoV39uu2CoAVAV1NHP+q3EecCX5BW0=; b=CkDrx4/sBG00feCVNiN/+V+uUaZP26RbdYZDfOeFZxHrO4fpJH2fyeoBNNg68MYuw+ 22sY7mRbSlIVuYxVvJYk6cq6N0GiQ55QkAfL7n2EnRLTj6YzTsjAH/ZqurJpEquiH6Jz zS52wJW4+0COCcWoioIcgWhrX7wkI860B9mdqHfxPfzjqzYRzHh0pHEEi9mxhcIQ/PWx k4Spp7UojOAS+bk4XFdZ45mXiZ31ItgulQaWQtGZAPmLnbmR9WK2l2S/6F0pbPpwBsxk XE9NPNEzo/7P1mNIAi2dgRGDEt/BB5ocFSOpR2W8fd1iOpp+3+O2sbuAf6F6gtPjEVCW DINA== MIME-Version: 1.0 X-Received: by 10.236.137.14 with SMTP id x14mr25150523yhi.4.1393186385391; Sun, 23 Feb 2014 12:13:05 -0800 (PST) Received: by 10.170.92.85 with HTTP; Sun, 23 Feb 2014 12:13:05 -0800 (PST) In-Reply-To: References: Date: Sun, 23 Feb 2014 12:13:05 -0800 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FITDSJ5YKWnVJlOhozdIMBIzus8 Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 20:13:08 -0000 It seems to me the basic idea is to have the client encrypt its handshake after learning the server ECDH key, under the idea that this protects the client handshake. But this is wrong: the server's key isn't authenticated, so the handshake isn't actually being protected. This is why we need to know the server ECDH key for the 1RTT transaction. 90% of what people use TLS for can be handled by the following flow: C->S: g^x S->C: g^y, Sign(g^y, g^x), certificates C->S:everything encrypted with g^(xy). This is 1 round trip with no preknowledge, and has additional security. In particular for SNI we could get some additional information from DNS like "hi, I'm hosted with alice.com and bob.com, so if you see other certificates, close the connection." I don't see a way to do that with the current round trip proposals. As a sidenote: kick DH. ECDH has the DH speed record, and isn't going to give it up anytime soon. The IPR issues are long gone for something invented in 1985. Sincerely, Watson Ladd On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla wrote: > Folks, > > I have prepared a new version of the TLS 1.3 flows document which > should appear in the repository shortly and in the meantime can be > found at: > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt > > This version fleshes out a "recommended" set of flows: > > - 2-RTT where the client has no knowledge of the > server's capabilities. > > - 1-RTT where the client knows the server's semi-permanent > DHE/ECDHE key pair. > > - 0-RTT where the client and the server have shared anti-replay > state. > > There are still a number of open issues, but this should be clear > enough to see the direction I am trying to go. These flows are > structured so that the 1-RTT case is the base case with the 2-RTT and > 0-RTT versions being variants of the basic 1-RTT handshake. All > variants encrypt the client extensions that are not required > to define the cryptographic processing (e.g., SNI is encrypted > but curve negotiation is not). > > I think the high order bit here is whether we want to have > encrypted SNI, because that dictates the position of the DHE > exchanges with respect to the server's messages. > > There are three options here: > > - Never > - Sometimes > - Always > > The flows in this draft take the position of "Always" which is > simple. "Never" is actually simpler. "Sometimes" is the most > complicated. There are two cases where we could shave off latency if > we were willing to disclose the SNI to passive attackers (and in cases > where the client and server have never talked before.) My sense of > recent discussion is that people feel it's important to have modes > that protect SNI even if those are not the only modes. However, that > means that if we want to have non-SNI protecting modes, they are > additional complexity. Please let me know if I have misread the WG > here. > > > Here are some other things to keep in mind as you read the document. > > - Per my sense of the list, I have totally removed static RSA. If > people strongly object to that, please speak up and let me know. > > - There has been no real security analysis of this material other than > at the hand-wavy level. We clearly need that, but the first thing we > need is to be clear on whether this is approximately the right set of > points in the complexity/performance/privacy tradeoff space and then > make sure that the security properties are correct. So, if you see > something that looks wrong or even grievously wrong, don't panic (but > do point it out). > > > - There is no currently defined support for any kind of resumption. > We need to decide if resumption is still an important feature in light > of the trend towards more PFS and faster processors. I'm particularly > looking for input from the IoT/DICE guys here. > > - We will probably need to work out some of the details for DTLS, but > I wanted to get TLS nailed down first. > > - We also need to do some work on the symmetric crypto, e.g., to make > encrypt-then-MAC the default, perhaps to deprecate some ciphers, > compression, etc. I haven't forgotten that, but I want to deal with > the handshakes first. > > - As before, this incorporates ideas from a lot of different people > (and many times the same idea from different people). If you think > you should acknowledged in the text and/or acknowledgements > differently, please let me know. > > Thanks and comments welcome > -Ekr > > > > > > > > > > > > > _______________________________________________ > 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 nobody Sun Feb 23 12:34:25 2014 Return-Path: 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 027451A0709 for ; Sun, 23 Feb 2014 12:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.923 X-Spam-Level: * X-Spam-Status: No, score=1.923 tagged_above=-999 required=5 tests=[BAYES_80=2, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 y0IvP25qKt92 for ; Sun, 23 Feb 2014 12:34:22 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0608D1A0702 for ; Sun, 23 Feb 2014 12:34:21 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id cz12so3710858veb.25 for ; Sun, 23 Feb 2014 12:34:21 -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:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=PSEY97sCIc/W1v9UPkthRG9+7XsR0F/CIcMy4l2WezM=; b=Ns8ArqSs9SGWQkuDVZzlEDrH0ZlSXLMUIG+3UFZA+KrQ9P38i7tQa1XqoK78sHHqVH t8ZbiaooVH1VAgORozWyBPsAxigrdG+9w034bmR28H4kwLOQB3oIrvttIY332fqU1syK Q2tFEwHpDhWJzwI+hp2lVqwV/MibKZPyO5Zt0TmlVkQSzQw5tYVyDmj7G/5RkJQZvEZa LDt00/Cc/fCkbCKgCaBt71De3TwIDGi1pSuaeloemuVSsK2m5ny1Hc7RGXsy2qjd22kE mV+N20rTVZ8rjyKA3zMPK/1rLMAKX2Kj6zILMfi5/wPidMbhKnoRRhgovhQUBnLKpdv4 cfWw== X-Gm-Message-State: ALoCoQkHp9RcxOd6DmcLg3N0lu5V+mB43vhrejCZ6uUNYUk8aZms6lCzY/yCuVOBGPdjhW17rxOo X-Received: by 10.220.92.135 with SMTP id r7mr10508342vcm.11.1393187661459; Sun, 23 Feb 2014 12:34:21 -0800 (PST) MIME-Version: 1.0 Sender: hovav@eng.ucsd.edu Received: by 10.52.115.134 with HTTP; Sun, 23 Feb 2014 12:34:01 -0800 (PST) In-Reply-To: References: From: Hovav Shacham Date: Sun, 23 Feb 2014 12:34:01 -0800 X-Google-Sender-Auth: pfdmkwfJz9NzfFSUdljonEc2OLA Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b66f5fbaaca4604f318c71b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CA45Eq-W3m0dIBPnjE29MeVPPb4 Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 20:34:24 -0000 --047d7b66f5fbaaca4604f318c71b Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 23, 2014 at 12:13 PM, Watson Ladd wrote: C->S: g^x > S->C: g^y, Sign(g^y, g^x), certificates > C->S:everything encrypted with g^(xy). > > This is 1 round trip with no preknowledge, and has additional security. > Um, *which* certificates? All of them? And a signature under which key? All of them? -hs. --047d7b66f5fbaaca4604f318c71b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Feb 23, 2014 at 12:13 PM, Watson Ladd <watsonbladd@gmail.com&g= t; wrote:

C->S: g^x<= br> S->C: g^y, Sign(g^y, g^x), certificates
C->S:everything encrypted with g^(xy).

This is 1 round trip with no preknowledge, and has additional security.
=

Um, *which* certificates? =A0All of them? = =A0And a signature under which key? =A0All of them?

-hs.
--047d7b66f5fbaaca4604f318c71b-- From nobody Sun Feb 23 12:36:08 2014 Return-Path: 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 44B401A0702 for ; Sun, 23 Feb 2014 12:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nEwt7coeCy3N for ; Sun, 23 Feb 2014 12:36:05 -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 D00481A0165 for ; Sun, 23 Feb 2014 12:36:04 -0800 (PST) Received: by mail-yh0-f47.google.com with SMTP id c41so4374377yho.20 for ; Sun, 23 Feb 2014 12:36:04 -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=ZLexZbV4O+x2sEN5Uqv0+8TdEO42VFpa6UxezPFQzSQ=; b=AhllxiL5ZGH+lO94CoZE4PefiNuG5eZi+EzBi3vr3e/1L3SKh6ZLZafVPHlWnhC7zb FARLUL7tblgrE8/2xqUpFanPZzFi2XbNvZjzE8kayCmfhVpRFAi7pKVk3khJ9NshNYve J14ldo23OP25jSBZCzDbkG3TzjVuCfweKe+U6d3WS3RXBHU5MQoA87ByyWdsDhbzTfRP KDRipB3Yng9a0aTqM6j69hv+wq07jiyqkVR8XGj+dhDryGZXRD0+R8EODAoBDdyY/93A 6z6YF4/lJLHSDV0fPJaFRxhiw9aKLJY3N8sTfM3y1wXZ7KjyKsdEl9NETBuULQbzxcSa 73EQ== MIME-Version: 1.0 X-Received: by 10.236.142.198 with SMTP id i46mr26391022yhj.66.1393187764449; Sun, 23 Feb 2014 12:36:04 -0800 (PST) Received: by 10.170.92.85 with HTTP; Sun, 23 Feb 2014 12:36:04 -0800 (PST) In-Reply-To: References: Date: Sun, 23 Feb 2014 12:36:04 -0800 Message-ID: From: Watson Ladd To: Hovav Shacham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rmfMa1Qk9a-ghZ0ewEYRxGVNZHU Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 20:36:06 -0000 On Sun, Feb 23, 2014 at 12:34 PM, Hovav Shacham wrote: > On Sun, Feb 23, 2014 at 12:13 PM, Watson Ladd wrote: > >> C->S: g^x >> S->C: g^y, Sign(g^y, g^x), certificates >> C->S:everything encrypted with g^(xy). >> >> This is 1 round trip with no preknowledge, and has additional security. > > > Um, *which* certificates? All of them? And a signature under which key? Under a key then signed with the certificate. Even with SNI you should be able to pick an identity to respond with first. > All of them? > > -hs. > > _______________________________________________ > 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 nobody Sun Feb 23 13:27:27 2014 Return-Path: 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 7771A1A0733 for ; Sun, 23 Feb 2014 13:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 d137S5s3oApW for ; Sun, 23 Feb 2014 13:27:20 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id B8BBF1A0720 for ; Sun, 23 Feb 2014 13:27:19 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so2395776wiw.9 for ; Sun, 23 Feb 2014 13:27:19 -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=LcencJdK2ZtqGiFMDmge5W0OBRz5N34saUag/M8tzCM=; b=UoiH+CTzykcAcqLh41RCKx+Wzhllr/ZLCArxKM2DJI7UaVr84XeHRSCGtIAJuhSNq9 eGfNFYJDoJrmERdOHtKcInUo76z6fJURDJHylreTuZcFoxoJY3nyk9aqt45btRYKaayZ O9Yl4tudgQNb/W+IXAWlaJeLRjFcC1/gLxUjPTz3dgO6AGlw9kNn4cd2d6S+rItFwniE 8V0tBoank9PWq6oI6PaZpDbzBM0b/wzyZsZ3jQdX/ndjWgtu3hoINggvyJ7g8mAqNJyG 0ksLIB1cD0UKUVfEsTcvOnxe4aaErT5WduXkzuRjqwWcBrmZhiz3KWZQKcBOLzKwRkfY suxw== X-Gm-Message-State: ALoCoQmPc6z8ZBneoWZeTUbq7BKuKsedyxLwC1yPhlvTOiOGDG++DHCri2LMYo3Soe8uKkvl5RGF X-Received: by 10.180.164.174 with SMTP id yr14mr11530141wib.18.1393190838946; Sun, 23 Feb 2014 13:27:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.217.126.132 with HTTP; Sun, 23 Feb 2014 13:26:37 -0800 (PST) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 23 Feb 2014 13:26:37 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=00248c0d79140f712f04f31985f9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zb07PZrblsB37edw465PeeM3oNA Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 21:27:24 -0000 --00248c0d79140f712f04f31985f9 Content-Type: text/plain; charset=ISO-8859-1 Watson, Thanks for your comments. On Sun, Feb 23, 2014 at 12:13 PM, Watson Ladd wrote: > It seems to me the basic idea is to have the client encrypt its > handshake after learning the server ECDH key, under the idea that this > protects the client handshake. But this is wrong: the server's key > isn't authenticated, so the handshake isn't actually being protected. It's being protected from passive attack. In general, because the server has multiple certificates and uses SNI to select between them, we can't really authenticate the DH exchange until the client has supplied the SNI to indicate which certificate is to be used to authenticate the exchange. The idea here is to do an initial unauthenticated DH exchange to protect the SNI from passive attackers. Obviously this isn't perfect, but it's an improvement over the current state. Note that once the client and the server have spoken once and the client has a valid server key (via ServerParameters or the like), the client can use that key to form a secure connection and therefore protect the SNI from an active adversary (in theory). However (and this is a big however) if you won't fall back to the non-optimistic case, you have a permanent commitment for the server to use those parameters, and if it forgets those for some reason (or you have multiple servers without totally shared state), then you would have no way to recover, so it's a tradeoff. [There are similar tradeoffs with cert pinning.] See Section 8.1: http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-8.1 > This is why we need to know the server ECDH key for the 1RTT > transaction. > > 90% of what people use TLS for can be handled by the following flow: > C->S: g^x > S->C: g^y, Sign(g^y, g^x), certificates > C->S:everything encrypted with g^(xy). This is effectively what's in Appendix C: http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appendix-C I agree it's basically what you want if you don't care about protecting SNI. As I said in my note, I am assuming we want to try to protect SNI from passive attackers. BTW, I note that this still is counting on some degree of pre-knowledge, namely, of what groups are acceptable to the server, so there's still a possibility you will end up having to do a second round trip. > In particular for SNI we could get some additional information from > DNS like "hi, I'm hosted with alice.com and bob.com, so if you see > other certificates, close the connection." I don't see a way to do > that with the current round trip proposals. I'm not sure quite what you're proposing here, but there's been a bunch of work on using DNS and DNSSEC to indicate information about the server's certificates. See, for instance: http://tools.ietf.org/html/rfc6698 http://tools.ietf.org/html/draft-ietf-dane-srv-05 However, this work is mostly agnostic to the details of the handshake flow, so I'm not sure how it interacts with the question of the internals of TLS. > As a sidenote: kick DH. ECDH has the DH speed record, and isn't going > to give it up anytime soon. The IPR issues are long gone for something > invented in 1985. This seems like an orthogonal issue, so I suggest we discuss it separately. -Ekr On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla wrote: > > Folks, > > > > I have prepared a new version of the TLS 1.3 flows document which > > should appear in the repository shortly and in the meantime can be > > found at: > > > > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt > > > > This version fleshes out a "recommended" set of flows: > > > > - 2-RTT where the client has no knowledge of the > > server's capabilities. > > > > - 1-RTT where the client knows the server's semi-permanent > > DHE/ECDHE key pair. > > > > - 0-RTT where the client and the server have shared anti-replay > > state. > > > > There are still a number of open issues, but this should be clear > > enough to see the direction I am trying to go. These flows are > > structured so that the 1-RTT case is the base case with the 2-RTT and > > 0-RTT versions being variants of the basic 1-RTT handshake. All > > variants encrypt the client extensions that are not required > > to define the cryptographic processing (e.g., SNI is encrypted > > but curve negotiation is not). > > > > I think the high order bit here is whether we want to have > > encrypted SNI, because that dictates the position of the DHE > > exchanges with respect to the server's messages. > > > > There are three options here: > > > > - Never > > - Sometimes > > - Always > > > > The flows in this draft take the position of "Always" which is > > simple. "Never" is actually simpler. "Sometimes" is the most > > complicated. There are two cases where we could shave off latency if > > we were willing to disclose the SNI to passive attackers (and in cases > > where the client and server have never talked before.) My sense of > > recent discussion is that people feel it's important to have modes > > that protect SNI even if those are not the only modes. However, that > > means that if we want to have non-SNI protecting modes, they are > > additional complexity. Please let me know if I have misread the WG > > here. > > > > > > Here are some other things to keep in mind as you read the document. > > > > - Per my sense of the list, I have totally removed static RSA. If > > people strongly object to that, please speak up and let me know. > > > > - There has been no real security analysis of this material other than > > at the hand-wavy level. We clearly need that, but the first thing we > > need is to be clear on whether this is approximately the right set of > > points in the complexity/performance/privacy tradeoff space and then > > make sure that the security properties are correct. So, if you see > > something that looks wrong or even grievously wrong, don't panic (but > > do point it out). > > > > > > - There is no currently defined support for any kind of resumption. > > We need to decide if resumption is still an important feature in light > > of the trend towards more PFS and faster processors. I'm particularly > > looking for input from the IoT/DICE guys here. > > > > - We will probably need to work out some of the details for DTLS, but > > I wanted to get TLS nailed down first. > > > > - We also need to do some work on the symmetric crypto, e.g., to make > > encrypt-then-MAC the default, perhaps to deprecate some ciphers, > > compression, etc. I haven't forgotten that, but I want to deal with > > the handshakes first. > > > > - As before, this incorporates ideas from a lot of different people > > (and many times the same idea from different people). If you think > > you should acknowledged in the text and/or acknowledgements > > differently, please let me know. > > > > Thanks and comments welcome > > -Ekr > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 > --00248c0d79140f712f04f31985f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Watson,

Thanks for your comments.

On Sun, Feb 23, 2014 at 12:13 PM, Watson L= add <watsonbladd@gmail.com&= gt; wrote:
> It seems to me the basic id= ea is to have the client encrypt its
> handshake after learning the server ECDH ke= y, under the idea that this
> protects t= he client handshake. But this is wrong: the server's key
> isn't authenticated, so the handshake isn't actually being pro= tected.

It's being protected from passive attack.

In general, because the server has mul= tiple certificates and uses
SNI to select b= etween them, we can't really authenticate the DH
exchange until the client has supplied the SNI to indicate which
certificate is to be used to authenticate the exchang= e.
The idea here is to do an initial unauth= enticated DH exchange
to protect the SNI from passive attackers. Obvio= usly this isn't
perfect, but it's a= n improvement over the current state.

<= /div>
Note that once the cl= ient and the server have spoken once and the
client has a valid server key (via ServerParameters or the like), the
client can use that key to form a secure connect= ion and therefore
protect the SNI from an a= ctive adversary (in theory). =A0However (and
this is a big however) if you won't fall back to the non-optimistic
case, you have a permanent commitment for the se= rver to use those
parameters, and if it for= gets those for some reason (or you have
mul= tiple servers without totally shared state), then you would have no
way to recover, so it's a tradeoff. [There a= re similar tradeoffs with
cert pinning.]

Se= e Section 8.1:
http://tools.ietf.org/html/draft-resco= rla-tls13-new-flows-01#section-8.1

=

> This i= s why we need to know the server ECDH key for the 1RTT
> transaction.
>=A0
=
> 90% of what people use TLS for can be handled by the following flow:
> C->S: g^x
> S->C: g^y, Sign(g^y, g^x), certificates
> C->S:everything encrypted with g^(xy).

This is effectively what's in = Appendix C:

http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appen= dix-C

I agree it's basically what you want if you don't care about protec= ting SNI.
As I said in my note, I am assumi= ng we want to try to protect SNI from
passi= ve attackers.

BTW, I note= that this still is counting on some degree of
pre-knowledge, namely, of what groups are acceptable to the server, so<= /div>
there's still a possibility you will end up = having to do a second
round trip.
=A0

> In particular for SNI we could get some additional information from
> DNS like "hi, I'm hosted with <= a href=3D"http://alice.com">alice.com and bo= b.com, so if you see
> other certificates, close the connection.&q= uot; I don't see a way to do
> that = with the current round trip proposals.

=
I'm not sure quite what you're proposing= here, but there's been a
bunch of work= on using DNS and DNSSEC to indicate information
about the server's certificates. See, for instance:

http://tools.ietf.org/html/rfc6698
However, this work is mostly agnostic to= the details of the handshake
flow, so I'm not sure how it interacts with = the question of the internals
of TLS.
=


<= div class=3D"gmail_quote"> =A0
> As a sidenote: kick DH. ECDH has t= he DH speed record, and isn't going
>= ; to give it up anytime soon. The IPR issues are long gone for something
> invented in 1985.

This seems like an orthogonal i= ssue, so I suggest we discuss it separately.

-Ekr
=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Folks,
>
> I have prepared a new version of the TLS 1.3 flows document which
> should appear in the repository shortly and in the meantime can be
> found at:
>
> https://github.com/tlswg/tls13-spec/blob= /master/draft-rescorla-tls-1.3.txt
>
> This version fleshes out a "recommended" set of flows:
>
> - 2-RTT where the client has no knowledge of the
> =A0 server's capabilities.
>
> - 1-RTT where the client knows the server's semi-permanent
> =A0 DHE/ECDHE key pair.
>
> - 0-RTT where the client and the server have shared anti-replay
> =A0 state.
>
> There are still a number of open issues, but this should be clear
> enough to see the direction I am trying to go. These flows are
> structured so that the 1-RTT case is the base case with the 2-RTT and<= br> > 0-RTT versions being variants of the basic 1-RTT handshake. All
> variants encrypt the client extensions that are not required
> to define the cryptographic processing (e.g., SNI is encrypted
> but curve negotiation is not).
>
> I think the high order bit here is whether we want to have
> encrypted SNI, because that dictates the position of the DHE
> exchanges with respect to the server's messages.
>
> There are three options here:
>
> - Never
> - Sometimes
> - Always
>
> The flows in this draft take the position of "Always" which = is
> simple. "Never" is actually simpler. "Sometimes" i= s the most
> complicated. =A0There are two cases where we could shave off latency i= f
> we were willing to disclose the SNI to passive attackers (and in cases=
> where the client and server have never talked before.) My sense of
> recent discussion is that people feel it's important to have modes=
> that protect SNI even if those are not the only modes. However, that > means that if we want to have non-SNI protecting modes, they are
> additional complexity. Please let me know if I have misread the WG
> here.
>
>
> Here are some other things to keep in mind as you read the document. >
> - Per my sense of the list, I have totally removed static RSA. =A0If > people strongly object to that, please speak up and let me know.
>
> - There has been no real security analysis of this material other than=
> at the hand-wavy level. We clearly need that, but the first thing we > need is to be clear on whether this is approximately the right set of<= br> > points in the complexity/performance/privacy tradeoff space and then > make sure that the security properties are correct. So, if you see
> something that looks wrong or even grievously wrong, don't panic (= but
> do point it out).
>
>
> - There is no currently defined support for any kind of resumption. > We need to decide if resumption is still an important feature in light=
> of the trend towards more PFS and faster processors. =A0I'm partic= ularly
> looking for input from the IoT/DICE guys here.
>
> - We will probably need to work out some of the details for DTLS, but<= br> > I wanted to get TLS nailed down first.
>
> - We also need to do some work on the symmetric crypto, e.g., to make<= br> > encrypt-then-MAC the default, perhaps to deprecate some ciphers,
> compression, etc. I haven't forgotten that, but I want to deal wit= h
> the handshakes first.
>
> - As before, this incorporates ideas from a lot of different people > (and many times the same idea from different people). If you think
> you should acknowledged in the text and/or acknowledgements
> differently, please let me know.
>
> Thanks and comments welcome
> -Ekr
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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 =A0Liberty nor Safety."
-- Benjamin Franklin

--00248c0d79140f712f04f31985f9-- From nobody Sun Feb 23 16:41:16 2014 Return-Path: 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 81BA81A0787 for ; Sun, 23 Feb 2014 16:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 In7k9Sg_s-xd for ; Sun, 23 Feb 2014 16:41:11 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 894691A0203 for ; Sun, 23 Feb 2014 16:41:11 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so12628440yks.5 for ; Sun, 23 Feb 2014 16:41: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 :cc:content-type; bh=cOpR1SaDb+25F3jQ9enK8WFDrQ8f5/C5a4Y3xMcfWxo=; b=vqy0nnIz+87FopqIExHCvuyrCicqKB8Tta1CVa5OBfufsowVQUKWI1vp3vLelZwQsV 0hLCv9ExC40BGrQonu1SWI6DdRlEiWbA3rbfU/Q3qO4kDq37Kkhjo4w2TO7/iHYtQ5Aa IL6wkVuDY5umtxcM90Oq/hxU77LOclqo8oB8EnbtYZob/w/3nq67SXlt6SUrQ+JS7dF0 Z2oRbwFIJQYo4icAmj2x198PJPnjtqIv5ukQR8X/f9XAiuAZ/akqINcEYeila1dGGlo2 PdjRc+0W/vO3TYKaYMiy1z57G5iyfB9KpgQneKAME8LgRWMRqN98kd6TVFq+EB2Pa7vq Uw3A== MIME-Version: 1.0 X-Received: by 10.236.194.40 with SMTP id l28mr27503809yhn.63.1393202471057; Sun, 23 Feb 2014 16:41:11 -0800 (PST) Received: by 10.170.92.85 with HTTP; Sun, 23 Feb 2014 16:41:10 -0800 (PST) In-Reply-To: References: Date: Sun, 23 Feb 2014 16:41:10 -0800 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VgBPIhaDkh8Dis44SXlS9YTYNeU Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 00:41:14 -0000 On Sun, Feb 23, 2014 at 1:26 PM, Eric Rescorla wrote: > Watson, > > Thanks for your comments. > > On Sun, Feb 23, 2014 at 12:13 PM, Watson Ladd wrote: >> It seems to me the basic idea is to have the client encrypt its >> handshake after learning the server ECDH key, under the idea that this >> protects the client handshake. But this is wrong: the server's key >> isn't authenticated, so the handshake isn't actually being protected. > > It's being protected from passive attack. At a cost that would suffice to protect it from active attack, namely a DH computation on each side after looking up one end in the DNS. > > In general, because the server has multiple certificates and uses > SNI to select between them, we can't really authenticate the DH > exchange until the client has supplied the SNI to indicate which > certificate is to be used to authenticate the exchange. > The idea here is to do an initial unauthenticated DH exchange > to protect the SNI from passive attackers. Obviously this isn't > perfect, but it's an improvement over the current state. > > Note that once the client and the server have spoken once and the > client has a valid server key (via ServerParameters or the like), the > client can use that key to form a secure connection and therefore > protect the SNI from an active adversary (in theory). However (and > this is a big however) if you won't fall back to the non-optimistic > case, you have a permanent commitment for the server to use those > parameters, and if it forgets those for some reason (or you have > multiple servers without totally shared state), then you would have no > way to recover, so it's a tradeoff. [There are similar tradeoffs with > cert pinning.] > > See Section 8.1: > http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-8.1 > > >> This is why we need to know the server ECDH key for the 1RTT >> transaction. >> >> 90% of what people use TLS for can be handled by the following flow: >> C->S: g^x >> S->C: g^y, Sign(g^y, g^x), certificates >> C->S:everything encrypted with g^(xy). > > This is effectively what's in Appendix C: > > http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#appendix-C > > I agree it's basically what you want if you don't care about protecting SNI. > As I said in my note, I am assuming we want to try to protect SNI from > passive attackers. True, but my point was more that anything more than 128 bytes and certificates is cruft. Some of that is unavoidable given backwards necessity Some of that (SNI, ALPN) is of dubious necessity. But if we want to make a real improvement in security, we need to massively simplify the protocol and the code required to implement it. > > BTW, I note that this still is counting on some degree of > pre-knowledge, namely, of what groups are acceptable to the server, so > there's still a possibility you will end up having to do a second > round trip. Easy solution: limit the options so that there is one acceptable choice, with a means to negotiate a future one when that one acceptable choice falls. There is no reason to have a smorgasbord of possibilities here. > > >> In particular for SNI we could get some additional information from >> DNS like "hi, I'm hosted with alice.com and bob.com, so if you see >> other certificates, close the connection." I don't see a way to do >> that with the current round trip proposals. > > I'm not sure quite what you're proposing here, but there's been a > bunch of work on using DNS and DNSSEC to indicate information > about the server's certificates. See, for instance: I'm proposing that we secure the key we are sending SNI data to with some certificate, so that a future extension can impose restrictions on who gets to see that data. With your proposal of security only against passive attackers, this requires the server to keep the ECDH key it uses in memory and say something like "expect this ECDH key", which is much more restrictive operationally. > > http://tools.ietf.org/html/rfc6698 > http://tools.ietf.org/html/draft-ietf-dane-srv-05 > > However, this work is mostly agnostic to the details of the handshake > flow, so I'm not sure how it interacts with the question of the internals > of TLS. It's not agnostic. The kind of key I get from DNS can dramatically change what sorts of protocols are possible, and hence how the handshake works. Get an ECDH key and we can do some sort of MQV variant (AKE or SIGMA is probably the right thing here). Get out the SHA256 fingerprint of an RSA key and there is nothing you can do: the other side has to go first to tell you what the key is. > > > >> As a sidenote: kick DH. ECDH has the DH speed record, and isn't going >> to give it up anytime soon. The IPR issues are long gone for something >> invented in 1985. > > This seems like an orthogonal issue, so I suggest we discuss it separately. > > -Ekr Sincerely, Watson Ladd > > >> On Wed, Feb 19, 2014 at 12:40 PM, Eric Rescorla wrote: >> > Folks, >> > >> > I have prepared a new version of the TLS 1.3 flows document which >> > should appear in the repository shortly and in the meantime can be >> > found at: >> > >> > >> > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.txt >> > >> > This version fleshes out a "recommended" set of flows: >> > >> > - 2-RTT where the client has no knowledge of the >> > server's capabilities. >> > >> > - 1-RTT where the client knows the server's semi-permanent >> > DHE/ECDHE key pair. >> > >> > - 0-RTT where the client and the server have shared anti-replay >> > state. >> > >> > There are still a number of open issues, but this should be clear >> > enough to see the direction I am trying to go. These flows are >> > structured so that the 1-RTT case is the base case with the 2-RTT and >> > 0-RTT versions being variants of the basic 1-RTT handshake. All >> > variants encrypt the client extensions that are not required >> > to define the cryptographic processing (e.g., SNI is encrypted >> > but curve negotiation is not). >> > >> > I think the high order bit here is whether we want to have >> > encrypted SNI, because that dictates the position of the DHE >> > exchanges with respect to the server's messages. >> > >> > There are three options here: >> > >> > - Never >> > - Sometimes >> > - Always >> > >> > The flows in this draft take the position of "Always" which is >> > simple. "Never" is actually simpler. "Sometimes" is the most >> > complicated. There are two cases where we could shave off latency if >> > we were willing to disclose the SNI to passive attackers (and in cases >> > where the client and server have never talked before.) My sense of >> > recent discussion is that people feel it's important to have modes >> > that protect SNI even if those are not the only modes. However, that >> > means that if we want to have non-SNI protecting modes, they are >> > additional complexity. Please let me know if I have misread the WG >> > here. >> > >> > >> > Here are some other things to keep in mind as you read the document. >> > >> > - Per my sense of the list, I have totally removed static RSA. If >> > people strongly object to that, please speak up and let me know. >> > >> > - There has been no real security analysis of this material other than >> > at the hand-wavy level. We clearly need that, but the first thing we >> > need is to be clear on whether this is approximately the right set of >> > points in the complexity/performance/privacy tradeoff space and then >> > make sure that the security properties are correct. So, if you see >> > something that looks wrong or even grievously wrong, don't panic (but >> > do point it out). >> > >> > >> > - There is no currently defined support for any kind of resumption. >> > We need to decide if resumption is still an important feature in light >> > of the trend towards more PFS and faster processors. I'm particularly >> > looking for input from the IoT/DICE guys here. >> > >> > - We will probably need to work out some of the details for DTLS, but >> > I wanted to get TLS nailed down first. >> > >> > - We also need to do some work on the symmetric crypto, e.g., to make >> > encrypt-then-MAC the default, perhaps to deprecate some ciphers, >> > compression, etc. I haven't forgotten that, but I want to deal with >> > the handshakes first. >> > >> > - As before, this incorporates ideas from a lot of different people >> > (and many times the same idea from different people). If you think >> > you should acknowledged in the text and/or acknowledgements >> > differently, please let me know. >> > >> > Thanks and comments welcome >> > -Ekr >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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 > > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Feb 23 17:20:12 2014 Return-Path: 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 CFD5E1A0789 for ; Sun, 23 Feb 2014 17:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zX7B-AH0oKs0 for ; Sun, 23 Feb 2014 17:20:06 -0800 (PST) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id 909C91A0788 for ; Sun, 23 Feb 2014 17:20:06 -0800 (PST) Received: by mail-qg0-f43.google.com with SMTP id f51so13204787qge.2 for ; Sun, 23 Feb 2014 17:20:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=a4QIWnxz323d5QlpkDvr8cC2KmXjzF70EQpdat/ORLg=; b=UiQ25idg2ZxyMwqEj1FTB7KRPwU3F/naYfT/1U2XnSsGkLIXEcx8DXbwW7PX3XgTKs dop+0SjY/B9MRSMNkUkTsBl3GkFK/UmSvrTtMB8/ca4G2TkRaf1vwVru3PPY9PAdW8OM UVCGSLn7uVImwFMEBcxbhV1gheEuQLz+ODQ8g2Hpp/Dz++6FF45IO0gH6A+0buvGUbRt vxxHS4MtYeUQLVgzUcqxb/frBZwOIj2+IzeWAmlQ5++yS/GmMrDic7vDg+zUK2Oz9omk yMy+xfAAMEEuRDFcKoNM0lDpHJUiA9nzCoinwQ7eQVyzMG2i5q0YrZLzlTY/n9DEoWMr smIw== X-Gm-Message-State: ALoCoQmlzMPp06bangJrI9A5HBcIjN9s03nRBUqIeUqmjE92DDreZOQwIvmls29ozoxdrqEGmWr3 X-Received: by 10.224.151.147 with SMTP id c19mr26158699qaw.86.1393204805996; Sun, 23 Feb 2014 17:20:05 -0800 (PST) Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id d15sm45066811qaq.4.2014.02.23.17.20.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2014 17:20:05 -0800 (PST) Received: from [10.0.1.4] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id B003DAC28B5; Sun, 23 Feb 2014 20:20:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Stephen Checkoway In-Reply-To: Date: Sun, 23 Feb 2014 20:20:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4156173A-B7FC-4841-8733-D39009A88BDF@pahtak.org> References: To: Watson Ladd X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TTbpCAS8_QXZHfrvUDO2xYxAkUs Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 01:20:09 -0000 Hi Watson, On Feb 23, 2014, at 7:41 PM, Watson Ladd wrote: > Easy solution: limit the options so that there is one acceptable > choice, As much as this appeals to me, this route seems unlikely to be adopted = since what's acceptable to you or me is probably not acceptable to = everyone. > with a means to negotiate a future one when that one > acceptable choice falls. It seems likely that this will because the default method and I'm not = sure how this is simpler than offering options initially. > I'm proposing that we secure the key we are sending SNI data to with > some certificate I'm not sure I'm following you here. As I understand it, the whole issue = is that with SNI the server doesn't know which cert to use until after = it sees the SNI. Are you proposing that there is some master cert which = secures the key used for SNI data and then a separate cert for the given = server name? --=20 Stephen Checkoway From nobody Sun Feb 23 17:31:54 2014 Return-Path: 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 6E47A1A079D for ; Sun, 23 Feb 2014 17:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 JfoJ-LJQ1uT5 for ; Sun, 23 Feb 2014 17:31:51 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE21A078C for ; Sun, 23 Feb 2014 17:31:50 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id f73so4617415yha.28 for ; Sun, 23 Feb 2014 17:31:50 -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=XSU6bzQOoKt9BbNcs6LpGnyoR2cznP6rFcGsNcJmhUY=; b=mz3Fyq57lms0zOvMSQi95fiUoWfZKEGE6MEW/2Q6n12Sv6mUUaH1lOahfVn/xmaDF9 /+BtV5TUzFLH8rSr4FEBv9of5BsisqFxP0c2yCoUHo4WADXD8kWu/RsqpzSVmJMWFnJK kEujEuGm05Hc6qL1iUAkHVwKIFQXG55hpvJJWMa/vzVH3iDveNoS7W4vsL4JwUbwJt2S NOEp5ft6D99XqL349lFLfou4VPp1c6XpqSA/MEQK7REKQAG9dXFKRmfTyQamqtTtMjtF waiFdWtYSAndb9xdCrXIe332us8hYaebhkj9BCjT/q55JoCqjk1IgVGbPjTSb9vthC7j QPGw== MIME-Version: 1.0 X-Received: by 10.236.127.39 with SMTP id c27mr27212150yhi.120.1393205510292; Sun, 23 Feb 2014 17:31:50 -0800 (PST) Received: by 10.170.92.85 with HTTP; Sun, 23 Feb 2014 17:31:50 -0800 (PST) In-Reply-To: <4156173A-B7FC-4841-8733-D39009A88BDF@pahtak.org> References: <4156173A-B7FC-4841-8733-D39009A88BDF@pahtak.org> Date: Sun, 23 Feb 2014 17:31:50 -0800 Message-ID: From: Watson Ladd To: Stephen Checkoway Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e9dZEfqFh_RBVNxpfpV2tIM_GLY Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 01:31:52 -0000 On Sun, Feb 23, 2014 at 5:20 PM, Stephen Checkoway wrote: > Hi Watson, > > On Feb 23, 2014, at 7:41 PM, Watson Ladd wrote: > >> Easy solution: limit the options so that there is one acceptable >> choice, > > As much as this appeals to me, this route seems unlikely to be adopted si= nce what's acceptable to you or me is probably not acceptable to everyone. > >> with a means to negotiate a future one when that one >> acceptable choice falls. > > It seems likely that this will because the default method and I'm not sur= e how this is simpler than offering options initially. Does anyone have a problem with P256 or Curve25519 with some fallback option TBD? > >> I'm proposing that we secure the key we are sending SNI data to with >> some certificate > > I'm not sure I'm following you here. As I understand it, the whole issue = is that with SNI the server doesn't know which cert to use until after it s= ees the SNI. Are you proposing that there is some master cert which secures= the key used for SNI data and then a separate cert for the given server na= me? In the SNI case the server has a great number of certificates to pick from, and doesn't know which one to use. My suggestion is that they use on initially, and if informed they messed up, use that one. Sincerely, Watson Ladd > > -- > Stephen Checkoway > > > > > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Mon Feb 24 05:01:26 2014 Return-Path: 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 12CCF1A0862 for ; Mon, 24 Feb 2014 05:01:25 -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 1LVcXy_zl5tL for ; Mon, 24 Feb 2014 05:01:23 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 061F51A0457 for ; Mon, 24 Feb 2014 05:01:22 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so5938992qab.23 for ; Mon, 24 Feb 2014 05:01:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IpChpyhI1rJnVBUbXkxVXQnLkdq3qJ5Z0URNJO7y04Y=; b=JXTvI4njrhQ6h2Q7A71FQm6TbsWEZC4x7jiRvA+j+y9m4kvHzQwaAOJF1v3IFUIBi4 pQfGrJ/q81RN3MmKG1GG9Vx60R2NnsgXTvjhVwG9IjcaQD6MT9csgcnf9k/DEdw+A97E w7Vq1LldzF5ik3IZhM6lmqqPVteVBFmUU0PE3NQWU0yLO0biur36CYQI5r9f4W16y5To tv4Iq8DlfOkqH8GCAEl5Bue5LZNoTeaDQdPBkK5a+p1jRVK/5Fjr38ZbnoYo1XLwv/wf xvhIZzNKYlFiveESf+S2jhitVb5ParheCc+/iIKjUBnya2joxrJoIlHqtz5sn8M0h+Yt oayw== X-Gm-Message-State: ALoCoQlc/SR03Mf8M0scO2ZSLaJH5Pipmasg1dnL3bgtrfS0iAkUWa3rivBrDbTe8l1pCvk3MRMK X-Received: by 10.140.25.142 with SMTP id 14mr27735121qgt.83.1393246881730; Mon, 24 Feb 2014 05:01:21 -0800 (PST) Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id 110sm25253094qgv.19.2014.02.24.05.01.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2014 05:01:20 -0800 (PST) Received: from [10.0.1.4] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 18FEDAC28E5; Mon, 24 Feb 2014 08:01:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Stephen Checkoway In-Reply-To: Date: Mon, 24 Feb 2014 08:01:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <06D16886-A6B7-44D3-B8AC-FD4A46CE467C@pahtak.org> References: <4156173A-B7FC-4841-8733-D39009A88BDF@pahtak.org> To: Watson Ladd X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JkrxIIjqoo2sNvN0KCuuIudCYFk Cc: "tls@ietf.org" Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 13:01:25 -0000 On Feb 23, 2014, at 8:31 PM, Watson Ladd wrote: > On Sun, Feb 23, 2014 at 5:20 PM, Stephen Checkoway = wrote: >> Hi Watson, >>=20 >> On Feb 23, 2014, at 7:41 PM, Watson Ladd = wrote: >>=20 >>> Easy solution: limit the options so that there is one acceptable >>> choice, >>=20 >> As much as this appeals to me, this route seems unlikely to be = adopted since what's acceptable to you or me is probably not acceptable = to everyone. >>=20 >>> with a means to negotiate a future one when that one >>> acceptable choice falls. >>=20 >> It seems likely that this will because the default method and I'm not = sure how this is simpler than offering options initially. >=20 > Does anyone have a problem with P256 or Curve25519 with some fallback > option TBD? I don't have a problem with either but, again, that doesn't say anything = about everyone else. >>> I'm proposing that we secure the key we are sending SNI data to with >>> some certificate >>=20 >> I'm not sure I'm following you here. As I understand it, the whole = issue is that with SNI the server doesn't know which cert to use until = after it sees the SNI. Are you proposing that there is some master cert = which secures the key used for SNI data and then a separate cert for the = given server name? >=20 > In the SNI case the server has a great number of certificates to pick > from, and doesn't know which one to use. My suggestion is that they > use on initially, and if informed they messed up, use that one. So say the server picks the wrong one. This reveals a different server = name to the client. This would seem to be an issue if the various names = the server is willing to use are private for some reason. With the wrong = one chosen, the client has three options: (1) send the SNI in the clear = to the server; (2) use the unauthenticated server parameters to = establish a key and send the SNI encrypted under that key; or (3) say = "nope, pick a different cert and try again." (1) is essentially what we have today but with more overhead; (2) is essentially the proposed mechanism except that it has more = overhead and exposes the server name of the incorrectly chosen cert; and (3) could take a significant number of round trips to get the right cert = and also enables a client to enumerate all supported server names. None of these seem better so I've probably misunderstood what you're = actually proposing. --=20 Stephen Checkoway From nobody Thu Feb 27 09:48:25 2014 Return-Path: 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 2C3C41A03A7 for ; Thu, 27 Feb 2014 09:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 seTEV-QkbjW0 for ; Thu, 27 Feb 2014 09:48:22 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D348F1A0445 for ; Thu, 27 Feb 2014 09:48:21 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id db12so263374veb.38 for ; Thu, 27 Feb 2014 09:48:19 -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=aVdylK3eBS4EIeIc7kzve6+wnyTfTe+rLXegWKFjshk=; b=WQg283a2wiY0LGodoZB1XhvWSDqXGrGVQYNYFwjUE0FJuWz66oUIC0oN+xv9/F8wQX wZxGMZbm75xp4/BTNQ3+QgvOCv2YEauJ++WQk8l0p3X6+k3V+TI+0DUUyEb3bkh44OY+ GgtNd/kwL0WUVUwttnivNZlKNSNqxpikGLx4LMRXj+yhS3kMRw9yy+YBOPelrLBfIznW G+JmjGqwyvtBraOgRRecXAAKOdeboAgbVR1iorBYWRaHM3d7G9VJcVHghDYlYMY6RA2I DO7wIu/4DpJIUZprcP9yXF0LLDEqjkGvfKMfwI5LqfDasUgZWhP4FJlbWX0VV/2Krzz9 oBKw== 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=aVdylK3eBS4EIeIc7kzve6+wnyTfTe+rLXegWKFjshk=; b=UAo4+W3RV2ejy0tEZFFH9xw4l7ToK6lRZXTGwwlGYXdQ0aHQYcrEa+4w9d2O9AmXPn ns4LOc1Pj/EmH+mNplpk7dS828YP5MCHoN5rKmj6nw3VFer5hzaVm8Noo+7rJ1KzYU26 kf+CWf8/ATPh98y/gC+IEu6XdRccZWWHWASiurlQKwyIr/Zwjc+FVOXPY8gAoFmw5Xgy fYw/TMgrnzLK8+zCrA1/jOV0S131put2p6yKYB6ZReOBAsr9RuxAGSpjiSZTvJ0ei/zb ivae8vtEQgeMb/NBE10gX6SfzadNI6SdKolJUoGsggRPtSoygiybgz88TL58Un9gFiIv cqMg== X-Gm-Message-State: ALoCoQlBrm1Zvkql0eVnzu6KaOs+Cx/93Ycb6ycZY2cOfNagcA6Q883eioiftObn0QbXMtUtNf4Istns4ahpRQK8xV4HsyBq985OunSF8lRiEprgOhz2G0dN/yZkS04GHroWKhOPiihIWW5KX55qogcR9Pee5iYTXRRZRhIbq8Ku2mz0/PgK+VEConP0q5DcedvVMLeRWXTy X-Received: by 10.52.122.14 with SMTP id lo14mr1810686vdb.38.1393523299661; Thu, 27 Feb 2014 09:48:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.104.37 with HTTP; Thu, 27 Feb 2014 09:47:59 -0800 (PST) From: Adam Langley Date: Thu, 27 Feb 2014 12:47:59 -0500 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dCIIbgHZs-MEpE3G6SEI0e6NDBc Subject: [TLS] Viability of fallback SCSV and padding drafts. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:48:24 -0000 Chrome 33 went stable[1] on the 20th and contained implementations of both the fallback SCSV[2] and padding drafts[3]. The fallback SCSV is also enabled for Google properties. Of the two, padding was significantly more trouble. In order to flush out problems, Chrome 33 pads all ClientHellos to 512 bytes, whether they would have been smaller than 256 bytes or not. One, Windows based, "anti-virus" product broke because it made assumptions about the maximum size of a ClientHello. One network middleware product broke for the same reasons. Both have now been updated. (Thankfully, the design of the network middleware was such that it could be updated for all users.) A second, "anti-virus" product also broke, Kaspersky, and it's unclear which of the two changes caused the problem. Kaspersky has a history of such issues but the TLS MITM mode is disabled by default and this has not been a major source of user feedback. It's possible that smaller breakages have also occurred but I've seen no evidence of that yet. We continue to follow up on user reports in case there's something that got missed. We're going to change Chrome 33 to only pad ClientHellos when needed, but that's the only change scheduled so far. Otherwise both changes are holding steady and appear viable. Cheers AGL [1] http://googlechromereleases.blogspot.com/2014/02/stable-channel-update_20.html [2] https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01 [3] https://tools.ietf.org/html/draft-agl-tls-padding-03 From nobody Thu Feb 27 10:20:02 2014 Return-Path: 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 EEFF81A0234 for ; Thu, 27 Feb 2014 10:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.589 X-Spam-Level: * X-Spam-Status: No, score=1.589 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] 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 dTbUWsG1Daye for ; Thu, 27 Feb 2014 10:19:54 -0800 (PST) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by ietfa.amsl.com (Postfix) with ESMTP id B37E21A0163 for ; Thu, 27 Feb 2014 10:19:54 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:59222 helo=[192.168.7.9]) by relay16.mail.eu.clara.net (relay.clara.net [81.171.239.36]:10465) with esmtpa (authdaemon_plain:drh) id 1WJ5Ym-0002rG-JM for tls@ietf.org (return-path ); Thu, 27 Feb 2014 18:19:52 +0000 Message-ID: <530F81C5.1060104@drh-consultancy.co.uk> Date: Thu, 27 Feb 2014 18:19:49 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZET3ICFEh3_4GeY0TV4BUvPlC4M Subject: Re: [TLS] Viability of fallback SCSV and padding drafts. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:19:57 -0000 On 27/02/2014 17:47, Adam Langley wrote: > > It's possible that smaller breakages have also occurred but I've seen > no evidence of that yet. We continue to follow up on user reports in > case there's something that got missed. > > We're going to change Chrome 33 to only pad ClientHellos when needed, > but that's the only change scheduled so far. Otherwise both changes > are holding steady and appear viable. > That's good to know. I'm hoping that once there is an official designation for the padding extension (any news on when that might be?) it can be enabled by default in OpenSSL, at present it needs a compilation option. It could then appear in 1.0.2 when it is officially released and 1.0.1 releases. 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 nobody Fri Feb 28 04:22:32 2014 Return-Path: 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 2CF001A07DD for ; Fri, 28 Feb 2014 04:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.547] 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 mZ92K0Ju3EMC for ; Fri, 28 Feb 2014 04:22:19 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B08B01A07E0 for ; Fri, 28 Feb 2014 04:20:50 -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=1393590050; x=1425126050; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gtbkfjieSKPUApHa4iWaH/ljzIgYhnNa3f3X+jFbZYE=; b=e8E9GDOxB0Nies6TZkoAMXjFZHYN9p+Hpy1aILXZiT3wv/yeFmeY9xSi ao0smEmLnu/DmIHVhQS+O8gr+QYCWvDlpG6p7zvDoZeP/QRfw6cETTGxi 9z6bLp5bBSiQiX7BqZK3SWDqaHdON8TMGx/i2wZkqFNLhJBknLCZEf6yb s=; X-IronPort-AV: E=Sophos;i="4.97,561,1389697200"; d="scan'208";a="236508111" 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 mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 01 Mar 2014 01:20:48 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.53]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Sat, 1 Mar 2014 01:20:47 +1300 From: Peter Gutmann To: "" , "ietf-ssh@NetBSD.org" Thread-Topic: I can has SHA-1 hashes for RFC 2409/3526 MODP groups? Thread-Index: Ac80f4KYhJZr8H2uQwmODWcaii6Djw== Date: Fri, 28 Feb 2014 12:20:47 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73723848D4@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 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3RW-IUgVaNNwc_7Vg3kCFkjOj6A Subject: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 12:22:26 -0000 I can has SHA-1 hashes for RFC 2409/3526 MODP groups?=0A= =0A= The MODP groups for DH specified in RFC 2409 and 3526 seem to be widely use= d=0A= in things like SSH and SSL/TLS, however unlike the RFC 5114 groups there's = no=0A= subgroup given and so no way to verify that the prime hasn't been corrupted= in=0A= some way (the generator is easy, it's always 2). OTOH the RFC 5114 groups= =0A= have stupid generators so I don't know why anyone would use them.=0A= =0A= In any case I'd like to have a means of verifying the validity of the data = for=0A= the RFC 2409/3526 primes as stored in memory, but if I generate my own SHA-= 1=0A= hashes then there's the risk that I'm verifying flawed data. Does anyone h= ave=0A= SHA-1 hash values for the RFC 2409/3526 primes, i.e. the 1024/1536/2048/etc= -=0A= bit values in the two RFCs? The values I've got are:=0A= =0A= RFC 2409, 1024-bit prime: c0 33 bd 43 51 fb a3 73 25 45 ea 2e 01 6d 52 b0 .= ..=0A= RFC 3526, 1536-bit prime: 49 ec ab a9 72 7a 1a f0 63 60 82 c4 67 48 5a 1a .= ..=0A= RFC 3526, 2048-bit prime: b9 5c 79 9a a5 dd 38 8c 6d f5 e7 23 98 cb 9d 7d .= ..=0A= RFC 3526, 3072-bit prime: 94 1a 04 77 38 fe 55 33 33 69 e2 b3 86 b6 d6 18 .= ..=0A= =0A= Peter.= From nobody Fri Feb 28 13:23:02 2014 Return-Path: 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 90FF71A01F6 for ; Fri, 28 Feb 2014 13:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-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 hXlSeq0t_xY0 for ; Fri, 28 Feb 2014 13:22:55 -0800 (PST) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8D1A028A for ; Fri, 28 Feb 2014 13:22:55 -0800 (PST) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 607CA33D22C; Fri, 28 Feb 2014 21:22:53 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73723848D4@uxcn10-6.UoA.auckland.ac.nz> From: Geoffrey Keating Date: 28 Feb 2014 13:22:53 -0800 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73723848D4@uxcn10-6.UoA.auckland.ac.nz> Message-ID: Lines: 30 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1E3oh8lEmQRfvCzvzYrRoHVWI-I Cc: "ietf-ssh@NetBSD.org" , "" Subject: Re: [TLS] I can has SHA-1 hashes for RFC 2409/3526 MODP groups? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 21:22:57 -0000 Peter Gutmann writes: > I can has SHA-1 hashes for RFC 2409/3526 MODP groups? > > The MODP groups for DH specified in RFC 2409 and 3526 seem to be widely used > in things like SSH and SSL/TLS, however unlike the RFC 5114 groups there's no > subgroup given and so no way to verify that the prime hasn't been corrupted in > some way (the generator is easy, it's always 2). OTOH the RFC 5114 groups > have stupid generators so I don't know why anyone would use them. > > In any case I'd like to have a means of verifying the validity of the data for > the RFC 2409/3526 primes as stored in memory, but if I generate my own SHA-1 > hashes then there's the risk that I'm verifying flawed data. Does anyone have > SHA-1 hash values for the RFC 2409/3526 primes, i.e. the 1024/1536/2048/etc- > bit values in the two RFCs? The values I've got are: > > RFC 2409, 1024-bit prime: c0 33 bd 43 51 fb a3 73 25 45 ea 2e 01 6d 52 b0 ... > RFC 3526, 1536-bit prime: 49 ec ab a9 72 7a 1a f0 63 60 82 c4 67 48 5a 1a ... > RFC 3526, 2048-bit prime: b9 5c 79 9a a5 dd 38 8c 6d f5 e7 23 98 cb 9d 7d ... > RFC 3526, 3072-bit prime: 94 1a 04 77 38 fe 55 33 33 69 e2 b3 86 b6 d6 18 ... I'd encourage you to do the derivation again: compute 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } and verify that it's prime. I don't think any special security measures were taken during the creation of RFC 3526, you'd think by now someone would have noticed if the 'primes' weren't prime or didn't match the claimed polynomial, but if everyone thinks someone else has checked...