From nick.lewis@usa.g4s.com Mon Jul 1 02:03:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9821F9C2B for ; Mon, 1 Jul 2013 02:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrOszs9wJA2K for ; Mon, 1 Jul 2013 02:03:03 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) by ietfa.amsl.com (Postfix) with ESMTP id 31D6D21F91BF for ; Mon, 1 Jul 2013 02:03:01 -0700 (PDT) Received: from [85.158.137.19:15876] by server-9.bemta-3.messagelabs.com id DA/94-31358-2C541D15; Mon, 01 Jul 2013 09:02:58 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-13.tower-39.messagelabs.com!1372669378!3156364!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29817 invoked from network); 1 Jul 2013 09:02:58 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-13.tower-39.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2013 09:02:58 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Mon, 1 Jul 2013 10:02:57 +0100 From: "Lewis, Nick" To: "'tls@ietf.org'" Date: Mon, 1 Jul 2013 10:02:57 +0100 Thread-Topic: Re: [TLS] Requesting feedback on TACK draft Thread-Index: Ac52Oe/4tq53Hc7oSVKyVV+P1lq9zw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54175GBTWK10E001Te_" MIME-Version: 1.0 Subject: Re: [TLS] Requesting feedback on TACK draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 09:03:10 -0000 --_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54175GBTWK10E001Te_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >While people are looking at that, there's also the encrypt-then-MAC draft, >http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-03.= txt, >which has been stable for about as long, has already been deployed by seve= ral vendors, >and for which TLS extension 0x10 has been de facto claimed, >so it'd be good to get this published to legitimise the use >(and to document what's already being deployed in production). As I recall there were three proposals for resolving the padding bug in TLS 1. An extension for Pad First (i.e. padding before an otherwise stand= ard TLS mode of operation) 2. An extension for Encrypt-then-MAC (i.e. this draft) 3. The replacement of each existing cipher suite with an equivalent A= EAD one Was any consensus achieved as to the best approach? -- Nick ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. --_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54175GBTWK10E001Te_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>While people are looking at that, there's als= o the encrypt-then-MAC draft,

>http://www.ietf.org/internet-d= rafts/draft-gutmann-tls-encrypt-then-mac-03.txt,

>which has been stable for about as long, has = already been deployed by several vendors,

>and for which TLS extension 0x10 has been de = facto claimed,

>so it'd be good to get this published to legi= timise the use

>(and to document what's already being deploye= d in production). 

 

As I recall there were three proposals for resolving= the padding bug in TLS

 

1.     &= nbsp; An extension for Pad First (i.e. padding before an = otherwise standard TLS mode of operation)

2.     &= nbsp; An extension for Encrypt-then-MAC (i.e. this draft)=

3.     &= nbsp; The replacement of each existing cipher suite with = an equivalent AEAD one

 

Was any consensus achieved as to the best approach?<= o:p>

 

-- Nick

 


The details of this company = are as follows:
G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38.

This communication may contain information which is confidential, personal = and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
 --_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54175GBTWK10E001Te_-- From Andrei.Popov@microsoft.com Mon Jul 1 16:31:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240B811E830C for ; Mon, 1 Jul 2013 16:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwF2iJVhgjrw for ; Mon, 1 Jul 2013 16:31:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA0211E82E2 for ; Mon, 1 Jul 2013 16:31:16 -0700 (PDT) Received: from BL2FFO11FD018.protection.gbl (10.173.161.202) by BL2FFO11HUB030.protection.gbl (10.173.161.54) with Microsoft SMTP Server (TLS) id 15.0.717.3; Mon, 1 Jul 2013 23:31:07 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD018.mail.protection.outlook.com (10.173.161.36) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Mon, 1 Jul 2013 23:31:07 +0000 Received: from db9outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 1 Jul 2013 23:30:33 +0000 Received: from mail220-db9-R.bigfish.com (10.174.16.240) by DB9EHSOBE034.bigfish.com (10.174.14.97) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Jul 2013 23:30:31 +0000 Received: from mail220-db9 (localhost [127.0.0.1]) by mail220-db9-R.bigfish.com (Postfix) with ESMTP id 9C396800EA for ; Mon, 1 Jul 2013 23:30:31 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zz9371I148cI542I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: softfail (mail220-db9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(52604005)(13464003)(164054003)(189002)(199002)(377454003)(74366001)(69226001)(79102001)(4396001)(76482001)(77982001)(80022001)(47736001)(65816001)(76796001)(50986001)(31966008)(63696002)(53806001)(47976001)(59766001)(49866001)(56776001)(74876001)(56816003)(74662001)(77096001)(81542001)(76576001)(51856001)(46102001)(74316001)(76786001)(54316002)(83072001)(33646001)(74502001)(47446002)(54356001)(81342001)(74706001)(16406001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB196; H:BL2PR03MB194.namprd03.prod.outlook.com; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail220-db9 (localhost.localdomain [127.0.0.1]) by mail220-db9 (MessageSwitch) id 1372721428728708_27011; Mon, 1 Jul 2013 23:30:28 +0000 (UTC) Received: from DB9EHSMHS007.bigfish.com (unknown [10.174.16.232]) by mail220-db9.bigfish.com (Postfix) with ESMTP id ACEFA20045; Mon, 1 Jul 2013 23:30:28 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by DB9EHSMHS007.bigfish.com (10.174.14.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 1 Jul 2013 23:30:28 +0000 Received: from BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.324.0; Mon, 1 Jul 2013 23:30:23 +0000 Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) with Microsoft SMTP Server (TLS) id 15.0.702.21; Mon, 1 Jul 2013 23:30:21 +0000 Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.98]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.98]) with mapi id 15.00.0702.005; Mon, 1 Jul 2013 23:30:21 +0000 From: Andrei Popov To: Yoav Nir , "tls@ietf.org list" Thread-Topic: Some comments about draft-ietf-tls-applayerprotoneg-01 Thread-Index: AQHOcXYmoV9GvBkxHECtNVUf6mHhEZlQdzOg Date: Mon, 1 Jul 2013 23:30:20 +0000 Message-ID: <31987392d2a3412f8e3932dc61264c32@BL2PR03MB194.namprd03.prod.outlook.com> References: <279FAAD4-1FF3-4D9D-939A-10D83E0B036E@checkpoint.com> In-Reply-To: <279FAAD4-1FF3-4D9D-939A-10D83E0B036E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:a:2:c085:5cb7:cd84:99c5] x-forefront-prvs: 089473E5FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB196.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CHECKPOINT.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(199002)(164054003)(189002)(52604005)(377454003)(50986001)(20776003)(47776003)(63696002)(16676001)(33646001)(23726002)(81542001)(46406003)(74316001)(4396001)(6806003)(65816001)(47976001)(47736001)(49866001)(83072001)(51856001)(80022001)(74706001)(79102001)(76482001)(69226001)(56816003)(54316002)(44976004)(81342001)(56776001)(76576001)(76786001)(76796001)(59766001)(50466002)(74366001)(46102001)(74662001)(74876001)(77982001)(47446002)(53806001)(54356001)(74502001)(31966008)(77096001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB030; H:TK5EX14MLTC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 089473E5FE Subject: Re: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 23:31:22 -0000 Hi Yoav, Thanks for reviewing the draft. Regarding the preference order of the protocol IDs, the language was intend= ed to indicate that most of the time it makes sense for the server to choos= e according to the server's preferences; however an implementation may have= valid reasons to ignore this and go with the client's order of preference = (that's why SHOULD is used). We can change the wording, if this is not clea= r. As for returning the protocol selection response, the idea is that an exten= sion is optional, and can be ignored (e.g. when disabled, or for some imple= mentation-specific reasons). I would rather retain this flexibility and kee= p MAY. The current draft makes a distinction between IANA-registered protocol IDs = and those not registered by IANA. The latter can be used privately, for exp= erimentation, etc. We can devise a more elaborate namespace scheme if there= is consensus in the WG that this would be desirable. Personally, I would r= ather keep it simple. "hide" protocol ID seems to defeat the very purpose of hiding:). Those who = are interested in hiding the negotiated protocol, usually don't want the in= termediaries to be able to treat different protocols differently. E.g. prox= ies could easily filter out traffic which includes "hide" protocol ID. Does it make sense to include a protocol list in the renegotiation handshak= e? I believe it is possible that one would want to renegotiate to a differe= nt application protocol. Thanks, Andrei -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Yoav = Nir Sent: Tuesday, June 25, 2013 12:33 AM To: tls@ietf.org list Subject: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01 Hi I have read the draft, and think it is in good shape. There are some quibbl= es, however. Section 3.1 says:=20 "ProtocolNameList" contains the list of protocols advertised by the client, in descending order of preference. But section 3.2 says:=20 It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol it supports which is also advertised by the client. It's not clear to me why the order of preference of the client makes any di= fference if the server chooses a protocol based on its own order of prefere= nce. I would remove that last sentence, and leave it up to the implementati= on whether it enforces its own order of preference (select the most preferr= ed protocol that appears anywhere on the client's list) or the clients' (se= lect the first protocol advertised by the client that you also support). Section 3.1 has this rather confusing paragraph: Servers that receive a client hello containing the "application_layer_protocol_negotiation" extension, MAY return a suitable protocol selection response to the client. The server will ignore any protocol name that it does not recognize. A new ServerHello extension type ("application_layer_protocol_negotiation(16)") MAY be returned to the client within the extended ServerHello message. The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL be structured the same as described above for the client "extension_data", except that the "ProtocolNameList" MUST contain exactly one "ProtocolName". First, ClientHello and ServerHello extensions are pretty much the same (yes= , I know the formatting sometimes changes), so there's no need to talk abou= t "a new ServerHello extension type". Also, I can't figure out the MAY here= . Not returning a response says that the server does not support this exten= sion. A server compliant with this specification MUST send a response (or e= lse a no_application_protocol alert). How about rewriting this as follows: Compliant servers that receive a client hello containing the "application_layer_protocol_negotiation" extension, MUST return a suitable protocol selection response to the client. The server MUST ignore any protocol name that it does not recognize. A=20 ("application_layer_protocol_negotiation(16)") extension MUST be=20 returned to the client within the ServerHello message. The=20 "extension_data" field of the extension is structured the same as=20 described above for the client "extension_data", except that the=20 "ProtocolNameList" MUST contain exactly one "ProtocolName". Section 3.1 also has this: Experimental protocol names, which are not registered by IANA, will start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). And this is repeated in section 4: A namespace will be assigned for experimental protocols, comprising byte strings which start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). Assignments in this namespace do not need IANA registration. I suggest a somewhat different namespace allocation: * Names that begin with "X-" (0x58,0x2D) are experiments, like "X-spdy/4" * Names that begin with "P-" (0x50,0x2D) are private, and shall have an or= ganizational identifier, plus a protocol, like "P-MSFT-SSTP" or "P-CHKP-SNX= " * Names that begin with "D-" (0x44,0x2D) denote drafts, and the rest of th= e byte string has the draft title minus the "draft" qualifier, for example = "D-ietf-httpbis-http2-03". Since a slash (0x2F) is never part of the docume= nt name, a document that defines >1 protocols may add a slash and an intern= ally-meaningful string, such as "D-ietf-httpbis-http2-03/no-header-compress= ion" * IANA shall not assign any byte strings where the second byte is 0x2D. Su= ch byte strings are reserved. Section 4 says: Finally, by managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence with respect to the the ability to hide the negotiated protocol in advance of establishing the connection. If hiding the protocol is required, then renegotiation after connection establishment, which would provide true TLS security guarantees, would be a preferred methodology. How about making this more explicit. Add a special protocol called "hide", = and have the client propose just that. They could even be using an anon-dh = ciphersuite for that handshake. If "hide" is selected, no application data = is tolerated within it, and the client MUST immediately renegotiate with a = proper list of protocols.=20 If both of my previous suggestions are accepted, I would change the initial= registry to contain just "http/1.1" and "hide" for starters, as the spdy e= xperiment can be accommodated by "X-" prefix, and the draft versions of HTT= P/2.0 can be accommodated by "D-" prefix. Finally, the end of section 3.1 says this: Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant and only the values in the new handshake messages are considered. This does not mention renegotiation. Suppose we are already running applica= tion data, and the client initiates a renegotiation. Makes no difference if= this is of its own accord or because of a HelloRequest sent by the server.= Does it make any sense at all to include a protocol list in the renegotiat= ion handshake? Yoav _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From ynir@checkpoint.com Mon Jul 1 23:40:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3B11E830A for ; Mon, 1 Jul 2013 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53VsMpVDLgn2 for ; Mon, 1 Jul 2013 23:40:01 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC221F93E5 for ; Mon, 1 Jul 2013 23:40:00 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r626djkq010984; Tue, 2 Jul 2013 09:39:59 +0300 X-CheckPoint: {51D275B0-8-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 09:39:49 +0300 From: Yoav Nir To: Andrei Popov Thread-Topic: Some comments about draft-ietf-tls-applayerprotoneg-01 Thread-Index: AQHOcXYmoV9GvBkxHECtNVUf6mHhEZlQdzOggABOToA= Date: Tue, 2 Jul 2013 06:39:49 +0000 Message-ID: References: <279FAAD4-1FF3-4D9D-939A-10D83E0B036E@checkpoint.com> <31987392d2a3412f8e3932dc61264c32@BL2PR03MB194.namprd03.prod.outlook.com> In-Reply-To: <31987392d2a3412f8e3932dc61264c32@BL2PR03MB194.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.134] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11319d925e2458a1b08447534db72cb27497aeb610 Content-Type: text/plain; charset="us-ascii" Content-ID: <33FC4D7E4FC23E43BA16AB1CD983710A@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 06:40:07 -0000 Hi Andrei. Inline. On Jul 2, 2013, at 2:30 AM, Andrei Popov wrote= : > Hi Yoav, >=20 > Thanks for reviewing the draft. >=20 > Regarding the preference order of the protocol IDs, the language was inte= nded to indicate that most of the time it makes sense for the server to cho= ose according to the server's preferences; however an implementation may ha= ve valid reasons to ignore this and go with the client's order of preferenc= e (that's why SHOULD is used). We can change the wording, if this is not cl= ear. >=20 > As for returning the protocol selection response, the idea is that an ext= ension is optional, and can be ignored (e.g. when disabled, or for some imp= lementation-specific reasons). I would rather retain this flexibility and k= eep MAY. I know some documents specify behavior of implementations that have turned = off the feature. But I believe an implementation with the feature disabled = is not bound by the RFC. So as long as you support ALPN, you MUST reply. > The current draft makes a distinction between IANA-registered protocol ID= s and those not registered by IANA. The latter can be used privately, for e= xperimentation, etc. We can devise a more elaborate namespace scheme if the= re is consensus in the WG that this would be desirable. Personally, I would= rather keep it simple. I like the idea to have private space in addition to experimental space. Le= t's raise this issue in Berlin (and here) > "hide" protocol ID seems to defeat the very purpose of hiding:). Those wh= o are interested in hiding the negotiated protocol, usually don't want the = intermediaries to be able to treat different protocols differently. E.g. pr= oxies could easily filter out traffic which includes "hide" protocol ID. Doing an immediate renegotiation is as obvious a "tell" as a "hide" protoco= l. But there are many more fields that people would like to hide besides pr= otocol. In fact, protocol is unlikely to be the secret information. Hiding = a client certificate (that might have a user name) is a higher priority. We= can't really hide the fact that we *are* hiding a user identity. But we ca= n hide the identity itself, and I think that's a worthy thing to have. > Does it make sense to include a protocol list in the renegotiation handsh= ake? I believe it is possible that one would want to renegotiate to a diffe= rent application protocol. Renegotiation is supposed to be done to replace encryption keys, and it can= be done unbeknownst to the application layer (which was the basis for the = famous vulnerability from 2009). So negotiating a new protocol would be wei= rd. > Thanks, >=20 > Andrei From Andrei.Popov@microsoft.com Wed Jul 3 14:18:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EE521F9D22 for ; Wed, 3 Jul 2013 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXr8h9qwjLAV for ; Wed, 3 Jul 2013 14:18:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id C833721F9D24 for ; Wed, 3 Jul 2013 14:18:30 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.202) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.717.3; Wed, 3 Jul 2013 21:18:29 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Wed, 3 Jul 2013 21:18:28 +0000 Received: from DB8EHSOBE007.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 3 Jul 2013 21:18:11 +0000 Received: from mail19-db8-R.bigfish.com (10.174.8.253) by DB8EHSOBE007.bigfish.com (10.174.4.70) with Microsoft SMTP Server id 14.1.225.22; Wed, 3 Jul 2013 21:18:09 +0000 Received: from mail19-db8 (localhost [127.0.0.1]) by mail19-db8-R.bigfish.com (Postfix) with ESMTP id 41DBF34025E for ; Wed, 3 Jul 2013 21:18:09 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371I148cI542I1432I1418I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: softfail (mail19-db8: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(377454003)(52604005)(51704005)(13464003)(164054003)(51444003)(24454002)(46102001)(51856001)(79102001)(74502001)(54316002)(76786001)(74662001)(76576001)(33646001)(81342001)(54356001)(77096001)(74316001)(16406001)(74706001)(81542001)(47446002)(83072001)(56816003)(74366001)(47736001)(76482001)(4396001)(59766001)(80022001)(49866001)(69226001)(47976001)(74876001)(53806001)(76796001)(77982001)(56776001)(50986001)(31966008)(65816001)(63696002)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB196; H:BL2PR03MB194.namprd03.prod.outlook.com; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail19-db8 (localhost.localdomain [127.0.0.1]) by mail19-db8 (MessageSwitch) id 1372886287244944_12008; Wed, 3 Jul 2013 21:18:07 +0000 (UTC) Received: from DB8EHSMHS028.bigfish.com (unknown [10.174.8.244]) by mail19-db8.bigfish.com (Postfix) with ESMTP id 37E2D700047; Wed, 3 Jul 2013 21:18:07 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS028.bigfish.com (10.174.4.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 3 Jul 2013 21:18:06 +0000 Received: from BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.324.0; Wed, 3 Jul 2013 21:18:06 +0000 Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) with Microsoft SMTP Server (TLS) id 15.0.702.21; Wed, 3 Jul 2013 21:18:05 +0000 Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.98]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.98]) with mapi id 15.00.0702.005; Wed, 3 Jul 2013 21:18:05 +0000 From: Andrei Popov To: Yoav Nir Thread-Topic: Some comments about draft-ietf-tls-applayerprotoneg-01 Thread-Index: AQHOcXYmoV9GvBkxHECtNVUf6mHhEZlQdzOggABOToCAAonR4A== Date: Wed, 3 Jul 2013 21:18:05 +0000 Message-ID: <907a79bbee5a4733b0b5b618ccd2768b@BL2PR03MB194.namprd03.prod.outlook.com> References: <279FAAD4-1FF3-4D9D-939A-10D83E0B036E@checkpoint.com> <31987392d2a3412f8e3932dc61264c32@BL2PR03MB194.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:a:2:c085:5cb7:cd84:99c5] x-forefront-prvs: 0896BFCE6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB196.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CHECKPOINT.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(51444003)(189002)(164054003)(199002)(51704005)(24454002)(377454003)(52604005)(47736001)(76796001)(54316002)(76786001)(54356001)(76576001)(33646001)(63696002)(16676001)(4396001)(51856001)(47776003)(74316001)(50986001)(80022001)(49866001)(20776003)(6806003)(47976001)(65816001)(81542001)(76482001)(77096001)(74502001)(74876001)(69226001)(74366001)(77982001)(53806001)(46406003)(50466002)(56776001)(56816003)(81342001)(83072001)(31966008)(59766001)(47446002)(46102001)(23726002)(74662001)(79102001)(44976004)(74706001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB024; H:TK5EX14MLTC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0896BFCE6C Cc: "tls@ietf.org list" Subject: Re: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 21:18:37 -0000 " So as long as you support ALPN, you MUST reply." Here's an example: let's say a TLS server supports both ALPN and XPN extens= ions, each with its own set of application protocols. The server receives b= oth ALPN and XPN extensions in the ClientHello. The server might find no ma= tching ALPN protocol ID, but there is still hope that XPN will have a match= . Or, perhaps the server prefers to use XPN for some reason. In these and s= imilar situations, it makes sense for the server to ignore ALPN extension a= nd give XPN a try, without terminating the handshake with a fatal alert. I = would like the draft to allow this behavior. Regarding the private namespace, I see no problem adding it if enough peopl= e want it. Would the protocol IDs in the private namespace not require IANA= registration, just like those in the experimental namespace? Renegotiation is used for multiple purposes, commonly including client auth= , so I believe it is less revealing than the "hide" protocol ID. More impor= tantly, what does the "hide" protocol ID achieve that we don't have already= ? Cheers, Andrei -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Monday, July 1, 2013 11:40 PM To: Andrei Popov Cc: tls@ietf.org list Subject: Re: Some comments about draft-ietf-tls-applayerprotoneg-01 Hi Andrei. Inline. On Jul 2, 2013, at 2:30 AM, Andrei Popov wrote= : > Hi Yoav, >=20 > Thanks for reviewing the draft. >=20 > Regarding the preference order of the protocol IDs, the language was inte= nded to indicate that most of the time it makes sense for the server to cho= ose according to the server's preferences; however an implementation may ha= ve valid reasons to ignore this and go with the client's order of preferenc= e (that's why SHOULD is used). We can change the wording, if this is not cl= ear. >=20 > As for returning the protocol selection response, the idea is that an ext= ension is optional, and can be ignored (e.g. when disabled, or for some imp= lementation-specific reasons). I would rather retain this flexibility and k= eep MAY. I know some documents specify behavior of implementations that have turned = off the feature. But I believe an implementation with the feature disabled = is not bound by the RFC. So as long as you support ALPN, you MUST reply. > The current draft makes a distinction between IANA-registered protocol ID= s and those not registered by IANA. The latter can be used privately, for e= xperimentation, etc. We can devise a more elaborate namespace scheme if the= re is consensus in the WG that this would be desirable. Personally, I would= rather keep it simple. I like the idea to have private space in addition to experimental space. Le= t's raise this issue in Berlin (and here) > "hide" protocol ID seems to defeat the very purpose of hiding:). Those wh= o are interested in hiding the negotiated protocol, usually don't want the = intermediaries to be able to treat different protocols differently. E.g. pr= oxies could easily filter out traffic which includes "hide" protocol ID. Doing an immediate renegotiation is as obvious a "tell" as a "hide" protoco= l. But there are many more fields that people would like to hide besides pr= otocol. In fact, protocol is unlikely to be the secret information. Hiding = a client certificate (that might have a user name) is a higher priority. We= can't really hide the fact that we *are* hiding a user identity. But we ca= n hide the identity itself, and I think that's a worthy thing to have. > Does it make sense to include a protocol list in the renegotiation handsh= ake? I believe it is possible that one would want to renegotiate to a diffe= rent application protocol. Renegotiation is supposed to be done to replace encryption keys, and it can= be done unbeknownst to the application layer (which was the basis for the = famous vulnerability from 2009). So negotiating a new protocol would be wei= rd. > Thanks, >=20 > Andrei From Paras.Shah@riverbed.com Tue Jun 25 12:35:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3F321E809B for ; Tue, 25 Jun 2013 12:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8q0nYRMrL9R for ; Tue, 25 Jun 2013 12:35:14 -0700 (PDT) Received: from smtp1.riverbed.com (smtp.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4846021F9EA2 for ; Tue, 25 Jun 2013 12:35:14 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P1.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 25 Jun 2013 12:35:14 -0700 Received: from 365EXCH-MBX-P3.nbttech.com ([fe80::d453:ae2c:3b65:50e5]) by 365EXCH-HUB-P1.nbttech.com ([::1]) with mapi id 14.02.0328.009; Tue, 25 Jun 2013 12:35:13 -0700 From: Paras Shah To: "OMAR HASSAN (RIT Student)" Thread-Topic: [TLS] User Defined Key Pair Thread-Index: AQHObq4khJkyicCAKkOjssuh7VsnkZlFd1yAgAAPogCAAAIEgIAAH96AgAACDACAADDiAIAA6pmAgABbRYCAACSxgP//kMTw Date: Tue, 25 Jun 2013 19:35:12 +0000 Message-ID: <377FB9023E313048955F1A4A54DB21009A5676E9@365EXCH-MBX-P3.nbttech.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.250] Content-Type: multipart/alternative; boundary="_000_377FB9023E313048955F1A4A54DB21009A5676E9365EXCHMBXP3nbt_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 09 Jul 2013 08:44:46 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:35:19 -0000 --_000_377FB9023E313048955F1A4A54DB21009A5676E9365EXCHMBXP3nbt_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >If someone pretended to be Facebook, he will receive a public key and a s= igned message. The attacker cannot use this information to log into Faceboo= k, because the signed message contains the current >server's time stamp, so= it's valid only for a few seconds. That is the issue right there. If the attacker was masquerading as Facebook= , he would get the user's public key, signed message, username. The attacke= r, can then choose a session key _of his choice_, encrypt with public key o= f user and send it back. Thereafter, the user is communicating with the att= acker instead of the real Facebook server. Besides, even the very 1st time, how do you know that the user is communica= ting with Facebook for real to get the server's current timestamp for examp= le. Paras Shah, SSL Security Engineer, Riverbed Technology. From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of OMAR = HASSAN (RIT Student) Sent: Tuesday, June 25, 2013 12:07 PM Cc: tls@ietf.org Subject: Re: [TLS] User Defined Key Pair Hi Uri, May be I am still not able to clear my point regarding the man in the middl= e attack. When the user provides the credential information, he will not provide it t= o the Facebook log in page, instead he will go to the menu bar in his brows= er, and run the new plugin which has two tabs: one for log in; and the othe= r for enrollment, and in the plugin interface the user will provide his cre= dential information. The key pair will be generated inside the browser's plugin, and only the si= gned message, and the username will go to Facebook, no passwords will leave= the user's browser. When the server receive the username and the signed me= ssage, it will send the session key encrypted with the user's public key. If someone pretended to be Facebook, he will receive a public key and a si= gned message. The attacker cannot use this information to log into Facebook= , because the signed message contains the current server's time stamp, so i= t's valid only for a few seconds. And even if the attacker sends the signed message and the username to the s= erver, and the server accepted them, the next step is that the server will = respond with the session key encrypted with the user's public key. How the = attacker will read the public key if he doesn't have the private key, the p= rivate key that didn't leave the user's browser. On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) > wrote: Hi All >Stephan: >How you made sure that the user (client) is connected with the intended se= rver? >Paras Shah: >That is exactly the question I had. How is Server Authentication done with= this approach? >Rich: >I don't see anything in your system that prevents this, either. It seems = that replacing your system with self-signed client >certificates would be e= quivalent. >Robert: >As the proposal has no server authentication, it is surely broken in that = respect i.e. the client could be lured to any bogus >website masquerading a= s a legitimate one. How would the client know? I would explain How is Server Authentication done with a practical example.= Let's name facebook as our website that we need to protect using that new = protocol. When I go to facebook, I would receive a browser message telling me: "Pleas= e use the UDKP protected access (Tools->UDKP Protected Access)!" the user will go to the plugin interface, and provide the username, passwor= d, password confirmation, the plugin will create a file with random data st= ream in the user's usb, and then the user will click on the register button= . At that point the plugin will create the key pair based on the random file,= username, and password. The public key will go to the server with the user= name and a signed message, and the user will be redirected to the facebook = registration page to complete his registration. Now the user profile is created on facebook and associated with the user pu= blic key. When the user tries to sign in later into facebook, and if he was deceived = to sign in into a fake website, the user will go to the browser plugin inte= rface, and provide the username, password, and select the file from his usb= . At that point the user will be expecting to see his facebook timeline if = he is really signing into the real facebook. Note that the user didn't prov= ide the credential information to the website but to the browser plugin (To= ols->UDKP Protected Access). In our case, the fake website will only receive the username, the public ke= y, and the token (ServerHello.random ) signed with user private key, If the= attacker delivered this message to the facebook server, the server will tr= y to read and validate the token using the user public key. If it succeeds,= it will respond with the session key premaster encrypted by the user publi= c key. Because the user private key did not leave the browser, the attacker= will not be able to read the session key and hence will not be able to mon= itor the traffic. So if the user was successfully able to see his timeline, he would be sure = that he is communicating with the real facebook. >Robert: >Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting usi= ng a private key seems pointless. Don't you mean >signing? Yes Robert, I mean signing not encrypting. Actually someone told me before = about that mistake in the previous version, but unfortunately I forgot to c= orrect it in the new version. Hopefully in the next version it will be corr= ected. Thank You. >Juho V=E4h=E4-Herttua: >The whole security of the system seems to be dependant on the security of = the "browser plugin" and its key generation and encryption algorithms I preferred to make the generation of the key pair as a black box, so we ca= n focus our discussion on the idea itself, so the question is if we have a = key generation function that can generate key pair securely based on the us= ername, password, and the file selected, would the idea be a good one. >What if someone detects this enrollment and sends a new public key for the= user before the user has time to fill all the fields? Sounds like a race c= ondition to me. The key pair generation is done inside the browser plugin interface, not in= the website page, so there is no race condition, the communication with th= e website will start after the creation of the key pair. >I don't see how this is different from generating a self signed client cer= t and verifying it with for example HMAC with username+password+question de= rived secret. If you already need a custom >browser >plugin to handle the login, you can put all your custom logic there and us= e standard TLS for the rest. You can look at the generated key pair as a client certificate, but I prefe= rred to make it as a key pair, so this key pair could be generated based on= different approaches: security question, file, smart card, hardware token. Additionally it's not only about custom sign in, it's also about eliminatin= g the dependence on the CA, so the session key must be encrypted with the u= ser public key not encrypted with a key that claims to be the server public= key. >Rich: >It's great that you are trying to improve things; don't get discouraged, b= ut this ain't there yet. And as a first step to replacing all of SSL/TLS? = Nope. I am not discouraged at all, but I am still insisting that the security of = my traffic to facebook must be the responsibility of me and facebook only, = and not anyone else. And I am doing my best to achieve that. The discussion= is very useful to me, may be after this discussion we can come out with a = new final solution to this issue. On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich > wrote: > Self signed certificate is very dangerous because the user will not have= a way to verify the identity of the certificate owner and he could be a vi= ctim to a man in the middle attack. I don't see anything in your system that prevents this, either. It seems t= hat replacing your system with self-signed client certificates would be equ= ivalent. It's great that you are trying to improve things; don't get discouraged, bu= t this ain't there yet. And as a first step to replacing all of SSL/TLS? = Nope. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_377FB9023E313048955F1A4A54DB21009A5676E9365EXCHMBXP3nbt_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>If  someone preten= ded to be Facebook, he will receive a public key and a signed message. The = attacker cannot use this information to log into Facebook, because the signed message contains the current >server's time stamp, so it's v= alid only for a few seconds.

 <= /p>

That is the issue right t= here. If the attacker was masquerading as Facebook, he would get the user&#= 8217;s public key, signed message, username. The attacker, can then choose a session key _of his choice_, encrypt with public key = of user and send it back. Thereafter, the user is communicating with the at= tacker instead of the real Facebook server.

 <= /p>

Besides, even the very 1<= sup>st time, how do you know that the user is communicating with Face= book for real to get the server’s current timestamp for example.

 <= /p>

Paras Shah,

SSL Security Engineer,

Riverbed Technology.=

 <= /p>

From: tls-boun= ces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of OMAR HASSAN (RIT Student)
Sent: Tuesday, June 25, 2013 12:07 PM
Cc: tls@ietf.org
Subject: Re: [TLS] User Defined Key Pair

 

Hi Uri,

 

May be I am still not able = to clear my point regarding the man in the middle attack. =

 

When the user provides the = credential information, he will not provide it to the Facebook log in page,= instead he will go to the menu bar in his browser, and run the new plugin which has two tabs: one for log in; and the other for e= nrollment, and in the plugin interface the user will provide his credential= information.

 

The key pair will be genera= ted inside the browser's plugin, and only the signed message, and the usern= ame will go to Facebook, no passwords will leave the user's browser. When the server receive the username and the signed message, it w= ill send the session key encrypted with the user's public key.<= /o:p>

 

If  someone pretended = to be Facebook, he will receive a public key and a signed message. The atta= cker cannot use this information to log into Facebook, because the signed message contains the current server's time stamp, so it's valid= only for a few seconds.

 

And even if the attacker se= nds the signed message and the username to the server, and the server accep= ted them, the next step is that the server will respond with the session key encrypted with the user's public key. How the attacke= r will read the public key if he doesn't have the private key, the private = key that didn't leave the user's browser.

 

On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT St= udent) <omh1835@rit= .edu> wrote:

Hi All

>Stephan:


>How you made sure that the user (client) is connected with the intended= server?

>Paras Shah:


>That is exactly the question I had. How is Server Authentication done w= ith this approach?

>Rich:


>I don’t see anything in your system that prevents this, either. &= nbsp;It seems that replacing your system with self-signed client >c= ertificates would be equivalent.

>Robert:
>As the proposal has no server authentication, it is surely broken in th= at respect i.e. the client could be lured to any bogus >website mas= querading as a legitimate one. How would the client know?

I would explain How is Server Authentication done with a practica= l example. Let's name facebook as our website that we need to protect using= that new protocol.

When I go to facebook, I would receive a browser message telling me: "= Please use the UDKP protected access (Tools->UDKP Protected Access)!&quo= t;
the user will go to the plugin interface, and provide the username, passwor= d, password confirmation, the plugin will create a file with random data st= ream in the user's usb, and then the user will click on the register button= .


At that point the plugin will create the key pair based on the random file,= username, and password. The public key will go to the server with the user= name and a signed message, and the user will be redirected to the facebook = registration page to complete his registration.


Now the user profile is created on facebook and associated with the user pu= blic key.


When the user tries to sign in later into facebook, and if he was deceived = to sign in into a fake website, the user will go to the browser plugin inte= rface, and provide the username, password, and select the file from his usb= . At that point the user will be expecting to see his facebook timeline if he is really signing into the re= al facebook. Note that the user didn't provide the credential information t= o the website but to the browser plugin (Tools->UDKP Protected Access).<= o:p>


In our case, the fake website will only receive the username, the public ke= y, and the token (ServerHello.random ) signed with user private key, I= f the attacker delivered this message to the facebook server, the serv= er will try to read and validate the token using the user public key. If it succeeds, it will respond with the s= ession key premaster encrypted by the user public key. Because the use= r private key did not leave the browser, the attacker will not be able to r= ead the session key and hence will not be able to monitor the traffic.

So if the user was successfully able to see his time= line, he would be sure that he is communicating with the real facebook.

>Robert:
>Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting = using a private key seems pointless. Don't you mean >signing?

Yes Robert, I mean signing not encrypting. Actually someone told = me before about that mistake in the previous version, but unfortunately I f= orgot to correct it in the new version. Hopefully in the next version it wi= ll be corrected. Thank You.

>Juho V=E4h=E4-Herttua:


>The whole security of the system seems to be dependant on the security = of the "browser plugin" and its key generation and encryption alg= orithms

I preferred to make the generation of the key pair a= s a black box, so we can focus our discussion on the idea itself, so the qu= estion is if we have a key generation function that can generate key pair s= ecurely based on the username, password, and the file selected, would the idea be a good one.


>What if someone detects this enrollment and sends a new public key for = the user before the user has time to fill all the fields? Sounds like a rac= e condition to me.

The key pair generation is done inside the browser p= lugin interface, not in the website page, so there is no race condition, th= e communication with the website will start after the creation of the key p= air.



>I don't see how this is different from generating a self signed client = cert and verifying it with for example HMAC with username+password+= question derived secret. If you already need a custom >browser 

>plugin to handle = the login, you can put all your custom logic there and use standard TLS for= the rest.

You can look at the g= enerated key pair as a client certificate, but I preferred to make it as a = key pair, so this key pair could be generated based on different approaches= : security question, file, smart card, hardware token.

Additionally it's not only about custom sign in, it'= s also about eliminating the dependence on the CA, so the session key must = be encrypted with the user public key not encrypted with a key that claims = to be the server public key.

>Rich:


>It’s great that you are trying to improve things; don’t get= discouraged, but this ain’t there yet.  And as a first step to = replacing all of SSL/TLS?  Nope.

I am not discouraged at all, but I am still insistin= g that the security of my traffic to facebook must be the responsibility of= me and facebook only, and not anyone else. And I am doing my best to achie= ve that. The discussion is very useful to me, may be after this discussion we can come out with a new final = solution to this issue.

 

On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich <rsalz@akamai.com> = wrote:

=D8  Self signed certificate is very dangerous because the user will not have a = way to verify the identity of the certificate owner and he could be a victi= m to a man in the middle attack.

 

I don’t see anything in your syst= em that prevents this, either.  It seems that replacing your system with self-signed client certificates would be equivalent.

 

It’s great that you are trying to= improve things; don’t get discouraged, but this ain’t there ye= t.  And as a first step to replacing all of SSL/TLS?  Nope.

 

      &nb= sp;         /r$

 

-- 

Principal Security Engineer=

Akamai Technology

Cambridge, MA

 

 

 

--_000_377FB9023E313048955F1A4A54DB21009A5676E9365EXCHMBXP3nbt_-- From balfanz@google.com Sat Jun 29 04:28:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21B021F94FF for ; Sat, 29 Jun 2013 04:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZsQYPgJsqPg for ; Sat, 29 Jun 2013 04:28:40 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 63ED321F9473 for ; Sat, 29 Jun 2013 04:28:40 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 5so1025701qeb.31 for ; Sat, 29 Jun 2013 04:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5p3tYFxnKADazLhdHzizE1ruZ46VBf2yXA+N5j2Fs/8=; b=UmnVPKyhW7mQCK9ExEjk0aExxkE/HGcM5R7on5/oyi7mQyYu8ne9r8w98LpPtnn1Yz UDknogFZtc62xhEtDI78BalVLcdue4xGxEDA4SZbwSFOHBE0edmgbKbzAevI6DdHsfKX maM3arHFQpQsrM9xbXD83P9s/M4OtfdEUML5/LBqfPC2iHJquXEKd7Tc9bWl9ytE1/GO 57yUsrqj+p4REwUlSzepRxefmChBV5Zn+lEKJwfVk10kbXU5QNrjzSbyZ4KhZDMT/TQl TvW/GxkcqzDMEHWLCiCWP01dnukas3DG8UwoMVxUt5BDoTEIfYcA8YuaqrpBV5kfi0f5 S7Hw== X-Google-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:x-gm-message-state; bh=5p3tYFxnKADazLhdHzizE1ruZ46VBf2yXA+N5j2Fs/8=; b=D/kMpqudoHrL2mt0bvI193rOEC4pHvh2yyWpKH7HY+vWUY3uqgXvcLwVcGU1QPzpz2 nWi2a4hq5BiPDoBhmyQuve3EnRf3fpp1S5+bZAy1OJ5sR0Z87owOxoWw7o4CmFwNqN/N gtMIBpNUo+Yy6lZuohhrmMlfotTw5aWSuJ3Kk39QUkNqap3eJOvzLdzh7smkkq/DU4xz 4i1yp079isFdXhzlU4JYJfzvBS1k7hKpHbUcm9BaUbJU9cZvAm3oLH8+S+ByMAt+aRzl 8nPKp4Po/KtavFuA5fx968yiVFOFOWfljkoCkh7DtpBX9k51yemIsMZiqms2Nd8JTZaT F0+Q== MIME-Version: 1.0 X-Received: by 10.224.7.129 with SMTP id d1mr22808522qad.108.1372505319645; Sat, 29 Jun 2013 04:28:39 -0700 (PDT) Received: by 10.229.148.8 with HTTP; Sat, 29 Jun 2013 04:28:39 -0700 (PDT) In-Reply-To: <51805DA9.8000606@KingsMountain.com> References: <51805DA9.8000606@KingsMountain.com> Date: Sat, 29 Jun 2013 04:28:39 -0700 Message-ID: From: Dirk Balfanz To: "=JeffH" Content-Type: multipart/alternative; boundary=047d7b675dd207c8c704e0494c9c X-Gm-Message-State: ALoCoQkNo+b40AB6y6PVQxZcoEu0B+x8YcORk4nFmhib541BKEPgSwzLL1MD1NmyIVUblEZetQJsSWp00ntPbgH6JsjDwJDGcc8KogGPyPKBxG5goCTA/n7adfufP4zY3LiYySStaQnL9WvBHxzfbo7e4DXFo/hY92SN6Lz1kHkUjHVuyGvTP0FvtX1R85UB9BAhcTtTZCwG X-Mailman-Approved-At: Tue, 09 Jul 2013 08:44:46 -0700 Cc: IETF TLS WG Subject: Re: [TLS] comments on draft-balfanz-tls-channelid X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 11:28:44 -0000 --047d7b675dd207c8c704e0494c9c Content-Type: text/plain; charset=ISO-8859-1 Jeff, thanks so much for your comments. I'll address all the typos/wording changes etc. in a new draft. Below my answers to your high-level comments. On Tue, Apr 30, 2013 at 5:11 PM, =JeffH wrote: > [ for best results use a fixed-pitch font ] > > Here's some comments on draft-balfanz-tls-channelid, I hope they're > helpful. > > =JeffH > ------ > > High-level comments: > > 1. EncryptedExtensions modification to the TLS handshake ought to be split > out into a separate spec. > > 2. What are the ramifications if the TLS WG does not adopt an > EncryptedExtensions mechanism? I.e., what are the downsides to the > "channel id" being publicly exposed, i.e., the security ones as well as the > privacy implications? > I don't believe there should be security implications, but I feel fairly strongly - for privacy reasons - that the channel id message belongs in the encrypted part of the handshake. Whether or not that's riding on top of the EncryptedExtension mechanism (which indeed has been discussed separately) is something that I'm happy to discuss. I'm planning to go to IETF 87 in Berlin. Maybe we can discuss there? > 3. In my view, this spec defines how a TLS client generates and > subsequently wields a unique client identifier/key with a particular TLS > server over multiple TLS connections (in parallel and serially). Thus it is > more about creating a "security association" between the client and server > (eg, see definitions for the latter, as well as "channel", in RFC4949). > Thus I would not use the term "channel" for this mechanism. Also, TLS unto > itself is creating a cryptographic channel between client and server and > thus using the channel term for this mech seems ripe for confusion. This > comment implies some re-writing of the introduction (I've made some modest > suggestions below). Perhaps "TLS Security Association ID" (TLS-SAIDs) ? > I'm using "channel" in the sense of formal access control logics, for example as it's used here: http://homepages.inf.ed.ac.uk/gdp/publications/Calculus_for_Access_Control.pdf(I don't know what newfangled nomenclature people have introduced in RFC4949 - can I cite historical precedence? :-) A channel is something through with a principal can send messages. When you receive a message, you can tell which channel it has come through. In this sense, a cryptographic key (that signs messages) becomes a "channel". Yes, a TLS connection is a channel, but so is the client key we're using here. The former is a more short-lived channel, the latter is longer-lived. I think RFC5929 uses "channel" in this sense, too, since it views the server's keys as a channel (at least for the tls-server-end-point binding type). > 4. The lifecycle for the unique client identifier (aka "channel id") ought > to be more fully discussed/specified in main portion of the spec. Presently > it's sprinkled in the introduction and the privacy considerations. > Ok - I see how it currently reads and will try to make improvements. We have actually moved in Chrome to not expiring the keys automatically (although the user can still rotate them through the UI). > > 5. There would seem to be considerations for applications in terms of > reliance on the persistence of a given "channel id" and provisions for the > "channel id" changing or disappearing, e.g. if an app leverages "channel > id" to bind long-lived app-layer objects (eg cookies) to the TLS client, > and these implications/issues should be discussed. > Ok - I'll try and add something for that. > 6. This mechanism should be compared/contrasted with TLS Channel Binding > RFC5929. They don't appear to be mutually exclusive on first thought. What > are the semantics if they are both employed by an application? For what > might one employ one or the other or both concurrently? > In my view this is simply another binding type that could be added to RFC5929. In RFC5929, there is already a tls-server-end-point binding type that is simply the hash of the server cert. A channel-id-binding-type could be defined as the dual of that for the client side. But just as the TLS spec - not RFC5929 - explains how a server cert is "glued" to a TLS connection (i.e., only someone possessing the corresponding private key can "wield" the server cert), we need a different spec - this one, not RFC 5929 - that explains how the channel id keys are "glued" to a TLS connection. These can all co-exist. 7. This is a "trust on first use (TOFU)" mechanism. This should be > mentioned/discussed explicitly. > It doesn't have to be a TOFU mechanism. I can imagine other protocols that introduce the channel id in a secure manner to the server. See, e.g., http://homes.cs.washington.edu/~aczeskis/research/pubs/czeskis-phoneauth-ccs12.pdf Dirk. > > > Detailed comments/questions: > > > Network Working Group D. Balfanz > > Internet-Draft R. Hamilton > > Expires: May 12, 2013 Google Inc > > November 8, 2012 > > > > > > Transport Layer Security (TLS) Channel IDs > > draft-balfanz-tls-channelid-00 > > > > Abstract > > > > This document describes a Transport Layer Security (TLS) extension > > for identifying client machines at the TLS layer without using bearer > > tokens. > > > snip > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Why not client certificates . . . . . . . . . . . . . . . . . 4 > > 3. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 > > 4. Channel ID Extension . . . . . . . . . . . . . . . . . . . . . 6 > > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > > 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 9 > > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 > > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > > 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 > > 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 > > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 > > > snip > > > > 1. Introduction > > > > Many applications on the Internet use _bearer tokens_ to authenticate > > clients to servers. The most prominent example is the HTTP-based > > World Wide Web, which overwhelmingly uses HTTP cookies to > > authenticate client requests. Other examples include OpenID or SAML > > assertions, and OAuth tokens. All these have in common that the > > _bearer_ of the HTTP cookie or authentication token is granted access > > to a protected resource, regardless of the channel over which the > > token is presented, or who presented it. > > > > As a result, an adversary that manages to steal a bearer token from a > > client can impersonate that client to services that require the > > token. > > > > This document describes a light-weight mechanism for establishing a > > _cryptographic channel_ between client and server. > ^^^^^^^ ^ > security association , denoted by an ECC public key. > > > > A server can > ^ > For example, > > > > choose to bind authentication tokens to this channel, thus rendering > ^^^^^^^ > association > > > the theft of authentication tokens fruitless - tokens must be sent > > over the channel to which they are bound (i.e., by the client to > > which they were issued) or else they will be ignored. > > suggest.. > > ..tokens bound to the security association will be ignored by the > if they are not sent by the legitimate client. > > > > > This document does not prescribe _how_ authentication tokens are > > bound to the underlying channel. Rather, it prescribes how a client > > can establish a long-lived channel with a server. > ^^^^^^^ > security association > > > Such a channel > ^^^^^^^^^ > an association > > > persists across HTTP requests, TLS connections, and even multiple TLS > > sessions, as long as the same client communicates with the same > > server. > > > > The basic idea is that the client proves, during the TLS handshake, > > possession of a private key. The corresponding public key becomes > > the "Channel ID" that identifies this TLS connection. Clients should > > re-use the same private/public key pair across subsequent TLS > > connections to the same server, thus creating TLS connections that > > share the same Channel ID. > > > > Using private/public key pairs to define a channel (as opposed to, > > say, an HTTP session cookie) has several advantages: One, the > > credential establishing the channel (the private key) is never sent > > from client to server, thus removing it from the reach of > > eavesdroppers in the network. Two, clients can choose to implement > > cryptographic operations in a secure hardware module, which further > > removes the private key from the reach of eavesdroppers residing on > > the client itself. > > > snip > > > > 2. Why not client certificates > > > > TLS already supports a means of identifying clients without using > > bearer tokens: client certificates. However, a number of problems > > with using client certificates motivated the development of an > > alternative. > > > > Most importantly, it's not acceptable for a client identifier to be > > what are the threats if a long-term, asymmetric-key-based client > identifier is sent in the clear during TLS handshake? Is it mostly a > privacy concern? Or is it because of anticipated use cases of binding > app-layer info to the TLS layer? > > > > > transmitted in the clear and client certificates in TLS are sent > > unencrypted. Although we could also define a change to the TLS state > > machine to move the client certificates under encryption, such > > changes eliminate most of the benefits of reusing something that's > > already defined. > > > > TLS client certificates are also defined to be part of the session > > state. This turns session resumption secrets into equivalent barer > ^^^^^ > bearer > > tokens; completely defeating our objectives. > > I'm curious here... RFC5246 Appendix F.1.4. indicates.. > > When a connection is established by resuming a session, new > ClientHello.random and ServerHello.random values are hashed with the > session's master_secret. Provided that the master_secret has not > been compromised and that the secure hash operations used to produce > the encryption keys and MAC keys are secure, the connection should be > secure and effectively independent from previous connections. > > ..so I'm not sure how "session resumption secrets" are "equivalent bearer > tokens" ? > > > > > > > Client-certificates typically identify a user, while we seek to > > identify machines. Since they are not, conceptually, mutually > > exclusive and as only a single client certificate can be provided in > > TLS, we don't want to consume that single slot and eliminate the > > possibility of also using existing client certificates. > > > > Client certificates are implemented in TLS as X.509 certificates and > > we don't wish to require servers to parse arbitrary ASN.1. ASN.1 is > > a complex encoding that has been the source of several security > > vulnerabilities in the past and typical TLS servers can currently > > avoid doing ASN.1 parsing. > > > > X.509 certificates always include a signature, which would be a self- > > signature in this case. Calculating and transmitting the self- > > signature is a waste of computation and network traffic in our use. > > Although we could define a null signature algorithm with an empty > > signature, such deviations from X.509 eliminate many of the benefits > > of reusing something that is already implemented. > > > > Finally, client certificates trigger significant server-side > > processing by default and often need to be stored in their entirety > > for the duration of the connection. Since this design is intended to > > be widely used, it allows servers to retain only a cryptographic hash > > of the client's public key after the handshake completes. > > > snip > > > > 4. Channel ID Extension > > > > A new extension type ("channel_id(TBD)") is defined and MAY be > > included by the client in its "ClientHello" message. If, and only > > if, the server sees this extension in the "ClientHello", it MAY > > choose to echo the extension in its "ServerHello". In both cases, > > the "extension_data" field MUST be empty. > > > > enum { > > channel_id(TBD), (65535) > > } ExtensionType; > > > > A new handshake message type ("encrypted_extensions(TBD)") is > > defined. If the server included a "channel_id" extension in its > > "ServerHello" message, the client MUST verify that the selected > > cipher suite is sufficiently strong. If the cipher suite provides < > > 80-bits of security, the client MUST abort the handshake with a fatal > > "illegal_parameter" alert. Otherwise, the client MUST send an > > "EncryptedExtensions" message after its "ChangeCipherSpec" and before > > its "Finished" message. > > > > enum { > > encrypted_extensions(TBD), (65535) > > } HandshakeType; > > > > Therefore a full handshake with "EncryptedExtensions" has the > > following flow (contrast with section 7.3 of RFC 5246 [RFC5246]): > > > > Client Server > > > > ClientHello (ChannelID extension) --------> > > ServerHello > > (ChannelID extension) > > Certificate* > > ServerKeyExchange* > > CertificateRequest* > > <-------- ServerHelloDone > > Certificate* > > ClientKeyExchange > > CertificateVerify* > > [ChangeCipherSpec] > > EncryptedExtensions > > Finished --------> > > [ChangeCipherSpec] > > <-------- Finished > > Application Data <-------> Application Data > > > > An abbreviated handshake with "EncryptedExtensions" has the following > > > > > > > > Balfanz & Hamilton Expires May 12, 2013 [Page 6] > > > > Internet-Draft TLS Channel ID November 2012 > > > > > > flow: > > > > Client Server > > > > ClientHello (ChannelID extension) --------> > > ServerHello > > (ChannelID extension) > > [ChangeCipherSpec] > > <-------- Finished > > [ChangeCipherSpec] > > EncryptedExtensions > > Finished --------> > > Application Data <-------> Application Data > > > > The "EncryptedExtensions" message contains a series of "Extension" > > structures (see section 7.4.1.4 of RFC 5246 [RFC5246] > > the below should be separate section... > > > > If the server included a "channel_id" extension in its "ServerHello" > > message, the client MUST include an "Extension" with "extension_type" > > suggest.. > > ..the client MUST include, within the EncryptedExtensions message, an > "Extension" with "extension_type"... > > > > > > equal to "channel_id(TBD)". The "extension_data" of which has the > > following format: > > > > struct { > > opaque x[32]; > > opaque y[32]; > > opaque r[32]; > > opaque s[32]; > > } ChannelIDExtension; > > > > The contents of each of "x", "y", "r" and "s" is a 32-byte, big- > > endian number. The "x" and "y" fields contain the affine coordinates > > of a P-256 [DSS] curve point. > > you mean that the "x" and "y" fields (of the ChannelIDExtension struct) > contain the affine coordinates of a P-256 [DSS] curve point comprising an > ECC public key "Q" ? > > [ where Q = dG, d = ECC private key, G is the curve base point, and other > elliptic curve "domain parameters" are as given in [DSS] for curve P-256, > and the key pair is generated according to appendix B.4 in [DSS] aka > FIPS-186-3 ? ] > > So Q = (x,y) is the "channel id" per se ? It should be made explicit. > > > What's the lifecycle management of this identifier (ie "Q")? Is the TLS > server (or the server-side app running on top of it) to remember this > identifier? Is it to be mapped to other client-side identifying > information eg IP address, user data (eg account name), etc ? Even though > this I-D is just specifying the identifier and proof-of-possession > mechanism (aka "holder of key"), some modest discussion of example use > cases (beyond the mention of binding to "authentication tokens" that > appears in the Introduction) would be helpful. > > Presumably the TLS client stores this identifier keyed by TLS server > domain name and re-uses it in future TLS connections to that server (the > "storage model" needs to be discussed/specified)? When might a TLS client > change an established identifier? > > > (Some mention of these lifecycle items is given in the PrivCons section > below) > > Is it to be remembered on first use? Is it to be updated in the > server-side store upon it changing? What are this identifier's overall > semantics? > > > > > The "r" and "s" fields contain an > > ECDSA [DSS] signature by the corresponding private key of "TLS > > Channel ID signature\x00" > > suggest.. > > > The "r" and "s" fields contain an ECDSA [DSS] signature by the > corresponding private key over this US-ASCII string (not including > quotes, and where "\x00" represents an octet containing all zero bits): > > "TLS Channel ID signature\x00" > > > ..although we should probably use ABNF (or the RFC5246 notation) to define > this string and its concatenation with the handshake message hashes. > > > > followed by the handshake hash(es) prior to > > the "EncryptedExtensions" message. > > hashes of both the client-sent and server-sent handshake messages, as seen > by the client? > > > > > > > Unlike many other TLS extensions, this extension does not establish > > properties of the session, only of the connection. When session > > resumption or session tickets [RFC5077] are used, the previous > > contents of this extension are irrelevant and only the values in the > > new handshake messages are considered. > > but presumably the same (long-lived?) TLS client identifier Q = (x,y) > used and only (r,s) are different ? > > Or are new values for all of {x,y,r,s} calculated? [ "no" is implied by > the Introduction and Priv. Cons. ] > > > > > > 5. Security Considerations > > > > There are four classes of attackers against which we consider our > > security guarantees: passive network attackers, active network > > attackers, active network attackers with misissued certificates and > > attackers in possession of the legitimate server's private key. > > > > First, we wish to guarantee that we don't disclose the Channel ID to > > passive or active network attackers. > > why? simply for privacy reasons? > > Or is the main concern that the "channel id" will be used by app layers, > eg in HTTP cookies, in order to bind objects to a particular TLS > client-server pair, and thus the "channel id" should be protected as a > secret? > > If the "channel id" is simply included in cookies, and those cookies are > leaked in the clear (which is not uncommon for a variety of reasons), then > the "channel id" will potentially be divulged in any case. > > Since the channel id is a public key, the server could include some nonce, > encrypted by the channel id key, in messages to the client, the client > could decrypt it, then encrypt the nonce with its private key, and include > that on messages back to the server, which the server could decrypt with > the client's public key and verify. doing something like that could help > keep the channel id itself out of these messages and their potentially > leaky components (such as cookies) > > if servers who rely upon the Channel ID always do so with a corresponding > proof-of-possession of the private key on the part of the TLS client (and > they perform the requisite checks), then what are the security (as opposed > to privacy) issues if the Channel ID is observable by others? I suppose it > depends on the app-layer use cases employing the "channel id". > > > > We do this by sending a > > constant-length Channel ID under encryption. However, since the > > Channel ID may be transmitted before the server's Finished message is > > received, it's possible that the server isn't in possession of the > > certificate that it presented. > > do you mean in possession of the corresponding private key (to the cert it > presented) ? > > > > > In this situation, an active attacker > > could cause a Channel ID to be transmitted under a random key in a > > cipher suite of their choosing. Therefore we limit the permissible > > cipher suites to those where decrypting the message is infeasible. > > these TLS cipher suites should be explicitly listed. > > > > > > Even with this limit, an active attacker can cause the Channel ID to > > be transmitted in a non-forward-secure manner. Subsequent disclosure > > of the server's private key would allow previously recorded Channel > ^ > legitimate > > > > IDs to be decrypted. > > > > Second, we wish to guarantee that none of the first three attackers > > can terminate/hijack a TLS connection and impersonate a Channel ID > > from that connection when connecting to the legitimate server. We > > assume that TLS provides sufficient security to prevent a connection > > from being hijacked once established by these attackers. > > did you mean to say.. > > We assume that TLS provides sufficient security to prevent these attackers > from being able to hijack the TLS connection. > > ..? > > > > > > An active > > attacker with a misissued certificate can successfully terminate the > > TLS connection and decrypt the Channel ID. > > need a definition and perhaps reference for "mis-issued" cert. > > > > However, as the signature > > covers the handshake hashes, and therefore the server's certificate, > > it wouldn't be accepted by the true server. > > this essentially means that a attacker server with a mis-issued > certificate cannot act as a real-time TLS proxy between the TLS client and > legit server, yes? > > But otherwise such an attacker could potentially mount an impersonation of > the legitimate server, yes? > > > > > Against an attacker with the legitimate server's private key we can > > provide the second guarantee only if the legitimate server uses a > > forward-secret cipher suite, otherwise the attacker can hijack the > > connection. > > > here "connection" means the long-lived "security association" between TLS > client and legit server, yes? > > the known forward-secret TLS cipher suites should perhaps be listed in an > appendix. > > > > > snip > > > > 6. Privacy Considerations > > > > The TLS layer does its part in protecting user privacy by > > transmitting the Channel ID public key under encryption. Higher > > levels of the stack must ensure that the same Channel ID is not used > > with different servers in such a way as to provide a linkable > > identifier. For example, a user-agent must use different Channel IDs > > for communicating with different servers. > > There's ostensibly privacy implications worth mentioning in that each > distinct TLS client stack one wields with a particular TLS server will > generate a distinct "channel id" (TLS-SAID), even if they are "behind" one > IP address from the server's perspective. > > > User-agents must also > > ensure that Channel ID state can be reset by the user in the same way > > as other identifiers, i.e. cookies. > > Yes, because otherwise this becomes a "super cookie" mech. > > This implies dependent app-layers will need to be able to handle > dynamically changing "channel id" (TLS-SAID)s. > > > > > > However, there are some security concerns that could result in the > > disclosure of a client's Channel ID to a network attacker. This is > > covered in the Security Considerations section. > > > snip > > > > 7. IANA Considerations > > > > This document requires IANA to update its registry of TLS extensions > > to assign an entry referred to here as "channel_id". > > > > This document also requires IANA to update its registry of TLS > > handshake types to assign an entry referred to here as > > "encrypted_extensions". > > > snip > > > > 8. References > > > > 8.1. Normative References > > > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > > > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security > > (TLS) Protocol Version 1.2", RFC 5246, August 2008. > > > > [DSS] National Institute of Standards and Technology, "FIPS > > 186-3: Digital Signature Standard". > ^ > Issued June, 2009 > > > > > > 8.2. Informative References > > > > [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, > > "Transport Layer Security (TLS) Session Resumption without > > Server-Side State", RFC 5077, January 2008. > > > > > > > --- > end > > > > --047d7b675dd207c8c704e0494c9c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jeff, thanks so much for your comments. I'll address a= ll the typos/wording changes etc. in a new draft. Below my answers to your = high-level comments.

On Tue, Apr 30, 2013 at 5:11 PM, =3DJeffH <Jeff.Hodges@kingsmo= untain.com> wrote:
[ for best results use a fixed-pitch font ]

Here's some comments on draft-balfanz-tls-channelid, I hope they're= helpful.

=3DJeffH
------

High-level comments:

1. EncryptedExtensions modification to the TLS handshake ought to be split = out into a separate spec.

2. What are the ramifications if the TLS WG does not adopt an EncryptedExte= nsions mechanism? =A0I.e., what are the downsides to the "channel id&q= uot; being publicly exposed, i.e., the security ones as well as the privacy= implications?

I don't believe there should be securi= ty implications, but I feel fairly strongly - for privacy reasons - that th= e channel id message belongs in the encrypted part of the handshake. Whethe= r or not that's riding on top of the EncryptedExtension mechanism (whic= h indeed has been discussed separately) is something that I'm happy to = discuss. I'm planning to go to IETF 87 in Berlin. Maybe we can discuss = there?
=A0
3. In my view, this spec defines how a TLS c= lient generates and subsequently wields a unique client identifier/key with= a particular TLS server over multiple TLS connections (in parallel and ser= ially). Thus it is more about creating a "security association" b= etween the client and server (eg, see definitions for the latter, as well a= s "channel", in RFC4949). Thus I would not use the term "cha= nnel" for this mechanism. Also, TLS unto itself is creating a cryptogr= aphic channel between client and server and thus using the channel term for= this mech seems ripe for confusion. =A0This comment implies some re-writin= g of the introduction (I've made some modest suggestions below). =A0Per= haps "TLS Security Association ID" (TLS-SAIDs) ?

I'm using "channel" in the s= ense of formal access control logics, for example as it's used here:=A0= http://homepages.inf.ed.ac.uk/gdp/publications/Calculus_for= _Access_Control.pdf (I don't know what newfangled nomenclature peop= le have introduced in RFC4949 - can I cite historical precedence? :-)

A channel is something through with a principal can sen= d messages. When you receive a message, you can tell which channel it has c= ome through. In this sense, a cryptographic key (that signs messages) becom= es a "channel". Yes, a TLS connection is a channel, but so is the= client key we're using here. The former is a more short-lived channel,= the latter is longer-lived. I think RFC5929 uses "channel" in th= is sense, too, since it views the server's keys as a channel (at least = for the=A0tls-server-end-poi= nt binding type).
=A0
4. The lifecycle for the unique client ident= ifier (aka "channel id") ought to be more fully discussed/specifi= ed in main portion of the spec. Presently it's sprinkled in the introdu= ction and the privacy considerations.

Ok - I see how it currently reads and will= try to make improvements. We have actually moved in Chrome to not expiring= the keys automatically (although the user can still rotate them through th= e UI).
=A0

5. There would seem to be considerations for applications in terms of relia= nce on the persistence of a given "channel id" and provisions for= the "channel id" changing or disappearing, e.g. if an app levera= ges "channel id" to bind long-lived app-layer objects (eg cookies= ) to the TLS client, and these implications/issues should be discussed.

Ok - I'll try and add something for th= at.
=A0
6. This mechanism should be compared/contrasted with TLS Channel Binding RF= C5929. They don't appear to be mutually exclusive on first thought. Wha= t are the semantics if they are both employed by an application? =A0For wha= t might one employ one or the other or both concurrently?

In my view this is simply another binding type = that could be added to RFC5929. In RFC5929, there is already a tls-server-e= nd-point binding type that is simply the hash of the server cert. A channel= -id-binding-type could be defined as the dual of that for the client side. = But just as the TLS spec - not RFC5929 - explains how a server cert is &quo= t;glued" to a TLS connection (i.e., only someone possessing the corres= ponding private key can "wield" the server cert), we need a diffe= rent spec - this one, not RFC 5929 - that explains how the channel id keys = are "glued" to a TLS connection. These can all co-exist.

7. This is a "trust on first use (TOFU)" mechanism. This should b= e mentioned/discussed explicitly.

It do= esn't have to be a TOFU mechanism. I can imagine other protocols that i= ntroduce the channel id in a secure manner to the server. See, e.g.,=A0http://homes.cs.washington.edu/~aczeskis/research/pubs/czes= kis-phoneauth-ccs12.pdf
=A0
Dirk.




Detailed comments/questions:

> Network Working Group =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 D. Balfanz
> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 R. Hamilton
> Expires: May 12, 2013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Google Inc
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 November 8, 2012
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Transport Layer Security (TLS) Channel = IDs
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-balfanz-tls-channelid= -00
>
> Abstract
>
> =A0 =A0This document describes a Transport Layer Security (TLS) extens= ion
> =A0 =A0for identifying client machines at the TLS layer without using = bearer
> =A0 =A0tokens.
>
snip
>
> Table of Contents
>
> =A0 =A01. =A0Introduction . . . . . . . . . . . . . . . . . . . . . . = . . . =A03
> =A0 =A02. =A0Why not client certificates =A0. . . . . . . . . . . . . = . . . . =A04
> =A0 =A03. =A0Requirements Notation =A0. . . . . . . . . . . . . . . . = . . . . =A05
> =A0 =A04. =A0Channel ID Extension . . . . . . . . . . . . . . . . . . = . . . =A06
> =A0 =A05. =A0Security Considerations =A0. . . . . . . . . . . . . . . = . . . . =A08
> =A0 =A06. =A0Privacy Considerations . . . . . . . . . . . . . . . . . = . . . =A09
> =A0 =A07. =A0IANA Considerations =A0. . . . . . . . . . . . . . . . . = . . . . 10
> =A0 =A08. =A0References . . . . . . . . . . . . . . . . . . . . . . . = . . . 11
> =A0 =A0 =A08.1. =A0Normative References . . . . . . . . . . . . . . . = . . . . 11
> =A0 =A0 =A08.2. =A0Informative References . . . . . . . . . . . . . . = . . . . 11
> =A0 =A0Appendix A. =A0Acknowledgements =A0. . . . . . . . . . . . . . = . . . . 12
> =A0 =A0Authors' Addresses . . . . . . . . . . . . . . . . . . . . = . . . . 13
>
snip
>
> 1. =A0Introduction
>
> =A0 =A0Many applications on the Internet use _bearer tokens_ to authen= ticate
> =A0 =A0clients to servers. =A0The most prominent example is the HTTP-b= ased
> =A0 =A0World Wide Web, which overwhelmingly uses HTTP cookies to
> =A0 =A0authenticate client requests. =A0Other examples include OpenID = or SAML
> =A0 =A0assertions, and OAuth tokens. =A0All these have in common that = the
> =A0 =A0_bearer_ of the HTTP cookie or authentication token is granted = access
> =A0 =A0to a protected resource, regardless of the channel over which t= he
> =A0 =A0token is presented, or who presented it.
>
> =A0 =A0As a result, an adversary that manages to steal a bearer token = from a
> =A0 =A0client can impersonate that client to services that require the=
> =A0 =A0token.
>
> =A0 =A0This document describes a light-weight mechanism for establishi= ng a
> =A0 =A0_cryptographic channel_ between client and server.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^ =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0security association =A0 =A0 =A0 =A0, denote= d by an ECC public key.


> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A server can
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0For example,


> =A0 =A0choose to bind authentication tokens to this channel, thus rend= ering
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 association

> =A0 =A0the theft of authentication tokens fruitless - tokens must be s= ent
> =A0 =A0over the channel to which they are bound (i.e., by the client t= o
> =A0 =A0which they were issued) or else they will be ignored.

suggest..

=A0 ..tokens bound to the security association will be ignored by the
=A0 if they are not sent by the legitimate client.

>
> =A0 =A0This document does not prescribe _how_ authentication tokens ar= e
> =A0 =A0bound to the underlying channel. =A0Rather, it prescribes how a= client
> =A0 =A0can establish a long-lived channel with a server.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0security association=

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Such a channel
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 an association

> =A0 =A0persists across HTTP requests, TLS connections, and even multip= le TLS
> =A0 =A0sessions, as long as the same client communicates with the same=
> =A0 =A0server.
>
> =A0 =A0The basic idea is that the client proves, during the TLS handsh= ake,
> =A0 =A0possession of a private key. =A0The corresponding public key be= comes
> =A0 =A0the "Channel ID" that identifies this TLS connection.= =A0Clients should
> =A0 =A0re-use the same private/public key pair across subsequent TLS > =A0 =A0connections to the same server, thus creating TLS connections t= hat
> =A0 =A0share the same Channel ID.
>
> =A0 =A0Using private/public key pairs to define a channel (as opposed = to,
> =A0 =A0say, an HTTP session cookie) has several advantages: One, the > =A0 =A0credential establishing the channel (the private key) is never = sent
> =A0 =A0from client to server, thus removing it from the reach of
> =A0 =A0eavesdroppers in the network. =A0Two, clients can choose to imp= lement
> =A0 =A0cryptographic operations in a secure hardware module, which fur= ther
> =A0 =A0removes the private key from the reach of eavesdroppers residin= g on
> =A0 =A0the client itself.
>
snip
>
> 2. =A0Why not client certificates
>
> =A0 =A0TLS already supports a means of identifying clients without usi= ng
> =A0 =A0bearer tokens: client certificates. =A0However, a number of pro= blems
> =A0 =A0with using client certificates motivated the development of an<= br> > =A0 =A0alternative.
>
> =A0 =A0Most importantly, it's not acceptable for a client identifi= er to be

what are the threats if a long-term, asymmetric-key-based client identifier= is sent in the clear during TLS handshake? =A0Is it mostly a privacy conce= rn? =A0Or is it because of anticipated use cases of binding app-layer info = to the TLS layer?



> =A0 =A0transmitted in the clear and client certificates in TLS are sen= t
> =A0 =A0unencrypted. =A0Although we could also define a change to the T= LS state
> =A0 =A0machine to move the client certificates under encryption, such<= br> > =A0 =A0changes eliminate most of the benefits of reusing something tha= t's
> =A0 =A0already defined.
>
> =A0 =A0TLS client certificates are also defined to be part of the sess= ion
> =A0 =A0state. =A0This turns session resumption secrets into equivalent= barer
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bearer
> =A0 =A0tokens; completely defeating our objectives.

I'm curious here... =A0RFC5246 Appendix F.1.4. indicates..

=A0 =A0When a connection is established by resuming a session, new
=A0 =A0ClientHello.random and ServerHello.random values are hashed with the=
=A0 =A0session's master_secret. =A0Provided that the master_secret has = not
=A0 =A0been compromised and that the secure hash operations used to produce=
=A0 =A0the encryption keys and MAC keys are secure, the connection should b= e
=A0 =A0secure and effectively independent from previous connections.

..so I'm not sure how "session resumption secrets" are "= equivalent bearer tokens" ?



>
> =A0 =A0Client-certificates typically identify a user, while we seek to=
> =A0 =A0identify machines. =A0Since they are not, conceptually, mutuall= y
> =A0 =A0exclusive and as only a single client certificate can be provid= ed in
> =A0 =A0TLS, we don't want to consume that single slot and eliminat= e the
> =A0 =A0possibility of also using existing client certificates.
>
> =A0 =A0Client certificates are implemented in TLS as X.509 certificate= s and
> =A0 =A0we don't wish to require servers to parse arbitrary ASN.1. = =A0ASN.1 is
> =A0 =A0a complex encoding that has been the source of several security=
> =A0 =A0vulnerabilities in the past and typical TLS servers can current= ly
> =A0 =A0avoid doing ASN.1 parsing.
>
> =A0 =A0X.509 certificates always include a signature, which would be a= self-
> =A0 =A0signature in this case. =A0Calculating and transmitting the sel= f-
> =A0 =A0signature is a waste of computation and network traffic in our = use.
> =A0 =A0Although we could define a null signature algorithm with an emp= ty
> =A0 =A0signature, such deviations from X.509 eliminate many of the ben= efits
> =A0 =A0of reusing something that is already implemented.
>
> =A0 =A0Finally, client certificates trigger significant server-side > =A0 =A0processing by default and often need to be stored in their enti= rety
> =A0 =A0for the duration of the connection. =A0Since this design is int= ended to
> =A0 =A0be widely used, it allows servers to retain only a cryptographi= c hash
> =A0 =A0of the client's public key after the handshake completes. >
snip
>
> 4. =A0Channel ID Extension
>
> =A0 =A0A new extension type ("channel_id(TBD)") is defined a= nd MAY be
> =A0 =A0included by the client in its "ClientHello" message. = =A0If, and only
> =A0 =A0if, the server sees this extension in the "ClientHello&quo= t;, it MAY
> =A0 =A0choose to echo the extension in its "ServerHello". = =A0In both cases,
> =A0 =A0the "extension_data" field MUST be empty.
>
> =A0 =A0enum {
> =A0 =A0 =A0channel_id(TBD), (65535)
> =A0 =A0} ExtensionType;
>
> =A0 =A0A new handshake message type ("encrypted_extensions(TBD)&q= uot;) is
> =A0 =A0defined. =A0If the server included a "channel_id" ext= ension in its
> =A0 =A0"ServerHello" message, the client MUST verify that th= e selected
> =A0 =A0cipher suite is sufficiently strong. =A0If the cipher suite pro= vides <
> =A0 =A080-bits of security, the client MUST abort the handshake with a= fatal
> =A0 =A0"illegal_parameter" alert. =A0Otherwise, the client M= UST send an
> =A0 =A0"EncryptedExtensions" message after its "ChangeC= ipherSpec" and before
> =A0 =A0its "Finished" message.
>
> =A0 =A0enum {
> =A0 =A0 =A0encrypted_extensions(TBD), (65535)
> =A0 =A0} HandshakeType;
>
> =A0 =A0Therefore a full handshake with "EncryptedExtensions"= has the
> =A0 =A0following flow (contrast with section 7.3 of RFC 5246 [RFC5246]= ):
>
> =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Server
>
> =A0 =A0ClientHello (ChannelID extension) =A0 -------->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ServerHello
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0(ChannelID extension)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Certificate*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 ServerKeyExchange*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0CertificateRequest*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <--= ------ =A0 =A0 =A0ServerHelloDone
> =A0 =A0Certificate*
> =A0 =A0ClientKeyExchange
> =A0 =A0CertificateVerify*
> =A0 =A0[ChangeCipherSpec]
> =A0 =A0EncryptedExtensions
> =A0 =A0Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [ChangeCipherSpec]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <--= ------ =A0 =A0 =A0 =A0 =A0 =A0 Finished
> =A0 =A0Application Data =A0 =A0 =A0 =A0 =A0 =A0 <-------> =A0 = =A0 Application Data
>
> =A0 =A0An abbreviated handshake with "EncryptedExtensions" h= as the following
>
>
>
> Balfanz & Hamilton =A0 =A0 =A0 =A0Expires May 12, 2013 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[Page 6]
>
> Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 =A0 TLS Channel ID =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0November 2012
>
>
> =A0 =A0flow:
>
> =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Server
>
> =A0 =A0ClientHello (ChannelID extension) =A0 =A0-------->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ServerHello
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0(ChannelID extension)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [ChangeCipherSpec]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= ;-------- =A0 =A0 =A0 =A0 =A0 =A0Finished
> =A0 =A0[ChangeCipherSpec]
> =A0 =A0EncryptedExtensions
> =A0 =A0Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-------->= ;
> =A0 =A0Application Data =A0 =A0 =A0 =A0 =A0 =A0 =A0<-------> =A0= =A0Application Data
>
> =A0 =A0The "EncryptedExtensions" message contains a series o= f "Extension"
> =A0 =A0structures (see section 7.4.1.4 of RFC 5246 [RFC5246]

the below should be separate section...


> =A0 =A0If the server included a "channel_id" extension in it= s "ServerHello"
> =A0 =A0message, the client MUST include an "Extension" with = "extension_type"

suggest..

..the client MUST include, within the EncryptedExtensions message, an "= ;Extension" with "extension_type"...




> =A0 =A0equal to "channel_id(TBD)". =A0The "extension_da= ta" of which has the
> =A0 =A0following format:
>
> =A0 =A0struct {
> =A0 =A0 =A0opaque x[32];
> =A0 =A0 =A0opaque y[32];
> =A0 =A0 =A0opaque r[32];
> =A0 =A0 =A0opaque s[32];
> =A0 =A0} ChannelIDExtension;
>
> =A0 =A0The contents of each of "x", "y", "r&q= uot; and "s" is a 32-byte, big-
> =A0 =A0endian number. =A0The "x" and "y" fields co= ntain the affine coordinates
> =A0 =A0of a P-256 [DSS] curve point.

you mean that the "x" and "y" fields (of the ChannelIDE= xtension struct) contain the =A0affine coordinates of a P-256 [DSS] curve p= oint comprising an ECC public key "Q" ?

[ where Q =3D dG, d =3D ECC private key, G is the curve base point, and oth= er elliptic curve "domain parameters" are as given in [DSS] for c= urve P-256, and the key pair is generated according to appendix B.4 in [DSS= ] aka FIPS-186-3 ? ]

So Q =3D (x,y) is the "channel id" per se ? =A0It should be made = explicit.


What's the lifecycle management of this identifier (ie "Q")? = =A0Is the TLS server (or the server-side app running on top of it) to remem= ber this identifier? =A0Is it to be mapped to other client-side identifying= information eg IP address, user data (eg account name), etc ? =A0 Even tho= ugh this I-D is just specifying the identifier and proof-of-possession mech= anism (aka "holder of key"), some modest discussion of example us= e cases (beyond the mention of binding to "authentication tokens"= that appears in the Introduction) would be helpful.

Presumably the TLS client stores this identifier keyed by TLS server domain= name and re-uses it in future TLS connections to that server (the "st= orage model" needs to be discussed/specified)? =A0When might a TLS cli= ent change an established identifier?


(Some mention of these lifecycle items is given in the PrivCons section bel= ow)

Is it to be remembered on first use? =A0Is it to be updated in the server-s= ide store upon it changing? =A0What are this identifier's overall seman= tics?



> =A0 =A0The "r" and "s" fields contain an
> =A0 =A0ECDSA [DSS] signature by the corresponding private key of "= ;TLS
> =A0 =A0Channel ID signature\x00"

suggest..


=A0 The "r" and "s" fields contain an ECDSA [DSS] signa= ture by the
=A0 corresponding private key over this US-ASCII string (not including
=A0 quotes, and where "\x00" represents an octet containing all z= ero bits):

=A0 =A0 =A0 "TLS Channel ID signature\x00"


..although we should probably use ABNF (or the RFC5246 notation) to define = this string and its concatenation with the handshake message hashes.


> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0followed by the= handshake hash(es) prior to
> =A0 =A0the "EncryptedExtensions" message.

hashes of both the client-sent and server-sent handshake messages, as seen = by the client?



>
> =A0 =A0Unlike many other TLS extensions, this extension does not estab= lish
> =A0 =A0properties of the session, only of the connection. =A0When sess= ion
> =A0 =A0resumption or session tickets [RFC5077] are used, the previous<= br> > =A0 =A0contents of this extension are irrelevant and only the values i= n the
> =A0 =A0new handshake messages are considered.

but presumably the same (long-lived?) TLS client identifier Q =3D (x,y) =A0= used and only (r,s) are different ?

Or are new values for all of {x,y,r,s} calculated? =A0[ "no" is i= mplied by the Introduction and Priv. Cons. ]




> 5. =A0Security Considerations
>
> =A0 =A0There are four classes of attackers against which we consider o= ur
> =A0 =A0security guarantees: passive network attackers, active network<= br> > =A0 =A0attackers, active network attackers with misissued certificates= and
> =A0 =A0attackers in possession of the legitimate server's private = key.
>
> =A0 =A0First, we wish to guarantee that we don't disclose the Chan= nel ID to
> =A0 =A0passive or active network attackers.

why? =A0simply for privacy reasons?

Or is the main concern that the "channel id" will be used by app = layers, eg in HTTP cookies, in order to bind objects to a particular TLS cl= ient-server pair, and thus the "channel id" should be protected a= s a secret?

If the "channel id" is simply included in cookies, and those cook= ies are leaked in the clear (which is not uncommon for a variety of reasons= ), then the "channel id" will potentially be divulged in any case= .

Since the channel id is a public key, the server could include some nonce, = encrypted by the channel id key, in messages to the client, the client coul= d decrypt it, then encrypt the nonce with its private key, and include that= on messages back to the server, which the server could decrypt with the cl= ient's public key and verify. doing something like that could help keep= the channel id itself out of these messages and their potentially leaky co= mponents (such as cookies)

if servers who rely upon the Channel ID always do so with a corresponding p= roof-of-possession of the private key on the part of the TLS client (and th= ey perform the requisite checks), then what are the security (as opposed to= privacy) issues if the Channel ID is observable by others? =A0I suppose it= depends on the app-layer use cases employing the "channel id".

> =A0 =A0We do this by sending a
> =A0 =A0constant-length Channel ID under encryption. =A0However, since = the
> =A0 =A0Channel ID may be transmitted before the server's Finished = message is
> =A0 =A0received, it's possible that the server isn't in posses= sion of the
> =A0 =A0certificate that it presented.

do you mean in possession of the corresponding private key (to the cert it = presented) ?



> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0In this= situation, an active attacker
> =A0 =A0could cause a Channel ID to be transmitted under a random key i= n a
> =A0 =A0cipher suite of their choosing. =A0Therefore we limit the permi= ssible
> =A0 =A0cipher suites to those where decrypting the message is infeasib= le.

these TLS cipher suites should be explicitly listed.


>
> =A0 =A0Even with this limit, an active attacker can cause the Channel = ID to
> =A0 =A0be transmitted in a non-forward-secure manner. =A0Subsequent di= sclosure
> =A0 =A0of the server's private key would allow previously recorded= Channel
=A0 =A0 =A0 =A0 =A0 =A0^
=A0 =A0 =A0 =A0legitimate


> =A0 =A0IDs to be decrypted.
>
> =A0 =A0Second, we wish to guarantee that none of the first three attac= kers
> =A0 =A0can terminate/hijack a TLS connection and impersonate a Channel= ID
> =A0 =A0from that connection when connecting to the legitimate server. = =A0We
> =A0 =A0assume that TLS provides sufficient security to prevent a conne= ction
> =A0 =A0from being hijacked once established by these attackers.

did you mean to say..

We assume that TLS provides sufficient security to prevent these attackers<= br> from being able to hijack the TLS connection.

..?




> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0An active
> =A0 =A0attacker with a misissued certificate can successfully terminat= e the
> =A0 =A0TLS connection and decrypt the Channel ID.

need a definition and perhaps reference for "mis-issued" cert.

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0However, as the signature
> =A0 =A0covers the handshake hashes, and therefore the server's cer= tificate,
> =A0 =A0it wouldn't be accepted by the true server.

this essentially means that a attacker server with a mis-issued certificate= cannot act as a real-time TLS proxy between the TLS client and legit serve= r, yes?

But otherwise such an attacker could potentially mount an impersonation of = the legitimate server, yes?

>
> =A0 =A0Against an attacker with the legitimate server's private ke= y we can
> =A0 =A0provide the second guarantee only if the legitimate server uses= a
> =A0 =A0forward-secret cipher suite, otherwise the attacker can hijack = the
> =A0 =A0connection.


here "connection" means the long-lived "security association= " between TLS client and legit server, yes?

the known forward-secret TLS cipher suites should perhaps be listed in an a= ppendix.


>
snip
>
> 6. =A0Privacy Considerations
>
> =A0 =A0The TLS layer does its part in protecting user privacy by
> =A0 =A0transmitting the Channel ID public key under encryption. =A0Hig= her
> =A0 =A0levels of the stack must ensure that the same Channel ID is not= used
> =A0 =A0with different servers in such a way as to provide a linkable > =A0 =A0identifier. =A0For example, a user-agent must use different Cha= nnel IDs
> =A0 =A0for communicating with different servers.

There's ostensibly privacy implications worth mentioning in that each d= istinct TLS client stack one wields with a particular TLS server will gener= ate a distinct "channel id" (TLS-SAID), even if they are "be= hind" one IP address from the server's perspective.

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 User-agents must also
> =A0 =A0ensure that Channel ID state can be reset by the user in the sa= me way
> =A0 =A0as other identifiers, i.e. cookies.

Yes, because otherwise this becomes a "super cookie" mech.

This implies dependent app-layers will need to be able to handle dynamicall= y changing "channel id" (TLS-SAID)s.


>
> =A0 =A0However, there are some security concerns that could result in = the
> =A0 =A0disclosure of a client's Channel ID to a network attacker. = =A0This is
> =A0 =A0covered in the Security Considerations section.
>
snip
>
> 7. =A0IANA Considerations
>
> =A0 =A0This document requires IANA to update its registry of TLS exten= sions
> =A0 =A0to assign an entry referred to here as "channel_id".<= br> >
> =A0 =A0This document also requires IANA to update its registry of TLS<= br> > =A0 =A0handshake types to assign an entry referred to here as
> =A0 =A0"encrypted_extensions".
>
snip
>
> 8. =A0References
>
> 8.1. =A0Normative References
>
> =A0 =A0[RFC2119] =A0Bradner, S., "Key words for use in RFCs to In= dicate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Requirement Levels", BCP 14, RFC 2119= , March 1997.
>
> =A0 =A0[RFC5246] =A0Dierks, T. and E. Rescorla, "The Transport La= yer Security
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 (TLS) Protocol Version 1.2", RFC 5246= , August 2008.
>
> =A0 =A0[DSS] =A0 =A0 =A0National Institute of Standards and Technology= , "FIPS
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 186-3: Digital Signature Standard". =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Issued June, 2009


>
> 8.2. =A0Informative References
>
> =A0 =A0[RFC5077] =A0Salowey, J., Zhou, H., Eronen, P., and H. Tschofen= ig,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Transport Layer Security (TLS) Sessi= on Resumption without
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Server-Side State", RFC 5077, January= 2008.
>
>
<snip/>

---
end




--047d7b675dd207c8c704e0494c9c-- From turners@ieca.com Wed Jul 3 10:12:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9111E80C5 for ; Wed, 3 Jul 2013 10:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.033 X-Spam-Level: X-Spam-Status: No, score=-102.033 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKQdD4hHcn+f for ; Wed, 3 Jul 2013 10:12:18 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.70.11]) by ietfa.amsl.com (Postfix) with ESMTP id E4C1C11E81F3 for ; Wed, 3 Jul 2013 10:12:14 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 2355A9BB0FAA8; Wed, 3 Jul 2013 12:12:01 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 0D5369BB0FA7A for ; Wed, 3 Jul 2013 12:12:01 -0500 (CDT) Received: from [173.73.135.86] (port=52293 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UuQbD-0005xO-Dp; Wed, 03 Jul 2013 12:12:11 -0500 Message-ID: <51D45B6A.90200@ieca.com> Date: Wed, 03 Jul 2013 13:12:10 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Sean Turner , jose@ietf.org References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.86]:52293 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= X-Mailman-Approved-At: Tue, 09 Jul 2013 08:44:46 -0700 Subject: [TLS] Fwd: Draft submission deadlines change X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 17:12:19 -0000 In case you're not on the IETF announcement list. spt -------- Original Message -------- Subject: Draft submission deadlines change Date: Tue, 02 Jul 2013 22:17:01 -0700 From: IETF Chair Reply-To: ietf@ietf.org To: IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From rsalz@akamai.com Tue Jul 9 11:01:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A8821F9DAD for ; Tue, 9 Jul 2013 11:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.156 X-Spam-Level: * X-Spam-Status: No, score=1.156 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_34=0.6, SARE_OBFU_PART_ICE=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8JhNrpA+i+N for ; Tue, 9 Jul 2013 11:01:16 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 66CD421F9D8A for ; Tue, 9 Jul 2013 11:01:16 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 82BF71653F4 for ; Tue, 9 Jul 2013 18:01:15 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 76B971653E0 for ; Tue, 9 Jul 2013 18:01:15 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 5291747BD2 for ; Tue, 9 Jul 2013 18:01:15 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.196]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 9 Jul 2013 14:01:14 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Tue, 9 Jul 2013 14:01:13 -0400 Thread-Topic: Errors in RFC5246 Thread-Index: Ac58ygbd4z3/DkAJRL2bdr4aRZHHNw== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFAD01@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Errors in RFC5246 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 18:01:21 -0000 I updated my parser for the "presentation language" in the SSL/TLS RFC's. = I used RFC5246. Here is an updated version: tlsgrammar.tar - https://docs.google.com/file/d/0B8YgrWYHqacSNDhCekgtWUVP= MW8/edit?usp=3Dsharing The presentation language definition in section four has a number of errors= . Unfortunately, I only remember those that are related to the choices in a= variant; they are documented in the README file. As for the examples in the RFC, looking at a diff between the original and= changes I made, I have the following errors: Section 4.7: "digitally-signed opaque" should be "digitally-signed struct"= And shouldn't that struct have a name? Section 7.4.1.2 in ClientHello: should cipher_suites be <1..2^16-1>? And "= struct {};" for the false case isn't valid; I suggest using a single semico= lon. Section 7.4.1.3 in ServerHello; same comment about "struct {};" vs ";" for = an empty variant. Section 7.4.1.4.1 should supported_signature_algorithms be <1..2^16-1> ? Section 7.4.2, "ASN.1Cert" is not a valid name since "." is the sub-field o= perator. I used "ASN1Cert" Section 7.4.4, in CertificateRequest: see above question about supported_si= gnature_algorithms Section 7.4.7.2 in ClientDiffieHellmanPublic: I made dh_Yc a type and used = it in the explicit case, since the current construct is not allowed by the = presentation language. Section 7.4.8 in CertificateVerify: The internal closing } is missing a sem= icolon. And shouldn't that struct have a name? Section A.4 in HandshakeProtocol : missing a comma after the finished item. Section A.4 in ClientHello: same comment about cipher_suites. Same note abo= ut the false case. Section A.4 in ServerHello: same comment about the false case. Section A.4.2: Same comment about ASN.1Cert changed to ASN1Cert Section A.4.2 in ServerKeyExchange: the language requires that signed_param= s be pulled out into its on struct. When I do that, it becomes obvious that= ServerDHParams is included twice, once plain and once part of the signed_p= arams item. Is that correct? Also, for the rsa/dh_dss/dh_rsa case, use a s= emicolon to indicate an empty choice. Section A.4.3 same comment about ClientDiffieHellmanPublic Thanks. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From dharkins@lounge.org Wed Jul 10 10:49:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DA121F9EE7 for ; Wed, 10 Jul 2013 10:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcscusA0TMg5 for ; Wed, 10 Jul 2013 10:49:46 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6821F9EDA for ; Wed, 10 Jul 2013 10:49:46 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 099CDA888004; Wed, 10 Jul 2013 10:49:41 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 10 Jul 2013 10:49:41 -0700 (PDT) Message-ID: <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com > References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> Date: Wed, 10 Jul 2013 10:49:41 -0700 (PDT) From: "Dan Harkins" To: "Salz, Rich" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "omh1835@rit.edu" , "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 17:49:50 -0000 On Mon, June 24, 2013 11:34 am, Salz, Rich wrote: [snip] > If you are trying to avoid CA's, then why not just use self-signed > certificates or similar like PGP? Or why not use a protocol that is already a work item of the TLS working group: http://tools.ietf.org/html/draft-ietf-tls-pwd-00 Dan. From rsalz@akamai.com Wed Jul 10 14:45:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05A521F9B95 for ; Wed, 10 Jul 2013 14:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.333 X-Spam-Level: X-Spam-Status: No, score=-4.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_ICE=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH0S1DWZ7znj for ; Wed, 10 Jul 2013 14:45:05 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 89FCD21F9B92 for ; Wed, 10 Jul 2013 14:45:05 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3EA0A27E85 for ; Wed, 10 Jul 2013 21:45:02 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 0783B27E58 for ; Wed, 10 Jul 2013 21:45:02 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id D6D10204B for ; Wed, 10 Jul 2013 21:45:01 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.196]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 10 Jul 2013 17:45:01 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Wed, 10 Jul 2013 17:45:00 -0400 Thread-Topic: Errors in RFC5246 Thread-Index: Ac58ygbd4z3/DkAJRL2bdr4aRZHHNwA68QhA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB353@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Errors in RFC5246 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:45:10 -0000 In addition to the errors below, I found a few other questionable items. Section 7.4.1.2, in ClientHello: where does extensions_present come from? Section 7.4.1.3 in ServerHello: where does extensions_present come from? Section 7.4.8, in CertificateVerify: where does handshake_messages_length c= ome from? Section A.4.1 in ClientHello and in ServerHello: same question about extens= ions_present Section A.4.3 in CertificateVerify: same question about handshake_messages_= length Thanks. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA -----Original Message----- From: Salz, Rich=20 Sent: Tuesday, July 09, 2013 2:01 PM To: TLS@ietf.org (tls@ietf.org) Subject: Errors in RFC5246 I updated my parser for the "presentation language" in the SSL/TLS RFC's. = I used RFC5246. Here is an updated version: tlsgrammar.tar - https://docs.google.com/file/d/0B8YgrWYHqacSNDhCekgtWUVP= MW8/edit?usp=3Dsharing The presentation language definition in section four has a number of errors= . Unfortunately, I only remember those that are related to the choices in a= variant; they are documented in the README file. As for the examples in the RFC, looking at a diff between the original and= changes I made, I have the following errors: Section 4.7: "digitally-signed opaque" should be "digitally-signed struct"= And shouldn't that struct have a name? Section 7.4.1.2 in ClientHello: should cipher_suites be <1..2^16-1>? And "= struct {};" for the false case isn't valid; I suggest using a single semico= lon. Section 7.4.1.3 in ServerHello; same comment about "struct {};" vs ";" for = an empty variant. Section 7.4.1.4.1 should supported_signature_algorithms be <1..2^16-1> ? Section 7.4.2, "ASN.1Cert" is not a valid name since "." is the sub-field o= perator. I used "ASN1Cert" Section 7.4.4, in CertificateRequest: see above question about supported_si= gnature_algorithms Section 7.4.7.2 in ClientDiffieHellmanPublic: I made dh_Yc a type and used = it in the explicit case, since the current construct is not allowed by the = presentation language. Section 7.4.8 in CertificateVerify: The internal closing } is missing a sem= icolon. And shouldn't that struct have a name? Section A.4 in HandshakeProtocol : missing a comma after the finished item. Section A.4 in ClientHello: same comment about cipher_suites. Same note abo= ut the false case. Section A.4 in ServerHello: same comment about the false case. Section A.4.2: Same comment about ASN.1Cert changed to ASN1Cert Section A.4.2 in ServerKeyExchange: the language requires that signed_param= s be pulled out into its on struct. When I do that, it becomes obvious that= ServerDHParams is included twice, once plain and once part of the signed_p= arams item. Is that correct? Also, for the rsa/dh_dss/dh_rsa case, use a s= emicolon to indicate an empty choice. Section A.4.3 same comment about ClientDiffieHellmanPublic Thanks. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From rsalz@akamai.com Wed Jul 10 14:52:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911DD11E8139 for ; Wed, 10 Jul 2013 14:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.411 X-Spam-Level: X-Spam-Status: No, score=0.411 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, SARE_OBFU_PART_ICE=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o285jz6VLYH9 for ; Wed, 10 Jul 2013 14:52:31 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A211E8132 for ; Wed, 10 Jul 2013 14:52:29 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4C0FE1C4806 for ; Wed, 10 Jul 2013 21:52:27 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 410251C4803 for ; Wed, 10 Jul 2013 21:52:27 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 4C9B547BD2 for ; Wed, 10 Jul 2013 21:52:26 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.196]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Wed, 10 Jul 2013 17:52:25 -0400 From: "Salz, Rich" To: "Salz, Rich" , "TLS@ietf.org (tls@ietf.org)" Date: Wed, 10 Jul 2013 17:52:25 -0400 Thread-Topic: Errors in RFC5246 Thread-Index: Ac58ygbd4z3/DkAJRL2bdr4aRZHHNwA68QhAAABpAxA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB358@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB353@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B4BFB353@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Errors in RFC5246 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 21:52:35 -0000 And a (hopefully last) set of items. CompressionMethod is defined in Section 6.1 and Section 7.4.1.2; presumably= the second one should be removed. It is also defined in Section A.4.1 and Section A.6; presumably the second = one should be removed. -- =20 Principal Security Engineer Akamai Technology Cambridge, MA -----Original Message----- From: Salz, Rich [mailto:rsalz@akamai.com]=20 Sent: Wednesday, July 10, 2013 5:45 PM To: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] Errors in RFC5246 In addition to the errors below, I found a few other questionable items. Section 7.4.1.2, in ClientHello: where does extensions_present come from? Section 7.4.1.3 in ServerHello: where does extensions_present come from? Section 7.4.8, in CertificateVerify: where does handshake_messages_length c= ome from? Section A.4.1 in ClientHello and in ServerHello: same question about extens= ions_present Section A.4.3 in CertificateVerify: same question about handshake_messages_= length Thanks. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA -----Original Message----- From: Salz, Rich=20 Sent: Tuesday, July 09, 2013 2:01 PM To: TLS@ietf.org (tls@ietf.org) Subject: Errors in RFC5246 I updated my parser for the "presentation language" in the SSL/TLS RFC's. = I used RFC5246. Here is an updated version: tlsgrammar.tar - https://docs.google.com/file/d/0B8YgrWYHqacSNDhCekgtWUVP= MW8/edit?usp=3Dsharing The presentation language definition in section four has a number of errors= . Unfortunately, I only remember those that are related to the choices in a= variant; they are documented in the README file. As for the examples in the RFC, looking at a diff between the original and= changes I made, I have the following errors: Section 4.7: "digitally-signed opaque" should be "digitally-signed struct"= And shouldn't that struct have a name? Section 7.4.1.2 in ClientHello: should cipher_suites be <1..2^16-1>? And "= struct {};" for the false case isn't valid; I suggest using a single semico= lon. Section 7.4.1.3 in ServerHello; same comment about "struct {};" vs ";" for = an empty variant. Section 7.4.1.4.1 should supported_signature_algorithms be <1..2^16-1> ? Section 7.4.2, "ASN.1Cert" is not a valid name since "." is the sub-field o= perator. I used "ASN1Cert" Section 7.4.4, in CertificateRequest: see above question about supported_si= gnature_algorithms Section 7.4.7.2 in ClientDiffieHellmanPublic: I made dh_Yc a type and used = it in the explicit case, since the current construct is not allowed by the = presentation language. Section 7.4.8 in CertificateVerify: The internal closing } is missing a sem= icolon. And shouldn't that struct have a name? Section A.4 in HandshakeProtocol : missing a comma after the finished item. Section A.4 in ClientHello: same comment about cipher_suites. Same note abo= ut the false case. Section A.4 in ServerHello: same comment about the false case. Section A.4.2: Same comment about ASN.1Cert changed to ASN1Cert Section A.4.2 in ServerKeyExchange: the language requires that signed_param= s be pulled out into its on struct. When I do that, it becomes obvious that= ServerDHParams is included twice, once plain and once part of the signed_p= arams item. Is that correct? Also, for the rsa/dh_dss/dh_rsa case, use a s= emicolon to indicate an empty choice. Section A.4.3 same comment about ClientDiffieHellmanPublic Thanks. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From omh1835@g.rit.edu Thu Jul 11 02:42:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906B221F9298 for ; Thu, 11 Jul 2013 02:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eaol5vRfPMnW for ; Thu, 11 Jul 2013 02:42:45 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E121F9263 for ; Thu, 11 Jul 2013 02:42:45 -0700 (PDT) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MPR00K2WMYPUI@smtp-server.rit.edu> for tls@ietf.org; Thu, 11 Jul 2013 05:42:26 -0400 (EDT) Received: by mail-ie0-f176.google.com with SMTP id ar20so17308410iec.21 for ; Thu, 11 Jul 2013 02:42:25 -0700 (PDT) Received: by 10.42.232.200 with HTTP; Thu, 11 Jul 2013 02:42:25 -0700 (PDT) X-Received: by 10.50.6.16 with SMTP id w16mr13383934igw.29.1373535745820; Thu, 11 Jul 2013 02:42:25 -0700 (PDT) X-Received: by 10.50.6.16 with SMTP id w16mr13383932igw.29.1373535745737; Thu, 11 Jul 2013 02:42:25 -0700 (PDT) Date: Thu, 11 Jul 2013 12:42:25 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> Sender: omh1835@rit.edu To: Dan Harkins Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=047d7ba9797236198704e13936a0 X-RIT-Received-From: 209.85.223.176 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=RwL89OrcosLoczDMU43F13hyBZDRVDbPH05/Gc7X2ik=; b=PsApTpWU+UD2rxSYwoYsqT1lD0TdG4nX6evId6oATqaB6kRi3KP77XOtP5M+RCp76E kFMCpcCijdv/gmPQ2ZH0Jb6hHllitywHhOZBhn535YZssITdndyJrD5rcaVt4ldrgI+2 K1qpel1gdshmB27vOczUIIKsgnLuzjsFH8ilCt7w02AAnrXA742w0wM+kHi4wRXd7s6w YIioqBf9cPADDDOMWSdrlT/Yr3XXAyyaBEsLLOPdCbSW5PeMlRQGNZNLacn/93xnZ0YI 5FYwFi6n+7ze3Ia70z0UFskTcj1U3L/9Y2//Zl0Lq7o4TIYZUwtKCNaNIVLf6VzQGWdJ i2fA== X-Google-Sender-Auth: 5JKMOHqwxcSr4x-L6_TmyvFxDas X-Gm-Message-State: ALoCoQldA8TVx0U405Ie9S3IrOnoXmPIJvJjDb4u8XzG/n5ojDSnUKiI0om+9K3aVbpY8lJvGIZ2a0+Q7ApYJKNnM2HS5zG9UBjWOnGVl60BRXCc01X2/ZJpYRj0uWjUhRVuUQpofwqy References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:42:50 -0000 --047d7ba9797236198704e13936a0 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, I had a quick look at your work item, and I have some questions: What will be the consequences if the server data has be stolen? will the attacker be able to impersonate as the user? How will the password be stored in the server initially? How will you handle TLS termination that is used many websites to centralize the related measurements and protection against the common SSL attacks in one place, and to allow the application firewalls to validate and check the incoming requests for application-level attacks such as SQL injection and cross-site scripting? Thanks On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins wrote: > > On Mon, June 24, 2013 11:34 am, Salz, Rich wrote: > [snip] > > If you are trying to avoid CA's, then why not just use self-signed > > certificates or similar like PGP? > > Or why not use a protocol that is already a work item of the > TLS working group: > > http://tools.ietf.org/html/draft-ietf-tls-pwd-00 > > Dan. > > > > --047d7ba9797236198704e13936a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,

I had a quick look at you= r work item, and I have some questions:

What will be the consequences if the server data has be stolen? will the = attacker be able to impersonate as the user?

How will the password be stored in the serv= er initially?

How will you handle TLS = termination that is used many websites to centralize the related measuremen= ts and protection against the common SSL attacks in one place, and to allow= the application firewalls to validate and check the incoming requests for = application-level attacks such as SQL injection and cross-site scripting?

Thanks



On Wed, Jul 10, 2= 013 at 8:49 PM, Dan Harkins <dharkins@lounge.org> wrote:

On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
[snip]
> If you are trying to avoid CA's, then why not ju= st use self-signed
> certificates or similar like PGP?

=A0 Or why not use a protocol that is already a work item of the
TLS working group:

=A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-tls-pwd-00

=A0 Dan.




--047d7ba9797236198704e13936a0-- From dharkins@lounge.org Thu Jul 11 08:22:23 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4621F9B79 for ; Thu, 11 Jul 2013 08:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH+Dqk463KUd for ; Thu, 11 Jul 2013 08:22:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F178D21F9CAC for ; Thu, 11 Jul 2013 08:22:15 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 769D3A888004; Thu, 11 Jul 2013 08:22:15 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 11 Jul 2013 08:22:15 -0700 (PDT) Message-ID: <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net> In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> Date: Thu, 11 Jul 2013 08:22:15 -0700 (PDT) From: "Dan Harkins" To: "OMAR HASSAN (RIT Student)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:22:23 -0000 Hi Omar, On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote: > Hi Dan, > > I had a quick look at your work item, and I have some questions: > > What will be the consequences if the server data has be stolen? will the > attacker be able to impersonate as the user? Successfully stealing records from the server's password file will enable the thief to impersonate the client (back to the hacked server) for all stolen records. > How will the password be stored in the server initially? That is completely up to the server. > How will you handle TLS termination that is used many websites to > centralize the related measurements and protection against the common SSL > attacks in one place, and to allow the application firewalls to validate > and check the incoming requests for application-level attacks such as SQL > injection and cross-site scripting? This is really an operational question. At the risk of sounding flippant I guess I'd just say it will be handled in the best way possible. You claim in your draft that "UDKP aims to completely replace the TLS protocol." That is a much more ambitious goal and you will need to handle these sorts of issues. The tls-pwd draft just defines certificate-less ciphersuites that are resistant to dictionary attack (and are better than the various PSK ciphersuites) for use with the existing TLS protocol. regards, Dan. > Thanks > > > > On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins wrote: > >> >> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote: >> [snip] >> > If you are trying to avoid CA's, then why not just use self-signed >> > certificates or similar like PGP? >> >> Or why not use a protocol that is already a work item of the >> TLS working group: >> >> http://tools.ietf.org/html/draft-ietf-tls-pwd-00 >> >> Dan. >> >> >> >> > From ietf-ietf-tls@m.gmane.org Thu Jul 11 14:05:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578A011E8176 for ; Thu, 11 Jul 2013 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRZzrwD0K1Cw for ; Thu, 11 Jul 2013 14:05:05 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id EADF811E8170 for ; Thu, 11 Jul 2013 14:05:04 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UxO2x-000720-9R for tls@ietf.org; Thu, 11 Jul 2013 23:05:03 +0200 Received: from c-24-17-197-101.hsd1.wa.comcast.net ([24.17.197.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Jul 2013 23:05:03 +0200 Received: from eternaleye by c-24-17-197-101.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Jul 2013 23:05:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Thu, 11 Jul 2013 13:53:24 -0700 Lines: 54 Message-ID: References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-24-17-197-101.hsd1.wa.comcast.net User-Agent: KNode/4.10 rc3 Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 21:05:09 -0000 Dan Harkins wrote: > > Hi Omar, > > On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote: >> Hi Dan, >> >> I had a quick look at your work item, and I have some questions: >> >> What will be the consequences if the server data has be stolen? will the >> attacker be able to impersonate as the user? > > Successfully stealing records from the server's password file will > enable the thief to impersonate the client (back to the hacked server) > for all stolen records. > >> How will the password be stored in the server initially? > > That is completely up to the server. > >> How will you handle TLS termination that is used many websites to >> centralize the related measurements and protection against the common SSL >> attacks in one place, and to allow the application firewalls to validate >> and check the incoming requests for application-level attacks such as SQL >> injection and cross-site scripting? > > This is really an operational question. At the risk of sounding flippant > I guess I'd just say it will be handled in the best way possible. > > You claim in your draft that "UDKP aims to completely replace the TLS > protocol." That is a much more ambitious goal and you will need to handle > these sorts of issues. The tls-pwd draft just defines certificate-less > ciphersuites that are resistant to dictionary attack (and are better than > the various PSK ciphersuites) for use with the existing TLS protocol. I'd like to also point out: TLS-SRP: https://tools.ietf.org/html/rfc5054 TLS-AugPAKE: https://tools.ietf.org/html/draft-shin-tls-augpake-00 Both are: * Password-authenticated * Do not involve CAs at all * Do not allow a compromised server to impersonate the user - Zero-knowledge password proofs are rather useful * Are designed to work with TLS, rather than replace it wholesale While RFC 5054 is Informational rather than Standards track, it is supported by OpenSSL since 1.0.0h and 1.0.1 (https://www.openssl.org/news/news.html) and GnuTLS since at least 2007. From omh1835@g.rit.edu Fri Jul 12 04:37:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8621F9D46 for ; Fri, 12 Jul 2013 04:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eovoEDsw7m8i for ; Fri, 12 Jul 2013 04:37:28 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id F262B21F9F83 for ; Fri, 12 Jul 2013 04:37:27 -0700 (PDT) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MPT00FCTMYD7F@smtp-server.rit.edu> for tls@ietf.org; Fri, 12 Jul 2013 07:37:26 -0400 (EDT) Received: by mail-ie0-f182.google.com with SMTP id s9so20353699iec.41 for ; Fri, 12 Jul 2013 04:37:25 -0700 (PDT) Received: by 10.42.232.200 with HTTP; Fri, 12 Jul 2013 04:37:25 -0700 (PDT) X-Received: by 10.43.139.5 with SMTP id iu5mr12473575icc.107.1373629045805; Fri, 12 Jul 2013 04:37:25 -0700 (PDT) X-Received: by 10.43.139.5 with SMTP id iu5mr12473572icc.107.1373629045713; Fri, 12 Jul 2013 04:37:25 -0700 (PDT) Date: Fri, 12 Jul 2013 14:37:25 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net> Sender: omh1835@rit.edu To: Dan Harkins Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=001a11c2e9b852c29d04e14eefa5 X-RIT-Received-From: 209.85.223.182 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=2agZn8ny+R5sJGXlJGab6jwXxfRxUxwkDhpM9DAuyss=; b=Urmby77sErOG6v4SlJxf3AabODaPNlMknwNNJ7fa2Vs5uSHeXPyhH/0LyqG5G9WGai iNFTydCg5OBQoi0HzhffSxBDXv10PIidKsDJF+xogyI8yFYDlV/2jLswiX+ZhSVuEMcv +l3pfnC9r18VfkOFfnEE3yU+xUsuyOtIa7GY/BGZTy/qaDqW/JTdxCYV7GJF1RFpCAKN O1oCcMILuHDu92OoBDQSalAnWkPVATGIhoJ2FAXpSbxPTEbYhe3oK7+t3FHrYaumClck PPT/Xt1kehKwJrHrPtdgdygwyWC2t7D9kP3Y8ztpqdgvmgPmBv04BSLepaZ3x6h4+Jp5 1bNA== X-Google-Sender-Auth: N1XPuTeUqc6DI-4PPZPSbD5kljU X-Gm-Message-State: ALoCoQlLi8UXeoqDecTnfw6VgsKfRT3odj19HsxbCr6wDNTIYp6naXY3QBHuRww2xGVPBMH1zhCC3g3nq2hyEb1D9gicvKYnMn59hxhYMdkmT2ie4H+sELYgbfzaZH54XBo+OtG977YH References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:37:32 -0000 --001a11c2e9b852c29d04e14eefa5 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, I believe that your protocol will better suit for customized applications, but when it comes to websites you will definitely face those issues that I took about. It's very common that a SQL injection attack against the website would give the attacker the opportunity to steal database records, which will allow the attacker to impersonate the client (I think TLS-SRP adds a little complexity to protect against that scenario, I am sure you can improve this part in your protocol) Also TLS termination is very important, and must be supported by the protocol, and the first challenge in that regard is that the load balancer where the TLS connection should be terminated will not have access to the server database, and I think without access to the server database you will not be able to terminate the encrypted connection. Regarding UDKP, I believe that the only valid attack against it is during the registration. In that case using an initial TLS authenticated connection will solve this issue, and for all later usages there is no need to be dependent on certificate authorities. In UDKP, if the server data has been stolen, the attacker will get only the public key, and he will not be able to impersonate the client as he will need the private key. And regarding TLS termination, the load balancer could use the user public key to terminate the encrypted connection, and the let the server authenticate the user. You can refer to section 5.2 in the draft: http://tools.ietf.org/html/draft-omar-tls-udkp-01#section-5.2 In the coming version of the draft I will put a detailed analysis for the attack scenarios. On Thu, Jul 11, 2013 at 6:22 PM, Dan Harkins wrote: > > Hi Omar, > > On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote: > > Hi Dan, > > > > I had a quick look at your work item, and I have some questions: > > > > What will be the consequences if the server data has be stolen? will the > > attacker be able to impersonate as the user? > > Successfully stealing records from the server's password file will > enable the thief to impersonate the client (back to the hacked server) > for all stolen records. > > > How will the password be stored in the server initially? > > That is completely up to the server. > > > How will you handle TLS termination that is used many websites to > > centralize the related measurements and protection against the common SSL > > attacks in one place, and to allow the application firewalls to validate > > and check the incoming requests for application-level attacks such as SQL > > injection and cross-site scripting? > > This is really an operational question. At the risk of sounding flippant > I guess I'd just say it will be handled in the best way possible. > > You claim in your draft that "UDKP aims to completely replace the TLS > protocol." That is a much more ambitious goal and you will need to handle > these sorts of issues. The tls-pwd draft just defines certificate-less > ciphersuites that are resistant to dictionary attack (and are better than > the various PSK ciphersuites) for use with the existing TLS protocol. > > regards, > > Dan. > > > Thanks > > > > > > > > On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins > wrote: > > > >> > >> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote: > >> [snip] > >> > If you are trying to avoid CA's, then why not just use self-signed > >> > certificates or similar like PGP? > >> > >> Or why not use a protocol that is already a work item of the > >> TLS working group: > >> > >> http://tools.ietf.org/html/draft-ietf-tls-pwd-00 > >> > >> Dan. > >> > >> > >> > >> > > > > --001a11c2e9b852c29d04e14eefa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Dan,=A0

I believe that your protocol will better suit for customized applications, but when it comes to websites you = will definitely face those issues that I took about.

=A0

It's very common that= a SQL injection attack against the website would give the attacker the opportunit= y to steal database records, which will allow the attacker to impersonate the cl= ient (I think TLS-SRP adds a little complexity to protect against that scenario,= I am sure you can improve this part in your protocol)

=A0

Also TLS termination is v= ery important, and must be supported by the protocol, and the first challenge i= n that regard is that the load balancer where the TLS connection should be terminated will not have access to the server database, and I think without= access to the server database you will not be able to terminate the encrypted connection.

=A0

Regarding UDKP, I believe= that the only valid attack against it is during the registration. In that case using= an initial TLS authenticated connection will solve this issue, and for all lat= er usages there is no need to be dependent on certificate authorities.

=A0

In UDKP, if the server da= ta has been stolen, the attacker will get only the public key, and he will not be = able to impersonate the client as he will need the private key= . And regarding TLS termination, the load balancer could use the user public key to terminate the encrypted connection, and the let the server authenticate the user. You can refer to section 5.2 in the draft<= span lang=3D"AR-EG" dir=3D"RTL" style=3D"font-family:Arial,sans-serif">:

http://tools.ietf.org/html= /draft-omar-tls-udkp-01#section-5.2

In the coming version of = the draft I will put a detailed analysis for the attack scenarios.



On Thu,= Jul 11, 2013 at 6:22 PM, Dan Harkins <dharkins@lounge.org> wrote:

=A0 Hi Omar,

On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote:
> Hi Dan,
>
> I had a quick look at your work item, and I have some questions:
>
> What will be the consequences if the server data has be stolen? will t= he
> attacker be able to impersonate as the user?

=A0 Successfully stealing records from the server's password file= will
enable the thief to impersonate the client (back to the hacked server)
for all stolen records.

> How will the password be stored in the server initially?

=A0 That is completely up to the server.

> How will you handle TLS termination that is used many websites to
> centralize the related measurements and protection against the common = SSL
> attacks in one place, and to allow the application firewalls to valida= te
> and check the incoming requests for application-level attacks such as = SQL
> injection and cross-site scripting?

=A0 This is really an operational question. At the risk of sounding f= lippant
I guess I'd just say it will be handled in the best way possible.

=A0 You claim in your draft that "UDKP aims to completely replace the = TLS
protocol." That is a much more ambitious goal and you will need to han= dle
these sorts of issues. The tls-pwd draft just defines certificate-less
ciphersuites that are resistant to dictionary attack (and are better than the various PSK ciphersuites) for use with the existing TLS protocol.

=A0 regards,

=A0 Dan.

> Thanks
>
>
>
> On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
>> [snip]
>> > If you are trying to avoid CA's, then why not just use se= lf-signed
>> > certificates or similar like PGP?
>>
>> =A0 Or why not use a protocol that is already a work item of the >> TLS working group:
>>
>> =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-tls-pwd-00
>>
>> =A0 Dan.
>>
>>
>>
>>
>


--001a11c2e9b852c29d04e14eefa5-- From omh1835@g.rit.edu Fri Jul 12 05:40:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE92A11E8110 for ; Fri, 12 Jul 2013 05:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzkyUNnkZWxd for ; Fri, 12 Jul 2013 05:40:45 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id C273011E8106 for ; Fri, 12 Jul 2013 05:40:44 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MPT003FVPVUOC@smtp-server.rit.edu> for tls@ietf.org; Fri, 12 Jul 2013 08:40:43 -0400 (EDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so19434981iec.8 for ; Fri, 12 Jul 2013 05:40:42 -0700 (PDT) Received: by 10.42.232.200 with HTTP; Fri, 12 Jul 2013 05:40:41 -0700 (PDT) X-Received: by 10.43.137.65 with SMTP id in1mr12785614icc.103.1373632842055; Fri, 12 Jul 2013 05:40:42 -0700 (PDT) X-Received: by 10.43.137.65 with SMTP id in1mr12785612icc.103.1373632841944; Fri, 12 Jul 2013 05:40:41 -0700 (PDT) Date: Fri, 12 Jul 2013 15:40:41 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu Cc: "tls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=001a11c2456e989df204e14fd122 X-RIT-Received-From: 209.85.223.177 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:cc:content-type :x-gm-message-state; bh=AAuCoV/l41vcFFpfwdki4mrVReETers6boW6krcUfXQ=; b=ohGzkv3ngi6dcGP5goEMoM6wuntQIQCxcZwL83OizJ9b53e9Py1Amy+StfOqRBqu4r MzNhzukBcLD0rDYZaS1vNHQqerbNSgpyLvYCeqGG2k94UgcRXRmWZy8DdflGTnYIhGQv 0RNpq5ph3SaUTSbSeux/65mATE4SgvNdKOG+S2s6lHilai5gwDlVmt43rWN2AY4YNGN6 1f8jNsdGXMhC6/lPg9DiE/bMhFU9ER8p0hpp6Hao3gpoxiq22BiI8Cg86Dt+bhPdm4hJ 7T9Igte+HN+4P9g8VSlQXDggNFVKmThhDc/dIM6IXX2lhlxIYyMm0NrxC5nb1nuy/7rN Oo7Q== X-Google-Sender-Auth: MkhoxjvRNnv97K73x0psXljvNPQ X-Gm-Message-State: ALoCoQmWGA+ZWzYBrIqXlfLNj+ScWJ2221aH7nKu4fjlPdcYzBtxWu+etUatogpD7oCj816sx8apFqUJaMxCA5nYQR5FQcvatnLgTLck0pkuJ9ooV1nz6gVIMC7yRe8dZmyfLBZlAv7N References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net> Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:40:49 -0000 --001a11c2456e989df204e14fd122 Content-Type: text/plain; charset=ISO-8859-1 Hi Alex, * Password-authenticated UDKP is key-authenticated, it's based on signing a message by the user's private key, and getting it validated by the user's public key, which is stored on the server. That will make it easy for supporting TLS termination as mentioned in the section 5.2 of the draft, which is not easy to be supported by the TLS-SRP, and that's one of the reasons it's not yet implemented in browsers. * Do not involve CAs at all If it's to be used in the browsers for websites, it will have to depend on CA to secure the registration of the user credential on the server, and that is also the case with UDKP. * Do not allow a compromised server to impersonate the user - Zero-knowledge password proofs are rather useful If the server is compromised, offline and dictionary attack will be possible against the verifier, the attack will be in the password entropy. In UDKP the authentication is done using public/private key, the server will only contains the public key which will not be useful to impersonate the user. The key generation should be based on at least the password, and the security question/answer pair, for applications that require more security the key generation will be based on a file that the user will select, or the key generation will be based on a smart card or a hardware token (more details on that will be in the coming version of the draft). * Are designed to work with TLS, rather than replace it wholesale Actually I have been advised to make it compatible with TLS, and I am thinking of that seriously. Thank You Best Regards On Fri, Jul 12, 2013 at 2:37 PM, OMAR HASSAN (RIT Student) wrote: > Hi Dan, > > I believe that your protocol will better suit for customized applications, > but when it comes to websites you will definitely face those issues that I > took about. > > > > It's very common that a SQL injection attack against the website would > give the attacker the opportunity to steal database records, which will > allow the attacker to impersonate the client (I think TLS-SRP adds a little > complexity to protect against that scenario, I am sure you can improve this > part in your protocol) > > > > Also TLS termination is very important, and must be supported by the > protocol, and the first challenge in that regard is that the load balancer > where the TLS connection should be terminated will not have access to the > server database, and I think without access to the server database you will > not be able to terminate the encrypted connection. > > > > Regarding UDKP, I believe that the only valid attack against it is during > the registration. In that case using an initial TLS authenticated > connection will solve this issue, and for all later usages there is no need > to be dependent on certificate authorities. > > > > In UDKP, if the server data has been stolen, the attacker will get only > the public key, and he will not be able to impersonate the client as he > will need the private key. And regarding TLS termination, the load > balancer could use the user public key to terminate the encrypted > connection, and the let the server authenticate the user. You can refer to > section 5.2 in the draft: > > http://tools.ietf.org/html/draft-omar-tls-udkp-01#section-5.2 > > In the coming version of the draft I will put a detailed analysis for the > attack scenarios. > > > On Thu, Jul 11, 2013 at 6:22 PM, Dan Harkins wrote: > >> >> Hi Omar, >> >> On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote: >> > Hi Dan, >> > >> > I had a quick look at your work item, and I have some questions: >> > >> > What will be the consequences if the server data has be stolen? will the >> > attacker be able to impersonate as the user? >> >> Successfully stealing records from the server's password file will >> enable the thief to impersonate the client (back to the hacked server) >> for all stolen records. >> >> > How will the password be stored in the server initially? >> >> That is completely up to the server. >> >> > How will you handle TLS termination that is used many websites to >> > centralize the related measurements and protection against the common >> SSL >> > attacks in one place, and to allow the application firewalls to validate >> > and check the incoming requests for application-level attacks such as >> SQL >> > injection and cross-site scripting? >> >> This is really an operational question. At the risk of sounding flippant >> I guess I'd just say it will be handled in the best way possible. >> >> You claim in your draft that "UDKP aims to completely replace the TLS >> protocol." That is a much more ambitious goal and you will need to handle >> these sorts of issues. The tls-pwd draft just defines certificate-less >> ciphersuites that are resistant to dictionary attack (and are better than >> the various PSK ciphersuites) for use with the existing TLS protocol. >> >> regards, >> >> Dan. >> >> > Thanks >> > >> > >> > >> > On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins >> wrote: >> > >> >> >> >> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote: >> >> [snip] >> >> > If you are trying to avoid CA's, then why not just use self-signed >> >> > certificates or similar like PGP? >> >> >> >> Or why not use a protocol that is already a work item of the >> >> TLS working group: >> >> >> >> http://tools.ietf.org/html/draft-ietf-tls-pwd-00 >> >> >> >> Dan. >> >> >> >> >> >> >> >> >> > >> >> > --001a11c2456e989df204e14fd122 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,

* Password-authenti= cated

UDKP is key-authenticated, it's based on= signing a message by the user's private key, and getting it validated = by the user's public key, which is stored on the server.
That will make it easy for supporting TLS termination as mentioned in = the section 5.2 of the draft, which is not easy to be supported by the TLS-= SRP, and that's one of the reasons it's not yet implemented in brow= sers.
=A0
* Do not involve CAs at all

If = it's to be used in the browsers for websites, it will have to depend on= CA to secure the registration of the user credential on the server, and th= at is also the case with UDKP.
=A0
* Do not allow a compromised server to impersonate the u= ser
=A0 =A0 - Zero-knowledge password proofs are rather useful

If the server is compromised, offline and dictionary= attack will be possible against the verifier, the attack will be in the pa= ssword entropy.
In UDKP the authentication is done using public/private key, the serve= r will only contains the public key which will not be useful to impersonate= the user. The key generation should be based on at least the password, and= the security question/answer pair, for applications that require more secu= rity the key generation will be based on a file that the user will select, = or the key generation will be based on a smart card or a hardware token (mo= re details on that will be in the coming version of the draft).

* Are designed to work with TLS, rather than replace it= wholesale
Actually I have been advised to make it compatible wit= h TLS, and I am thinking of that seriously.=A0

Thank You
Best Regards



On Fri, Jul 12, 20= 13 at 2:37 PM, OMAR HASSAN (RIT Student) <omh1835@rit.edu> wro= te:

Hi Dan,=A0

I be= lieve that your protocol will better suit for customized applications, but when it comes to websites you = will definitely face those issues that I took about.

=A0

It's very common that a SQL injection attack against the website would give the attacker the opportunit= y to steal database records, which will allow the attacker to impersonate the cl= ient (I think TLS-SRP adds a little complexity to protect against that scenario,= I am sure you can improve this part in your protocol)

=A0

Also TLS termination is very important, and must be supported by the protocol, and the first challenge i= n that regard is that the load balancer where the TLS connection should be terminated will not have access to the server database, and I think without= access to the server database you will not be able to terminate the encrypted connection.

=A0

Regarding UDKP, I believe that the only valid attack against it is during the registration. In that case using= an initial TLS authenticated connection will solve this issue, and for all lat= er usages there is no need to be dependent on certificate authorities.

=A0

In UDKP, if the server data has been stolen, the attacker will get only the public key, and he will not be = able to impersonate the client as he will need the private key= . And regarding TLS termination, the load balancer could use the user public key to terminate the encrypted connection, and the let the server authenticate the user. You can refer to section 5.2 in the draft<= span lang=3D"AR-EG" dir=3D"RTL" style=3D"font-family:Arial,sans-serif">:

http://tools.ietf.o= rg/html/draft-omar-tls-udkp-01#section-5.2

In the coming version of the draft I will put a detailed analysis for the attack scenarios.


On Thu, Jul 11, 2013 at 6:22 PM, Dan Harki= ns <dharkins@lounge.org> wrote:

=A0 Hi Omar,

On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote:
> Hi Dan,
>
> I had a quick look at your work item, and I have some questions:
>
> What will be the consequences if the server data has be stolen? will t= he
> attacker be able to impersonate as the user?

=A0 Successfully stealing records from the server's password file= will
enable the thief to impersonate the client (back to the hacked server)
for all stolen records.

> How will the password be stored in the server initially?

=A0 That is completely up to the server.

> How will you handle TLS termination that is used many websites to
> centralize the related measurements and protection against the common = SSL
> attacks in one place, and to allow the application firewalls to valida= te
> and check the incoming requests for application-level attacks such as = SQL
> injection and cross-site scripting?

=A0 This is really an operational question. At the risk of sounding f= lippant
I guess I'd just say it will be handled in the best way possible.

=A0 You claim in your draft that "UDKP aims to completely replace the = TLS
protocol." That is a much more ambitious goal and you will need to han= dle
these sorts of issues. The tls-pwd draft just defines certificate-less
ciphersuites that are resistant to dictionary attack (and are better than the various PSK ciphersuites) for use with the existing TLS protocol.

=A0 regards,

=A0 Dan.

> Thanks
>
>
>
> On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
>> [snip]
>> > If you are trying to avoid CA's, then why not just use se= lf-signed
>> > certificates or similar like PGP?
>>
>> =A0 Or why not use a protocol that is already a work item of the >> TLS working group:
>>
>> =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-tls-pwd-00
>>
>> =A0 Dan.
>>
>>
>>
>>
>



--001a11c2456e989df204e14fd122-- From pascal.urien@gmail.com Fri Jul 12 06:06:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47F721F9DB8 for ; Fri, 12 Jul 2013 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmX3NU+qBtID for ; Fri, 12 Jul 2013 06:06:38 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E592C21F9D53 for ; Fri, 12 Jul 2013 06:06:37 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm2so3768249bkc.2 for ; Fri, 12 Jul 2013 06:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=p88vnnGwanwvt4h+XKkfyqc75L9r0xOC17XAZZCZ6WA=; b=ImH5L5GHNOTpFnKX9S0tIB5kJ1NapPl8rX250qnXt7wpYKVbAvRzzNay1zOuDGzdYH MYgG41Y0ob9BuibURI/3hBdAvj7fWkyn8oM93XlkZWzNRG0SAGNeylTL5R4lKKOaiwZL Hwv2yBARmxb1Q+y/Xjo2X8Tczy36vvDIe5uxDZ+qi5uohOw5W25EB6RpU3/N5ea9Fh0+ bml/VOME8mL1Pjpp9WWPnRcrkOQNsflJPfi69jpj8GmwQqmhUYOtSqakS5h/BgkEHp9P LmsHg7QwnBQwVo/N+qTt9i4rNWBfqkjQjT6NIeO8LTfSz26D/aRrUelt0y8WuOwfBJJQ Swqw== MIME-Version: 1.0 X-Received: by 10.204.189.80 with SMTP id dd16mr6266199bkb.126.1373634396855; Fri, 12 Jul 2013 06:06:36 -0700 (PDT) Received: by 10.205.123.145 with HTTP; Fri, 12 Jul 2013 06:06:36 -0700 (PDT) Date: Fri, 12 Jul 2013 15:06:36 +0200 Message-ID: From: Pascal Urien To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf3033454d46d1f104e1502e27 Subject: [TLS] draft-urien-tls-llcp-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 13:06:38 -0000 --20cf3033454d46d1f104e1502e27 Content-Type: text/plain; charset=ISO-8859-1 Hi All, A new version of I-D, draft-urien-tls-llcp-02.txt is available at http://www.ietf.org/internet-drafts/draft-urien-tls-llcp-02.txt LLCPS has been sucessfully implemented between a blackberry NFC mobile and a NFC reader see http://www.youtube.com/watch?v=CWS41cIZylw Abstract: This document describes the implementation, named LLCPS, of the TLS protocol over the NFC (Near Field Communication) LLCP (Logical Link Control Protocol) layer. The NFC peer to peer (P2P) protocol may be used by any application that needs communication between two devices at very small distances (a few centimeters). LLCPS enforces a strong security in NFC P2P exchanges, and may be deployed for many services, in the Internet Of Things (IoT) ecosystem, such as payments, access control or ticketing operations. Applications secured by LLCPS are identified by the service name "urn:nfc:sn:tls:x" where x is the application name. Regards Pascal Urien --20cf3033454d46d1f104e1502e27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0


LLCPS has been sucessfully implemented between a blackberry NFC mobi= le and a NFC reader

see http://www.youtube.com/watch?v=3DCWS41cIZylw
=A0
=A0A= bstract:
=A0=A0=A0 This document describes the implementation, named LLCPS, of the T= LS
=A0=A0=A0 protocol over the NFC (Near Field Communication) LLCP (Logi= cal Link
=A0=A0=A0 Control Protocol) layer. The NFC peer to peer (P2P) p= rotocol may be
=A0=A0=A0 used by any application that needs communication between two devi= ces
=A0=A0=A0 at very small distances (a few centimeters). LLCPS enforce= s a strong
=A0=A0=A0 security in NFC P2P exchanges, and may be deployed = for many
=A0=A0=A0 services, in the Internet Of Things (IoT) ecosystem, = such as
=A0=A0=A0 payments, access control or ticketing operations. Applications=A0=A0=A0 secured by LLCPS are identified by the service name
=A0=A0=A0= "urn:nfc:sn:tls:x" where x is the application name.

Regard= s

Pascal Urien

=A0

--20cf3033454d46d1f104e1502e27-- From internet-drafts@ietf.org Mon Jul 15 16:11:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779B021E818A; Mon, 15 Jul 2013 16:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OhzRHozyVxA; Mon, 15 Jul 2013 16:11:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4EC11E8109; Mon, 15 Jul 2013 16:11:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 16:11:27 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 23:11:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Out-of-Band Public Key Validation for Transport Layer Se= curity (TLS) Author(s) : Paul Wouters Hannes Tschofenig John Gilmore Samuel Weiler Tero Kivinen Filename : draft-ietf-tls-oob-pubkey-08.txt Pages : 15 Date : 2013-07-15 Abstract: This document specifies a new certificate type and two TLS extensions, one for the client and one for the server, 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hauke@hauke-m.de Tue Jul 16 04:50:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AA811E8299 for ; Tue, 16 Jul 2013 04:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7MHl+kSJIFr for ; Tue, 16 Jul 2013 04:50:48 -0700 (PDT) Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id A74C711E8276 for ; Tue, 16 Jul 2013 04:50:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 149C48F61 for ; Tue, 16 Jul 2013 13:50:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIj0i5wSTTV3 for ; Tue, 16 Jul 2013 13:50:41 +0200 (CEST) Received: from [192.168.1.178] (spit-414.wohnheim.uni-bremen.de [134.102.133.158]) by hauke-m.de (Postfix) with ESMTPSA id C81FA857F for ; Tue, 16 Jul 2013 13:50:41 +0200 (CEST) Message-ID: <51E5338F.9030100@hauke-m.de> Date: Tue, 16 Jul 2013 13:50:39 +0200 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: tls@ietf.org References: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> In-Reply-To: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 11:50:49 -0000 On 07/16/2013 01:11 AM, internet-drafts@ietf.org wrote: > > 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 : Out-of-Band Public Key Validation for Transport Layer Security (TLS) > Author(s) : Paul Wouters > Hannes Tschofenig > John Gilmore > Samuel Weiler > Tero Kivinen > Filename : draft-ietf-tls-oob-pubkey-08.txt > Pages : 15 > Date : 2013-07-15 > > Abstract: > This document specifies a new certificate type and two TLS > extensions, one for the client and one for the server, 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey > Thanks for the new draft. I have some comments to this version: In section 3. New TLS Extension the link to Section 2.3.5 of RFC 5480 is wrong, this should be just Section 2. RFC 5480 defines a lot more OIDs which could be used as an algorithm OID than listen in Figure 3. ECDSA defines a different OID for every standardized curve. I think naming the OID in Figure 3 should be removed and there should just be a pinter to the RFC. It should also be made clear that there could be further RFC than RFC 3279, RFC3279 and RFC5480 defining OIDs used in the SubjectPublicKeyInfo, like RFCs defining a new public key type. Could you add some list definition where the numbers assigned by the IANA should be added later. I like how it is done in draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0]. Are there some intermediate version of this draft available, like a public readable svn repository where the work on this draft is happening? Hauke [0]: https://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-06#section-2 From jpixton@gmail.com Tue Jul 16 13:15:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818C421F8438 for ; Tue, 16 Jul 2013 13:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC1J9lc9vZXZ for ; Tue, 16 Jul 2013 13:15:09 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 60DB221F9EF5 for ; Tue, 16 Jul 2013 13:15:09 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so636742qcy.41 for ; Tue, 16 Jul 2013 13:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GAKwuORk/uW0kfofgIUh2rOtV6QBUG4seha2FvNceuI=; b=uTBuI6hGI3b+W3aovJmrxqJ6xD2ZljePq9TlRLErLjK/4AEmOz1gXAzXYY7Lj4AKkJ G44If2QS7isoM6QSYk23+eguxSuMj85yC+L/gbjmBrZNM9fgkaYw2asNxbC5EcXofKby V6DPn6fgV7K+XhlDvnIn0Xso2YmZYpZBVcKwHMXcBnImILt/x7YSB67XXZjfcpUcA11C ZlY56u1GCyEge3l8OEpeaDiE6o2AGgU3GJ6+E9ieauEy3ktfMUjcjetnVJiAUMJS0KN6 1CnqelCMjDUHjweYArQvr3y1+Qtzv9n0gC0c55FCKA48JgE2mNycmvi093nW6Lp1M1Sd 2SyA== MIME-Version: 1.0 X-Received: by 10.224.66.2 with SMTP id l2mr5638380qai.28.1374005708843; Tue, 16 Jul 2013 13:15:08 -0700 (PDT) Received: by 10.224.45.199 with HTTP; Tue, 16 Jul 2013 13:15:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jul 2013 21:15:08 +0100 Message-ID: From: Joseph Birr-Pixton To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [TLS] TLS Digest, Vol 108, Issue 10 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 20:15:10 -0000 On Mon, 15 Jul 2013 16:11:27 -0700, wrote: > 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 : Out-of-Band Public Key Validation for Transport Layer Security (TLS) > Author(s) : Paul Wouters > Hannes Tschofenig > John Gilmore > Samuel Weiler > Tero Kivinen > Filename : draft-ietf-tls-oob-pubkey-08.txt > Pages : 15 > Date : 2013-07-15 > > Abstract: > This document specifies a new certificate type and two TLS > extensions, one for the client and one for the server, 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. What is the rationale for having the public key communicated /both/ authentically out-of-band and inauthentically in-band? Avoiding any inauthentic communication of the public key means failure to establish the correct key out-of-band will mean a connection is impossible, even in the presence of implementation bugs. Possible rationale could include: - allowing leap-of-faith authentication. - allowing an endpoint to vary the public key it returns with time or other extension content (like SNI, EC curves, etc.) - allowing an endpoint which cannot or does not store an authentic public key for its counterpart, but can store (say) a hash of it. In any case, I think including the real rationale in the RFC could prove instructive. Cheers, Joe From hannes.tschofenig@gmx.net Thu Jul 18 05:02:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FBB21F99AE for ; Thu, 18 Jul 2013 05:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vXXA9cEXdb5 for ; Thu, 18 Jul 2013 05:02:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 92AF021F994C for ; Thu, 18 Jul 2013 05:02:50 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M4GND-1U7xg43mTL-00rsyi; Thu, 18 Jul 2013 14:02:48 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jul 2013 14:02:44 +0200 Message-Id: <9BDB9446-3CFD-470F-8346-68541616A99A@gmx.net> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:fCJySWeNT5ESWKzaCeZSlIWwGZvTJBJajJErna5ZvofQDIwMkZV vNomOoHtwotYoYeSb+Uc7UC/8+yQ8KKb56J6mPbbbQHkG6hdVFeDGElnXtHuk3FZmypLfxP VgVPx1sfCSst9gulsVJtM7ljkaNsongP23F3UM4T3MzyFUZDafWet0hQy/E6FdKvOQX4BVr V7auMXtEcwp9Ln137UGaQ== Subject: [TLS] draft-ietf-tls-oob-pubkey-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:02:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 last Monday I have submitted an updated version of the "Out-of-Band = Public Key Validation for Transport Layer Security (TLS)" document in an = attempt to incorporate the review from Sean as well as the discussion = feedback on the list in response to it.=20 Here is the updated version:=20 https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ A look at the diff quickly reveals the changes I have made: =20 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-08 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR59llAAoJEGhJURNOOiAtDH4IAJM/M8EKODlbWThKWd82YOY9 c1jlEf12QmsOMYCC1ZbbHj6mUUySbHUj3odM21u9Z49talaA/GYNOhtCdSgDFTnV 7Y41KVYgkAndmfVSMeiyjv9BSiBLNHQLuCjhRmgWMKsO3fwskx9jnQsREcO6oRxR WvirF4fnJSQ4Az64f6+pKHBmVn/K9d9Tcm8lNKQLTzRPJzPUcwhaRudOf5JuepuN da/QbhXkyaOwx83byWTAzhYZ19/SN22uK5j5dO3/ulDIYvByIDoQPvkhIBoa11+j nkaNXnXRnXl7RHMf9JiLxFME3+5iHT2yipQeAotCvlGaZxDAfWRap4pUBc3G1SI=3D =3DurRW -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Thu Jul 18 05:20:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B105A21E80DA for ; Thu, 18 Jul 2013 05:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRCQGM-BqjR0 for ; Thu, 18 Jul 2013 05:20:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA621E80DE for ; Thu, 18 Jul 2013 05:20:01 -0700 (PDT) Received: from [172.16.254.104] ([80.92.116.207]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lz3JU-1U4PJ00PIm-014CsW; Thu, 18 Jul 2013 14:19:59 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <51E5338F.9030100@hauke-m.de> Date: Thu, 18 Jul 2013 14:19:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74975B22-61CB-47AD-AEFF-A273C8F6ECC8@gmx.net> References: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> <51E5338F.9030100@hauke-m.de> To: Hauke Mehrtens X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:1ygPRba77Lv7B/YQ1NUqpVb2sSp6HUwN7g/yj+IUCI6v+rG4hCu rDOgMvvMJEQAYUgOqLXACUyOjUvs1VHmmyWzvAq3TQ/yoi3qJYjKoZQXvDx5M+5ous0rouh 1uVAARIMalOfMpzCKxZBpLwoM9naalKpX2i901wHH0qTAhObemhtZjyCgm2Rket/3P5qYSu Omtb+GTFyePQC0LUgUz2w== Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:20:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Hauke,=20 thanks for your quick review.=20 >=20 > Thanks for the new draft. >=20 > I have some comments to this version: >=20 > In section 3. New TLS Extension the link to Section 2.3.5 of RFC 5480 > is wrong, this should be just Section 2. You are unfortunately correct. Fixed it.=20 >=20 > RFC 5480 defines a lot more OIDs which could be used as an algorithm = OID > than listen in Figure 3. ECDSA defines a different OID for every > standardized curve. I think naming the OID in Figure 3 should be = removed > and there should just be a pinter to the RFC. It should also be made > clear that there could be further RFC than RFC 3279, RFC3279 and = RFC5480 > defining OIDs used in the SubjectPublicKeyInfo, like RFCs defining a = new > public key type. You are right that (a) there may be more OIDs defined in the future and = that (b) RFC 5480 defines more OIDs than the single one listed in the = table.=20 However, the table just lists examples to illustrate common cases for = the reader. I could, however, add a sentence to point out that these are = just examples and more OIDs exist.=20 >=20 > Could you add some list definition where the numbers assigned by the > IANA should be added later. I like how it is done in > draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0]. The above-mentioned draft uses a different registry but I guess you are = asking for a snapshot of the current registry.=20 For example, something like this:=20 - - ------------------------------------------------------ Value Description Reference=20 0 X.509 [RFC6091] 1 OpenPGP [RFC6091] 3 Raw Public Key [This RFC] 3-223 Unassigned=09 224-255 Reserved for [RFC6091]=20 Private Use=09 - - ------------------------------------------------------ Is this correct?=20 >=20 > Are there some intermediate version of this draft available, like a > public readable svn repository where the work on this draft is = happening? Yes; here is the git repository: = https://github.com/hannestschofenig/tschofenig-ids/tree/master/raw-public-= keys Ciao Hannes >=20 > Hauke >=20 >=20 > [0]: = https://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-06#section-2 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls - -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR591UAAoJEGhJURNOOiAtVEYIAIFfPz+HEK4lBLNSe/2l2EYS 0GPWUduNo8/GcU/uiVxWEpFmKG0gvgTstj6AT2ima3JAgoWfglOdAh1N3/RJCNsf +1Tyh91SUGH40v6ctdfuKalzfb8DOcSBiZ3DRVLI4FiuSBXUFK6Ru5mpNTSELvgF 2rY8kDd/UUIlrRSIq9Zb1B88k6ElP5vxrtZV5x4OGZaD63UfitHMZpXCJqFDpNyb 8HTqxrHrJeNURh8HH7RDfkw4I/Hrkw1hMuMmADQoYCCEADBRDSRW6QFL2bVewjr2 EAlyHNrK4c1BosEzXhInIA/2WY4CUdd6/PwNa50p6md0dJxgZnZy7RG1kA73ny4=3D =3DJH/F - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR591tAAoJEGhJURNOOiAtwD0H/jmCbbdyGewFqCQ9FIcd3MZi uVHa80cfCsUQ9Z3w3UyLfV8qYmVxdXIaM4BK+/TdPpX44jPqfC+bNahTAmMT+Bha T0IRsEcetN24yYBf/Wth+st9V+TmER8t79S6iKxmmYVElvUdrxqR8bYISFB4Cpaw isWG4SKAooSdmnJVMGS3betCDvGJH1Q35HjLL22UlHDDCJggoQly16Cbgr2vGcFV sCpWWWD6X+ISgZ6hrhV7JP+UtV93SeoYuWmCSVBNiRInXXrQwy4LpJFHH5AEeg+t CCvQaHr/VWyTIJBKoaFleAsL0cMwCVQDEoVl/kvvUbld6ALA3+QcY0MBdbcmnt8=3D =3Dz/51 -----END PGP SIGNATURE----- From benl@google.com Fri Jul 19 03:33:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4531A21F888F for ; Fri, 19 Jul 2013 03:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rya4ewUnfiW5 for ; Fri, 19 Jul 2013 03:33:16 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0FD21F84AF for ; Fri, 19 Jul 2013 03:33:16 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so9085718iea.11 for ; Fri, 19 Jul 2013 03:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bwaFaJnfUJqgm4bm7vJNWDXPCZy0YltmvfYtdidiEK0=; b=E1ox7/QgnscZDLuR8eQbDGIZYZf8LLtMJXnefM4aafcHcgH6LyhqYoRUxfmsCrWirs fvHL+94R5D9jkNOldQLobJMb/XfMiHASPThm/USkhD0/XywpT5JYinPyUqvKoy+WHRr5 Pys4oTeSSbZd9oZ/JC7lRUpDZMe8naFC0cBiIHm7m1hSdFskOLxH+4Shtb4hAExNOEJl XSn1F1BYfB5SpcERMvO52hNJpqd9pdid2exayqnexuHrkdHGPajp/gxYibZY+f4e0por xC4uMS3nq0FneiEjXBMD+nNC7z2GCSkmf7/PhB0rFOsYHX7IhNH1WpkxDKWhSsApZ8LI jIcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=bwaFaJnfUJqgm4bm7vJNWDXPCZy0YltmvfYtdidiEK0=; b=KmuFI9EJkjZSLTz1CHk8hfbSOeCLZ/JcVFtI07RyMP/5wvS2AkYwhCdeEyl7zX5VqY IG4LZtUXd2ZfD45A6TCU1KvwrE1kLR5sN0ujamIMuZW5Li5JrhWZVQ6IOWn2gL6H94Mo bKSIGlQn4Cz4oNS+AFK3X6ZhLV6AZNjiJjk57aVXMwDu183jFJeygAiDndaTw63NGAOm qftajGOdCbr90M3YPwQxQFin19rrBjGlkAhWugh+cTshNAmr04OCvbEDzMBMFnGfzWTD /97YPPKt0Jk06BtUEVaFB00i+jDDmzOCndd+BJt0OIZB3hxxtmWjqCPmQTJDjuHb08O4 EUbg== MIME-Version: 1.0 X-Received: by 10.42.254.8 with SMTP id nc8mr9247640icb.49.1374229991955; Fri, 19 Jul 2013 03:33:11 -0700 (PDT) Received: by 10.64.100.207 with HTTP; Fri, 19 Jul 2013 03:33:11 -0700 (PDT) Date: Fri, 19 Jul 2013 11:33:11 +0100 Message-ID: From: Ben Laurie To: "tls@ietf.org" , IETF DANE WG list , certificate-transparency@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec50e5f9582c54304e1dadabc X-Gm-Message-State: ALoCoQmJ0B5AHgYmRZ+HH/GB0T4iVWqlQvV0/CsGjdEdfP+BdovtzNAlxBBo6iZnNTblETE/CfJ8WhMqN9aci3sfgWNrCyG/7Zf98Ggwk847bw62gTU1IgH4qD8fTQ+G9vrccnKiBHEzit8l+EMVQQ8jCloDvD5qtltKTEQRyQ5wv89JiJgEM6VtglXgoUr3z/IGeSAPG+la Subject: [TLS] Certificate Transparency Hack Day X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:33:17 -0000 --bcaec50e5f9582c54304e1dadabc Content-Type: text/plain; charset=ISO-8859-1 The Certificate Transparency team are considering hosting a hack day at Google's London office during the week of Aug 27-30 (Mon Aug 26 is a bank holiday). On the agenda would likely be: * log dashboard and data visualization * an appengine port of the dashboard * browser plugins * binary transparency * DNSSEC transparency * revocation transparency * anything else people find interesting If you'd be interested in attending such an event, please let Ben Laurie (benl@google.com) know and indicate any preference for which day. Thanks! --bcaec50e5f9582c54304e1dadabc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The Certificate Transparency team are considering hosting a hack day
at Google's London office = during the week of Aug 27-30 (Mon Aug 26 is
a bank holiday)= . On the agenda would likely be:

* log dashboard= and data visualization
* = an appengine port of the dashboard
* browser plugi= ns
* binary transparency
* DNSSEC transp= arency
* revocation transp= arency
* anything else= people find interesting

If you'd be in= terested in attending such an event, please let Ben
Laurie (= benl@google.com) know and indicate any preference for which
day.

Thanks!
--bcaec50e5f9582c54304e1dadabc-- From turners@ieca.com Fri Jul 19 06:54:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBFA21E80C3 for ; Fri, 19 Jul 2013 06:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP3GordLHtq1 for ; Fri, 19 Jul 2013 06:54:40 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.144.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0825811E82A5 for ; Fri, 19 Jul 2013 06:54:33 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 08582CDA23BBA; Fri, 19 Jul 2013 08:54:19 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id F1897CDA23B97 for ; Fri, 19 Jul 2013 08:54:18 -0500 (CDT) Received: from [74.96.0.204] (port=49559 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V0B8i-0000zK-CC; Fri, 19 Jul 2013 08:54:32 -0500 Message-ID: <51E94517.9040809@ieca.com> Date: Fri, 19 Jul 2013 09:54:31 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hannes Tschofenig References: <9BDB9446-3CFD-470F-8346-68541616A99A@gmx.net> In-Reply-To: <9BDB9446-3CFD-470F-8346-68541616A99A@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [74.96.0.204]:49559 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 16 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-08 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:54:52 -0000 Hannes, The remaining point is that this draft needs to state that checking the status of the key/name binding is also done out-of-band. spt On 7/18/13 8:02 AM, Hannes Tschofenig wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi all, > > last Monday I have submitted an updated version of the "Out-of-Band Public Key Validation for Transport Layer Security (TLS)" document in an attempt to incorporate the review from Sean as well as the discussion feedback on the list in response to it. > > Here is the updated version: > https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ > > A look at the diff quickly reveals the changes I have made: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oob-pubkey-08 > > Ciao > Hannes > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBCgAGBQJR59llAAoJEGhJURNOOiAtDH4IAJM/M8EKODlbWThKWd82YOY9 > c1jlEf12QmsOMYCC1ZbbHj6mUUySbHUj3odM21u9Z49talaA/GYNOhtCdSgDFTnV > 7Y41KVYgkAndmfVSMeiyjv9BSiBLNHQLuCjhRmgWMKsO3fwskx9jnQsREcO6oRxR > WvirF4fnJSQ4Az64f6+pKHBmVn/K9d9Tcm8lNKQLTzRPJzPUcwhaRudOf5JuepuN > da/QbhXkyaOwx83byWTAzhYZ19/SN22uK5j5dO3/ulDIYvByIDoQPvkhIBoa11+j > nkaNXnXRnXl7RHMf9JiLxFME3+5iHT2yipQeAotCvlGaZxDAfWRap4pUBc3G1SI= > =urRW > -----END PGP SIGNATURE----- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From hauke@hauke-m.de Sat Jul 20 08:29:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF2921E80A6 for ; Sat, 20 Jul 2013 08:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW0PqLkGkF9n for ; Sat, 20 Jul 2013 08:29:31 -0700 (PDT) Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0953321E80A3 for ; Sat, 20 Jul 2013 08:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 9EE658F61; Sat, 20 Jul 2013 17:29:28 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmYZp7ysmytA; Sat, 20 Jul 2013 17:27:17 +0200 (CEST) Received: from [IPv6:2001:470:1f0b:447:878:d37a:98c:1fb1] (unknown [IPv6:2001:470:1f0b:447:878:d37a:98c:1fb1]) by hauke-m.de (Postfix) with ESMTPSA id 55D0C857F; Sat, 20 Jul 2013 17:27:17 +0200 (CEST) Message-ID: <51EAAC53.6080704@hauke-m.de> Date: Sat, 20 Jul 2013 17:27:15 +0200 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hannes Tschofenig References: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> <51E5338F.9030100@hauke-m.de> <74975B22-61CB-47AD-AEFF-A273C8F6ECC8@gmx.net> In-Reply-To: <74975B22-61CB-47AD-AEFF-A273C8F6ECC8@gmx.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 15:29:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Hannes, On 07/18/2013 02:19 PM, Hannes Tschofenig wrote: > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > > Hi Hauke, > > thanks for your quick review. > > >> Thanks for the new draft. > >> I have some comments to this version: > >> RFC 5480 defines a lot more OIDs which could be used as an >> algorithm OID than listen in Figure 3. ECDSA defines a different >> OID for every standardized curve. I think naming the OID in >> Figure 3 should be removed and there should just be a pinter to >> the RFC. It should also be made clear that there could be further >> RFC than RFC 3279, RFC3279 and RFC5480 defining OIDs used in the >> SubjectPublicKeyInfo, like RFCs defining a new public key type. > > You are right that (a) there may be more OIDs defined in the future > and that (b) RFC 5480 defines more OIDs than the single one listed > in the table. However, the table just lists examples to illustrate > common cases for the reader. I could, however, add a sentence to > point out that these are just examples and more OIDs exist. Thanks for adding the sentence that makes it clear. > >> Could you add some list definition where the numbers assigned by >> the IANA should be added later. I like how it is done in >> draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0]. > > The above-mentioned draft uses a different registry but I guess you > are asking for a snapshot of the current registry. For example, > something like this: > > - ------------------------------------------------------ Value > Description Reference 0 X.509 > [RFC6091] 1 OpenPGP [RFC6091] 3 Raw > Public Key [This RFC] 3-223 Unassigned 224-255 Reserved for > [RFC6091] Private Use - > ------------------------------------------------------ > > Is this correct? Isn't the final number in the end of the standardization process added to the draft? I was just thinking about adding a placeholder for that number in the draft. For the Certificate Type there is already the excepted number added in the draft, but for the server_certificate_type and client_certificate_type there is a placeholder missing. >> Are there some intermediate version of this draft available, like >> a public readable svn repository where the work on this draft is >> happening? > > Yes; here is the git repository: > https://github.com/hannestschofenig/tschofenig-ids/tree/master/raw-public-keys Thanks > for the link. Hauke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJR6qxSAAoJEIZ0px9YPRMyh5cP/3BF6Mwbf7qT9Ra8rtFhvoll VJDWKtD2s6efgPHFXUA/mqELmCgy1v/TaZv4CzYvy1GWdneAQ6wTclzA+wsDbZ+0 RzD9Gd6uM3fPd3yYvfdXR+y9hM+5352aJMSeY2k30kpqJHaOCt0pTkBfgBsa9d/0 eXm6sdD4hRx9w47FlNltZOmbG93dSL7qBxc+43fFl/77DVS1KoLNmPkXLpxgP4oj KFJCZ+OiXm5hRdP4+tPn/DgUUzL9YQC4rkmR1Seo+Ttoql9UFTpjJ5j4otbeYnGZ h42Smk5rpyMQ+hbmuujiid6k3bTV2DK9fM6+CfMBGwE0O9DaXi/d/w6Nt3j1zRCe hT2r/plROzHvJESB7PFnI4oUWdJAz/hNs8idx8VX/pd3dj5y0IVL1sNDrNS0IziJ wUd91PJLKv/tb3qxtERX7Mu3aYN3HVAw4isRJidVr5nm/nvFnlX/jPdIEC0ZB+k6 LLPCiEv6neO4ACKB32B967o+cMWpHUiaWZ0sQaeMAWY8blmKcBDk/0x/2D7zYOgu 0unfajW/EwthSPVqdzS7tuZATwksa4Wg0WdHpZPHOW0MMR6C4YADIAMBEdFMCOFW NR6gi5GvTF22KOQ8rinjvNZ3d0BrZbU3tLbgJZ9CIVa2j4dCHfE3xy5mifSyI8uh +N0s2EHMHOoD8+9QDngo =Bx3l -----END PGP SIGNATURE----- From quynh97@gmail.com Mon Jul 29 03:33:13 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF2821F9B12 for ; Mon, 29 Jul 2013 03:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LvcGcZspABU for ; Mon, 29 Jul 2013 03:33:12 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 38E9321F99E8 for ; Mon, 29 Jul 2013 03:33:11 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m46so3756684wev.22 for ; Mon, 29 Jul 2013 03:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yAIsVnZB/HZLUXArxWDc//JUB7G5gm45CrYVvipreXA=; b=hnUahpEJYQNQR4tuIIUOw28a6ZceluFrVcUlS7FzUomy3rfJP3j0MGjPioakblWShk 4YRFW5kIhV0hH7Xv5+OTK4TOfiWJdS51PM4cXvoEw5sipf45fGMcMEw6i1hQLjYFVHfU FCsfJcCtK7BBbjyke1ivTTdXAkf1GnCjPqWZybvdF1Pork7/bLx2Z/rBmK1LRwZytE6c f357/qenJ9nwYERdmIwS/Eq3gIpzI3XSIWZNWGG6VCJFrPFA+Ev67d/g8DiwRLvfqD4t BYsQwABMu26PnsngEwLbGzuTl+Ky7iPQ2sGrtXqxFPOU3HGvh7Fm/sm7Qn6n9GWi/c/5 BiDg== X-Received: by 10.194.63.228 with SMTP id j4mr18149238wjs.34.1375093991258; Mon, 29 Jul 2013 03:33:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.176.66 with HTTP; Mon, 29 Jul 2013 03:32:51 -0700 (PDT) From: Quynh Dang Date: Mon, 29 Jul 2013 12:32:51 +0200 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7ba97f3ae1be9904e2a404ba Subject: [TLS] On the Security of the TLS Protocol: A Systematic Analysis by Hugo Krawczyk, Kenneth G. Paterson and Hoeteck Wee.. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 10:33:13 -0000 --047d7ba97f3ae1be9904e2a404ba Content-Type: text/plain; charset=ISO-8859-1 Everyone, The subject line is the title of a scheduled talk at the up coming Crypto 2013 about TLS. I think the paper is at the link below. http://eprint.iacr.org/2013/339.pdf Quynh. --047d7ba97f3ae1be9904e2a404ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Everyone,

The subject line i= s the title of a scheduled talk at the up coming Crypto 2013 about TLS. I t= hink the paper is at the link below.=A0


= http://eprint.iacr.org/2013= /339.pdf

Quynh.=A0


--047d7ba97f3ae1be9904e2a404ba-- From Kenny.Paterson@rhul.ac.uk Mon Jul 29 08:53:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2885421F99CE for ; Mon, 29 Jul 2013 08:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O76mRswJYafp for ; Mon, 29 Jul 2013 08:53:35 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 05D7E11E80F7 for ; Mon, 29 Jul 2013 08:52:57 -0700 (PDT) Received: from mail11-tx2-R.bigfish.com (10.9.14.225) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 15:52:54 +0000 Received: from mail11-tx2 (localhost [127.0.0.1]) by mail11-tx2-R.bigfish.com (Postfix) with ESMTP id 03D9D3801AC for ; Mon, 29 Jul 2013 15:52:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.107; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB01.cc.rhul.local; RD:exch-hub01.rhul.ac.uk; EFVD:NLI X-SpamScore: -6 X-BigFish: VPS-6(zzbb2dI98dI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah1de096h5eeeK8275bh8275dh1de097hz2dh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.248.133; KIP:(null); UIP:(null); (null); H:AMXPRD0310HT003.eurprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail11-tx2 (localhost.localdomain [127.0.0.1]) by mail11-tx2 (MessageSwitch) id 13751129926446_14952; Mon, 29 Jul 2013 15:49:52 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.231]) by mail11-tx2.bigfish.com (Postfix) with ESMTP id E6EC1160046 for ; Mon, 29 Jul 2013 15:49:51 +0000 (UTC) Received: from EXCH-HUB01.cc.rhul.local (134.219.208.107) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 15:49:51 +0000 Received: from am1outboundpool.messaging.microsoft.com (134.219.208.67) by hybrid.rhul.ac.uk (134.219.208.107) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 29 Jul 2013 16:49:50 +0100 Received: from mail60-am1-R.bigfish.com (10.3.201.245) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Mon, 29 Jul 2013 15:49:49 +0000 Received: from mail60-am1 (localhost [127.0.0.1]) by mail60-am1-R.bigfish.com (Postfix) with ESMTP id E36C1240350 for ; Mon, 29 Jul 2013 15:49:49 +0000 (UTC) Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1375112988499442_11677; Mon, 29 Jul 2013 15:49:48 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.228]) by mail60-am1.bigfish.com (Postfix) with ESMTP id 724832C004B; Mon, 29 Jul 2013 15:49:48 +0000 (UTC) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 29 Jul 2013 15:49:48 +0000 Received: from AMXPRD0310MB377.eurprd03.prod.outlook.com ([169.254.2.234]) by AMXPRD0310HT003.eurprd03.prod.outlook.com ([10.255.55.38]) with mapi id 14.16.0341.000; Mon, 29 Jul 2013 15:49:47 +0000 From: "Paterson, Kenny" To: Quynh Dang , "tls@ietf.org" Thread-Topic: [TLS] On the Security of the TLS Protocol: A Systematic Analysis by Hugo Krawczyk, Kenneth G. Paterson and Hoeteck Wee.. Thread-Index: AQHOjEdHq2sXF83RmEi/m2MjloDvbJl7722A Date: Mon, 29 Jul 2013 15:49:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.255.55.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <8CF88111007C014D9816AAFD90FB1EAB@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%36694$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-FOPE-CONNECTOR: Id%36694$Dn%IETF.ORG$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [TLS] On the Security of the TLS Protocol: A Systematic Analysis by Hugo Krawczyk, Kenneth G. Paterson and Hoeteck Wee.. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:53:49 -0000 Quynh, That is indeed the paper. The talk will be given by Hoeteck Wee. I am very happy to try to answer any questions on the paper on this list. For once, the results are good news for TLS! Regards, Kenny=20 On 29/07/2013 12:32, "Quynh Dang" wrote: >Everyone, > > >The subject line is the title of a scheduled talk at the up coming Crypto >2013 about TLS. I think the paper is at the link below. > > > > >http://eprint.iacr.org/2013/339.pdf > >Quynh.=20 > > > > > > From agl@google.com Mon Jul 29 12:09:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3850E21F9D3A for ; Mon, 29 Jul 2013 12:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0bmQKBcaOEe for ; Mon, 29 Jul 2013 12:09:48 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id CA62121F9A15 for ; Mon, 29 Jul 2013 12:09:47 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n16so2510817oag.22 for ; Mon, 29 Jul 2013 12:09:47 -0700 (PDT) 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=NjVL16gnYnxRjpl9r4RJPsRs3lVaN3L7a1ad7DfoTIA=; b=LmXI9b29GDB01cxNWPf/brIMJ9uJ07SB452+RVMrp0/vCNbiiaqpnwBNRJGldBWibX LpYMbVHoqA0cKqXYrb3z4srcpRXvfpdbdE6YlwZHUNP/5ga7ciO2Qzehz2Fai0QrL76k eX7Oala3OSmKBNZgi5Kqc+ecPMPJjiv3jcSEz7TOVdXiPF7iWq4R1O+g771G9aim/FoY f3wQ43fvuDSzzoeqh6lpfeSO0cts+ApeRatJ5Dw/Nv6Ljf19Hu6GuiTTSDXtbav4GwEy 3AUG2WuoCsj+FX2hDZ4GX+eRM3AIVDFgbWFSmK11814Ux9abQ6URWt86foBwKwRiy4P9 G0yw== X-Google-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 :x-gm-message-state; bh=NjVL16gnYnxRjpl9r4RJPsRs3lVaN3L7a1ad7DfoTIA=; b=FmgqY6zGoXT3ztVpZRXVyZ9RpjTttlh8e8LjgELatSbNubQ3tEJ397OSeBvxAJ8qLO 5YHUqR8q+F3gVqMnQbEdVyXnxpoztQxxjLLBqrg8IwyOQCF2S40u4SIeNofB/4LByeF0 RB5GSIzrMwGoEBvisa56ZSpq50XqJnhgtsN9Ql0vhiHpnu2q8TJG8Bt5PxAo4Qx6E4Ql QuoaQpWXNmJ0gRoVyYCKmcz+XJ1H+lj5uOlhbyIrNF24PrDqmfq5Tpiy4QmaUr2rTX37 2JnWj1+SN//lEo898OCWpGfBo0AzeXmMrjyptnH1U2A+ksdEMQLU+lwXZQ5rH89nXzQ6 hzeg== X-Received: by 10.182.81.41 with SMTP id w9mr16886748obx.18.1375124987195; Mon, 29 Jul 2013 12:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Mon, 29 Jul 2013 12:09:27 -0700 (PDT) From: Adam Langley Date: Mon, 29 Jul 2013 15:09:27 -0400 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmhgELriMnHxnTdxY7F2POsvHMxrCOvNQYaVB7mFJn9Q70rwnPlM8SAbqCS94BAkReH0dksZw1XAvng/Fx/z3NcmUstYJq5sD2WNDRe7ALx+Rsv8e90BmZnIcyLRHK5Il5zlSk+pgn88q5mjZv+eYHfPoWWCf49s3JDrEGeAsO+D0kCRn7zP8qFv9P7qnt58f4yfdRc Subject: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:09:49 -0000 I cannot make it to Berlin I'm afraid (or, indeed, any meetings until at least IETF 91) so I'm writing my thoughts on draft-josefsson-salsa20-tls-02, which is scheduled for discussion. We (Google) support the addition of Salsa20 as a cipher in TLS. Having a secure cipher which is fast and constant time on all platforms is important. It's also good to have an alternative to AES in the wings should that be needed in the future. At the moment I consider RC4 and AES-CBC to be mortally wounded, even if we have to continue supporting them for many years yet. Salsa20/12 is something that we are currently working on supporting. However, I believe that Poly1305 is superior to UMAC and we're looking at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the nonce generated directly by Salsa20/12, not via AES.) (For the following, I used UMAC in nettle 2.7 and Andrew M's implementation of Poly1305[1], both on a E5-2690@2.90GHz with Hyperthreading and Turboboost disabled.) UMAC96 (with AES for the nonce generation) takes 9146.1ns to authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes 561.4ns. However, that's not the whole story for UMAC because it can use 1.5KB of memory for precomputation, after which it can authenticate 1KB of memory in just 329ns with that in L1. That's typically the headline speed that's advertised. However, I consider cache pressure to be a way of cheating on benchmarks :) Benchmarks don't show cache pressure until the algorithm itself spills the L1 cache but, in a real system, cache costs. With the precomputed data only in L3 cache (tested by cycling through 10,000 contexts), UMAC takes 922.16ns to authenticate 1KB. So UMAC may give a small benefit to cases with few, busy connections, but it's a loss in the case where there are many connections (a server), or a few connections, intermittently used (i.e. a web browser). Additionally, Poly1305 can be written in a tweet(*), while UMAC is dramatically more complex. Since they are both Wegman-Carter style hashes I believe that they both have, fundamentally, well understood security properties. (See [2] for a good overview.) Thus Poly1305 is looking much more attractive to us. (* Here's an attempt in 159 chars: "Take msg in 16 byte chunks. Append 1 to each msg chunk&0-pad to 17 bytes. Interpt little-endian. Calc polynom in key[:16] mod 2^130-5. Add key[:16]. Mod 2^128.") [1] https://github.com/floodyberry/poly1305-donna [2] http://eprint.iacr.org/2013/144.pdf Cheers AGL From nico@cryptonector.com Mon Jul 29 12:40:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C1821E808C for ; Mon, 29 Jul 2013 12:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtPIZX4ZZyFP for ; Mon, 29 Jul 2013 12:40:03 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0C411E80F6 for ; Mon, 29 Jul 2013 12:39:56 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id C62E2202047 for ; Mon, 29 Jul 2013 12:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dG7JYX2Hoj7OnMEE7m15 gSHnT5U=; b=nXBYOAvxSY1DkNzvl2i4NblgiZqxxI6ZSERphizBBMk803wR46nH +1f2k+TVLyadMWEAJrrCedoA6hhCySgxgbQ9wCsLYqe4jjWLWQVigNZ/iFQQT7VD uyLOb1mAp3dOPsTrlB3PkKneNFJAD1eV34owN+tWvi4k42eeN2ivMm0= Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id E936220203C for ; Mon, 29 Jul 2013 12:39:52 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id uz6so6734786obc.3 for ; Mon, 29 Jul 2013 12:39:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2wH5sro9oqDc8EGfgXaY0PwEY9OILwUmYVonzhl836M=; b=M0DD5JikntDnJ3iHow9YXCqESIInRhb497VmefHEF1aV1UlFuLZryhb6w7bxnK16kq ODiskYKHdvaSrtVKHRpldO7hkhPEk2g7gNPC0yS39jNeJi74X9vj/JKdIlR7VkykGjMu ACPf8xC8q5VhE+oO1KIJPw9cyzcBfty3BgTu0kZX8ZzrKBT6mf9m8cWnpt+m9tJOi3OZ ns4Kmmj5qfi9fjO6jeuez12lpLU37+XYlSztULR8OBw+mOLbiQHFp5rJ/PYnCmPR8rGs h0BbmQuw7RhYGsdIC6VMQPduq5o2f7atOCLDBMlklolj4zAcLlTnpg1ZngHDd7I2vM8p 8JQQ== MIME-Version: 1.0 X-Received: by 10.42.33.129 with SMTP id i1mr21734179icd.95.1375126791874; Mon, 29 Jul 2013 12:39:51 -0700 (PDT) Received: by 10.64.130.169 with HTTP; Mon, 29 Jul 2013 12:39:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 14:39:51 -0500 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:40:10 -0000 +1. While we're at it, what about curve25519 for DH? Let's make sure this time not to leave out any combination using DH (anon and not). Nico -- From rstruik.ext@gmail.com Mon Jul 29 14:06:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7ADC21F972C for ; Mon, 29 Jul 2013 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mma2pjY1at2c for ; Mon, 29 Jul 2013 14:06:23 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EBB5521F962D for ; Mon, 29 Jul 2013 14:06:22 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 6so2667383qeb.17 for ; Mon, 29 Jul 2013 14:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wH57EUuXSdxaVBdzOwmUx9vppZt6c8C2fkCU3gFhsxs=; b=MXarZKJpsbJI09smBkH5WhAWesl1fPN2D3dgqFHvKu5RgaCiiLGCI7I37xfRNJfnnW Q0PHw1ONbhHxUR4tks8CXToIqKXEPFVVa2rgClGnr5mowS0lxi69KsbKiyiXTCmoEdgg YFSlL8Xn7KIbcNg1nK3WEDydxIy6qQcE9K82aOvHxBNWfV2ch92BuVs/kK/TzKlC2b/a 6qegcsQMIwuDt0Kj4GfqjFZjCIhVeW5dLuax7cRcpRkdnl5L0InqXLcXrG6pkUaFJtjo lxml9OJuJ25B+FVnlX7vSJpbOQBewkdSPu+/TtBysxFFHtIyr7fCzH2oj09PZc2WtC1L 9hdQ== X-Received: by 10.49.15.130 with SMTP id x2mr74877371qec.47.1375131981670; Mon, 29 Jul 2013 14:06:21 -0700 (PDT) Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPSA id t5sm24922690qae.9.2013.07.29.14.06.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 14:06:20 -0700 (PDT) Message-ID: <51F6D946.50109@gmail.com> Date: Mon, 29 Jul 2013 17:06:14 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Langley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 21:06:24 -0000 Hi Adam: Let us add (re)tweetability to the requirements for algorithm design! While we are at it, let us impose this to all RFCs, technical papers, source code, poetry, text books, and our daily news as well. Well, with the latter we are already nearly there... Darn, now I may have surpassed the tweet limit myself! Rene == Additionally, Poly1305 can be written in a tweet(*), while UMAC is dramatically more complex. On 7/29/2013 3:09 PM, Adam Langley wrote: > I cannot make it to Berlin I'm afraid (or, indeed, any meetings until > at least IETF 91) so I'm writing my thoughts on > draft-josefsson-salsa20-tls-02, which is scheduled for discussion. > > We (Google) support the addition of Salsa20 as a cipher in TLS. Having > a secure cipher which is fast and constant time on all platforms is > important. It's also good to have an alternative to AES in the wings > should that be needed in the future. At the moment I consider RC4 and > AES-CBC to be mortally wounded, even if we have to continue supporting > them for many years yet. > > Salsa20/12 is something that we are currently working on supporting. > > However, I believe that Poly1305 is superior to UMAC and we're looking > at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the > nonce generated directly by Salsa20/12, not via AES.) > > (For the following, I used UMAC in nettle 2.7 and Andrew M's > implementation of Poly1305[1], both on a E5-2690@2.90GHz with > Hyperthreading and Turboboost disabled.) > > UMAC96 (with AES for the nonce generation) takes 9146.1ns to > authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes > 561.4ns. > > However, that's not the whole story for UMAC because it can use 1.5KB > of memory for precomputation, after which it can authenticate 1KB of > memory in just 329ns with that in L1. That's typically the headline > speed that's advertised. > > However, I consider cache pressure to be a way of cheating on > benchmarks :) Benchmarks don't show cache pressure until the algorithm > itself spills the L1 cache but, in a real system, cache costs. > > With the precomputed data only in L3 cache (tested by cycling through > 10,000 contexts), UMAC takes 922.16ns to authenticate 1KB. > > So UMAC may give a small benefit to cases with few, busy connections, > but it's a loss in the case where there are many connections (a > server), or a few connections, intermittently used (i.e. a web > browser). > > Additionally, Poly1305 can be written in a tweet(*), while UMAC is > dramatically more complex. Since they are both Wegman-Carter style > hashes I believe that they both have, fundamentally, well understood > security properties. (See [2] for a good overview.) > > Thus Poly1305 is looking much more attractive to us. > > > (* Here's an attempt in 159 chars: "Take msg in 16 byte chunks. Append > 1 to each msg chunk&0-pad to 17 bytes. Interpt little-endian. Calc > polynom in key[:16] mod 2^130-5. Add key[:16]. Mod 2^128.") > > [1] https://github.com/floodyberry/poly1305-donna > [2] http://eprint.iacr.org/2013/144.pdf > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nick.a.mathewson@gmail.com Mon Jul 29 17:40:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6D21F9B85 for ; Mon, 29 Jul 2013 17:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0-XrxHc6JFU for ; Mon, 29 Jul 2013 17:40:38 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7E421F9B60 for ; Mon, 29 Jul 2013 17:40:38 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id r11so953187lbv.22 for ; Mon, 29 Jul 2013 17:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=J3hnIzU35dtybbVLuQMkrvuRmqZDjB5PvVklmDGgmkQ=; b=vBfJvQBGLo+SRiLWOXVQ8uvGARbdhd/XjMsIsbSJwUm3SQjyn6Z20ka5feyYEq5sJ2 bx3iodirGdZFkV/UysQESjnyE9k5dw4rnYrtKAsGcxvJDb5a97k93PnXWXLdgkpg+jRu 1J0ZPpW3cN4euF8Efd+FOgXX6t7VM9W8KfTigPShNRDxf5eW3xZahMTtzEqThGf4W//o GrOT+5Z9c1qVpsBGboxMRA5toSxsubh3tjc+pTTcDhfiTwb7LVIkiOwXkZDyghBdjaDh Pqle3oDuTMTDj4flrHyiOtdiBUIwTN4fvOIt1LTNwllhiTEFAaYD/5Lc2XeR0sqNqjMn ugBg== MIME-Version: 1.0 X-Received: by 10.152.87.171 with SMTP id az11mr6867875lab.40.1375144837367; Mon, 29 Jul 2013 17:40:37 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.112.30.166 with HTTP; Mon, 29 Jul 2013 17:40:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 20:40:37 -0400 X-Google-Sender-Auth: jrFUGBf2WRa4s3Cx8B0os5DT8i0 Message-ID: From: Nick Mathewson To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:40:39 -0000 On Mon, Jul 29, 2013 at 3:09 PM, Adam Langley wrote: > I cannot make it to Berlin I'm afraid (or, indeed, any meetings until > at least IETF 91) so I'm writing my thoughts on > draft-josefsson-salsa20-tls-02, which is scheduled for discussion. > > We (Google) support the addition of Salsa20 as a cipher in TLS. Having > a secure cipher which is fast and constant time on all platforms is > important. It's also good to have an alternative to AES in the wings > should that be needed in the future. At the moment I consider RC4 and > AES-CBC to be mortally wounded, even if we have to continue supporting > them for many years yet. Hi! Nick Mathewson (Tor guy) here. We at Tor also support adding Salsa20 as a TLS ciphersuite, for about the same reasons as Adam. (We won't be able to start using it much till browsers start using it, of course, since it's not in our interest to be among the first adopters of any externally detectable TLS feature.) I also personally concur with Adam's arguments in favor of Poly1305, but UMAC wouldn't be a disaster. best wishes, -- Nick Mathewson From ted@krovetz.net Mon Jul 29 20:03:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD3311E81A3 for ; Mon, 29 Jul 2013 20:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiVz2Yl3klht for ; Mon, 29 Jul 2013 20:03:43 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8091311E81A4 for ; Mon, 29 Jul 2013 20:03:43 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so5446081pbb.14 for ; Mon, 29 Jul 2013 20:03:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=X0ypk0L5Czxn7BHDb/Mf62w3FP6ib9OVEO0LfkWNlmw=; b=okulxuqkXso2SjBVcg/S9uP/Z+vcI6OODHrnaLxIgICUgLexVMH5PzMIUi6gMXwv7K 8cR5ZQw/n/yPDVLdNhzCVrqVoCVezprvcotnqq8d1nOq7YOf47ZSf/Ww+fpMoo55ISt1 c3l6J5EjyyB8BfuEbiN5lFlAv4hADa0Bt0PQjGDvGciiznM0TgslUgthY+OMq20u7VoF jK2tbthTaiL1i8nVa6M3/22NbbVrieQ87OK5XuVqMP34Efsz3i3+hXzN2WXs3egYI4km xZ9YONP8FZHNLVFPowcQ9C/GOzP54ZbLGilH6yrcdc2PqZj0+yDH/hhxJOukUoQhLP9z CExw== X-Received: by 10.66.51.102 with SMTP id j6mr71455044pao.80.1375153423053; Mon, 29 Jul 2013 20:03:43 -0700 (PDT) Received: from [192.168.3.127] (cpe-72-130-196-174.hawaii.res.rr.com. [72.130.196.174]) by mx.google.com with ESMTPSA id w8sm23975565pab.12.2013.07.29.20.03.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 20:03:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Krovetz In-Reply-To: Date: Mon, 29 Jul 2013 17:03:44 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> References: To: tls@ietf.org X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQmfmF92Yfny8iIV8Wl3c133VuPrAKhM9+oiEOW4iWZXog/r+7s+EQizUTTiXK1GiPJRejXd X-Mailman-Approved-At: Tue, 30 Jul 2013 01:53:06 -0700 Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:03:48 -0000 > However, I believe that Poly1305 is superior to UMAC and we're looking > at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the > nonce generated directly by Salsa20/12, not via AES.) The key agility in a simple poly hash is certainly much better than that = of UMAC, and I agree that UMAC is not appropriate for some usage = scenarios. I don't know enough about TLS usage, however, to comment on = whether UMAC is a bad choice. A couple of alternatives that may be worth considering... -- In an attempt to simplify from UMAC, I developed VMAC as an alternative = that uses considerably less internal key and is significantly faster on = 64-bit architectures. Even from L3 cache it is probably 2-3 times faster = than Poly1305. http://fastcrypto.org/vmac/ http://krovetz.net/csus/papers/vhash-revise.pdf http://krovetz.net/csus/papers/vmac.pdf -- I'd also suggest using Bernstein's Chacha instead of Bernstein's Salsa. = It has the same core as Salsa, but Bernstein cleaned up the rough edges = of its prolog and epilog, making it smaller, faster and nicer to = program. Chacha is basically a better Salsa. http://cr.yp.to/chacha.html -Ted= From n.mavrogiannopoulos@gmail.com Tue Jul 30 02:02:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB3A21E80C2 for ; Tue, 30 Jul 2013 02:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu4dDIPbjRnn for ; Tue, 30 Jul 2013 02:01:40 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B27521E80BC for ; Tue, 30 Jul 2013 02:00:32 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so1104765qcw.9 for ; Tue, 30 Jul 2013 02:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nEggyb6wLVZIAN5E7OkVb28H8d+HBdMIiABWAHuPI2g=; b=VZktEdRPNO75kIcAWXhs4FROF7kt4tYZnUx8aYmnrj8QrjOBKFZpO0qIxhAVDH3CHV RyD70Ue/ImkgGVh/WU+yNTpdugve8SRcpgzB8gguHrO1gxjAdixLmttn1gruJ/8Rkxzj mzSjZf+RvCzt5IaibwrJrZyJxUcoTATHx/i3n8GWi9grDRMG26Tzuu7ROIA/4vLm5Ujn c358yVbYcy+REPLfcfqaonxZhhO3mMSwQE11s+jylBqDy5r/nAzNdNDNe154DAOS0urZ ocC30ugd1/ZF7QZHqXeDTLxCr9qG+ZMD8Mv69gbz0P9laB7S41YbKn+pLKPWzxYQXES+ x0Lw== MIME-Version: 1.0 X-Received: by 10.49.116.104 with SMTP id jv8mr35687372qeb.34.1375174812663; Tue, 30 Jul 2013 02:00:12 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.151.195 with HTTP; Tue, 30 Jul 2013 02:00:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 11:00:12 +0200 X-Google-Sender-Auth: KLeqVe22JgTEQXQm0XAzjAw9A9I Message-ID: From: Nikos Mavrogiannopoulos To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:02:00 -0000 On Mon, Jul 29, 2013 at 9:09 PM, Adam Langley wrote: > I cannot make it to Berlin I'm afraid (or, indeed, any meetings until > at least IETF 91) so I'm writing my thoughts on > draft-josefsson-salsa20-tls-02, which is scheduled for discussion. [...] > Salsa20/12 is something that we are currently working on supporting. > However, I believe that Poly1305 is superior to UMAC and we're looking > at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the > nonce generated directly by Salsa20/12, not via AES.) Thanks. The choice between UMAC and Poly1305 is indeed an open issue right now. > (For the following, I used UMAC in nettle 2.7 and Andrew M's > implementation of Poly1305[1], both on a E5-2690@2.90GHz with > Hyperthreading and Turboboost disabled.) > UMAC96 (with AES for the nonce generation) takes 9146.1ns to > authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes > 561.4ns. > However, that's not the whole story for UMAC because it can use 1.5KB > of memory for precomputation, after which it can authenticate 1KB of > memory in just 329ns with that in L1. That's typically the headline > speed that's advertised. That is, however, an important advantage in dedicated peer-to-peer connections (e.g., VPN), which is how I test the current ciphersuites. btw. was Poly1305 used with salsa20/12 in this comparison or AES? If it is salsa20, I believe that the numbers would be quite different for UMAC if used with salsa20 as well. In any case, whether AES is used on the MAC (UMAC or Poly1305) or the cipher of the ciphersuite is also an issue to be addressed. The only issue for using the cipher instead of AES, is the fact that there are no test vectors (in an RFC or any other document), and both of these variants were defined using AES so by combining the MAC with another cipher TLS will be quite unique. Nevertheless that idea of combining them with the actual cipher in use is quite nice and has advantages in a number of systems. > Additionally, Poly1305 can be written in a tweet(*), while UMAC is > dramatically more complex. Since they are both Wegman-Carter style > hashes I believe that they both have, fundamentally, well understood > security properties. (See [2] for a good overview.) Complexity is indeed an issue, but tweetocity doesn't seem to be a clear advantage :) > Thus Poly1305 is looking much more attractive to us. While I like UMAC, but I also see the advantages of Poly1305. In any case, I think it would be a good idea to add them to the list (or even replace umac if there are no clear advantages) if that draft proceeds. regards, Nikos From benl@google.com Tue Jul 30 02:40:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6721E80C8 for ; Tue, 30 Jul 2013 02:40:55 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXjh1dijvZrr for ; Tue, 30 Jul 2013 02:40:52 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A13FE11E81C8 for ; Tue, 30 Jul 2013 02:40:47 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id l10so1291282oag.33 for ; Tue, 30 Jul 2013 02:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VzMQ+dUmZ2PIMwpDIfDEM2dCDJITBwHa3cOfRjR7Ysg=; b=g1xnkn2LbsPRiNsHV6vE7bPZOsL5i9fdcJKOsyw8ddJEwzjN38eLLCP95lVhIUpv3V jjqMGRHJd6PxwdW/7f+g/pOjs/NJs4i+Ex4mfu4RiaNOAG6Vycjbgw9h5IoiODpoWRCC z3Io7npO/2If/Nc8edM5dYNyfbAS2rFsPUbNTxpE2hVQ75lB5hf2eh+8ArPVB6NLAt00 sc0/R2ROIbuGBVxu2G9yt8RPDjmwVKm9U8nsnqKrMc88losUWqNOlUDR7InsgKLQi884 1+qY0AteehDxrYIpcjDJgfVUVMOgN0RXnk0lcmB7/f6ZyqBRU9oEMi/od9g97XdB/aiL hhhg== X-Google-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:x-gm-message-state; bh=VzMQ+dUmZ2PIMwpDIfDEM2dCDJITBwHa3cOfRjR7Ysg=; b=AMraTTaKgGFls+SDG4vUOITjw/ufUhl1ODP6U9VFnhht0caX3yQ2qA5UEq8s9A2Aqu r3+IutHAi19w40pH14nbo8BOpjaS+gknxm/Q3lHb8RbxSmigmW08D4cC2JxzVk1auEQK 5RV7ERHfVTe4oDTQMXrbNqXsgaheZ/5LAjAygvRq9FaREgbIhrZJX47MwOXIMbgBhGFh 2t5soip5Nlw35bKPVVrrSzJK3r78MutyBennUoxyCXu5I5yrenBGS16JNMLdI97Diw3L EXfPupKxEzseXqiGXmrD6vdgjulRcZNmh+b912A5pAaGJG5J1ZBuNykV/0qvB0ONL52h KJmg== MIME-Version: 1.0 X-Received: by 10.43.57.9 with SMTP id we9mr22159375icb.90.1375177227206; Tue, 30 Jul 2013 02:40:27 -0700 (PDT) Received: by 10.64.230.239 with HTTP; Tue, 30 Jul 2013 02:40:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 10:40:27 +0100 Message-ID: From: Ben Laurie To: Adam Langley Content-Type: multipart/alternative; boundary=bcaec51b1b9f21a44604e2b76651 X-Gm-Message-State: ALoCoQk2NKJ6H6BSCyLaQTscQlC/HD6NRNP9PXPZaY3sD69wECeCz0MhPQPxbITAqL90m3wKbvK7pwClQdesdewx2PweJKquB7rg8BqcCjIb2Q7kFNJ2174zklQbTzBD2KA7BCot8bEegnrcn7pt5NvmW9HND+zPD3La63Sd9fxzoBhcROV0I/CDzM+j6MmVpZoSRqkVhihT Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:40:59 -0000 --bcaec51b1b9f21a44604e2b76651 Content-Type: text/plain; charset=ISO-8859-1 Also, defining ciphersuites for SSL 3, TLS 1.0/1.1 would be good, so we can use them despite downgrade attacks. On 29 July 2013 20:09, Adam Langley wrote: > I cannot make it to Berlin I'm afraid (or, indeed, any meetings until > at least IETF 91) so I'm writing my thoughts on > draft-josefsson-salsa20-tls-02, which is scheduled for discussion. > > We (Google) support the addition of Salsa20 as a cipher in TLS. Having > a secure cipher which is fast and constant time on all platforms is > important. It's also good to have an alternative to AES in the wings > should that be needed in the future. At the moment I consider RC4 and > AES-CBC to be mortally wounded, even if we have to continue supporting > them for many years yet. > > Salsa20/12 is something that we are currently working on supporting. > > However, I believe that Poly1305 is superior to UMAC and we're looking > at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the > nonce generated directly by Salsa20/12, not via AES.) > > (For the following, I used UMAC in nettle 2.7 and Andrew M's > implementation of Poly1305[1], both on a E5-2690@2.90GHz with > Hyperthreading and Turboboost disabled.) > > UMAC96 (with AES for the nonce generation) takes 9146.1ns to > authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes > 561.4ns. > > However, that's not the whole story for UMAC because it can use 1.5KB > of memory for precomputation, after which it can authenticate 1KB of > memory in just 329ns with that in L1. That's typically the headline > speed that's advertised. > > However, I consider cache pressure to be a way of cheating on > benchmarks :) Benchmarks don't show cache pressure until the algorithm > itself spills the L1 cache but, in a real system, cache costs. > > With the precomputed data only in L3 cache (tested by cycling through > 10,000 contexts), UMAC takes 922.16ns to authenticate 1KB. > > So UMAC may give a small benefit to cases with few, busy connections, > but it's a loss in the case where there are many connections (a > server), or a few connections, intermittently used (i.e. a web > browser). > > Additionally, Poly1305 can be written in a tweet(*), while UMAC is > dramatically more complex. Since they are both Wegman-Carter style > hashes I believe that they both have, fundamentally, well understood > security properties. (See [2] for a good overview.) > > Thus Poly1305 is looking much more attractive to us. > > > (* Here's an attempt in 159 chars: "Take msg in 16 byte chunks. Append > 1 to each msg chunk&0-pad to 17 bytes. Interpt little-endian. Calc > polynom in key[:16] mod 2^130-5. Add key[:16]. Mod 2^128.") > > [1] https://github.com/floodyberry/poly1305-donna > [2] http://eprint.iacr.org/2013/144.pdf > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --bcaec51b1b9f21a44604e2b76651 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Also, defining ciphersuites for SSL 3, TLS 1.0/1.1 would b= e good, so we can use them despite downgrade attacks.


On 29 July 2013 20:09, Adam L= angley <agl@google.com> wrote:
I cannot make it to Berlin I'm afraid (o= r, indeed, any meetings until
at least IETF 91) so I'm writing my thoughts on
draft-josefsson-salsa20-tls-02, which is scheduled for discussion.

We (Google) support the addition of Salsa20 as a cipher in TLS. Having
a secure cipher which is fast and constant time on all platforms is
important. It's also good to have an alternative to AES in the wings should that be needed in the future. At the moment I consider RC4 and
AES-CBC to be mortally wounded, even if we have to continue supporting
them for many years yet.

Salsa20/12 is something that we are currently working on supporting.

However, I believe that Poly1305 is superior to UMAC and we're looking<= br> at Salsa20/12+Poly1305, not UMAC. (Note: that's Poly1305 with the
nonce generated directly by Salsa20/12, not via AES.)

(For the following, I used UMAC in nettle 2.7 and Andrew M's
implementation of Poly1305[1], both on a E5-2690@2.90GHz with
Hyperthreading and Turboboost disabled.)

UMAC96 (with AES for the nonce generation) takes 9146.1ns to
authenticate 1K of data, HMAC-SHA1(1K) takes 3667ns and Poly1305 takes
561.4ns.

However, that's not the whole story for UMAC because it can use 1.5KB of memory for precomputation, after which it can authenticate 1KB of
memory in just 329ns with that in L1. That's typically the headline
speed that's advertised.

However, I consider cache pressure to be a way of cheating on
benchmarks :) Benchmarks don't show cache pressure until the algorithm<= br> itself spills the L1 cache but, in a real system, cache costs.

With the precomputed data only in L3 cache (tested by cycling through
10,000 contexts), UMAC takes 922.16ns to authenticate 1KB.

So UMAC may give a small benefit to cases with few, busy connections,
but it's a loss in the case where there are many connections (a
server), or a few connections, intermittently used (i.e. a web
browser).

Additionally, Poly1305 can be written in a tweet(*), while UMAC is
dramatically more complex. Since they are both Wegman-Carter style
hashes I believe that they both have, fundamentally, well understood
security properties. (See [2] for a good overview.)

Thus Poly1305 is looking much more attractive to us.


(* Here's an attempt in 159 chars: "Take msg in 16 byte chunks. Ap= pend
1 to each msg chunk&0-pad to 17 bytes. Interpt little-endian. Calc
polynom in key[:16] mod 2^130-5. Add key[:16]. Mod 2^128.")

[1] https://github.com/floodyberry/poly1305-donna
[2] http:= //eprint.iacr.org/2013/144.pdf


Cheers

AGL
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--bcaec51b1b9f21a44604e2b76651-- From internet-drafts@ietf.org Tue Jul 30 06:36:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D3B21F9CEF; Tue, 30 Jul 2013 06:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg4JcqMARzfo; Tue, 30 Jul 2013 06:36:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06E21F9D01; Tue, 30 Jul 2013 06:36:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730133640.26429.83101.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 06:36:40 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:36:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Out-of-Band Public Key Validation for Transport Layer Se= curity (TLS) Author(s) : Paul Wouters Hannes Tschofenig John Gilmore Samuel Weiler Tero Kivinen Filename : draft-ietf-tls-oob-pubkey-09.txt Pages : 15 Date : 2013-07-30 Abstract: This document specifies a new certificate type and two TLS extensions, one for the client and one for the server, 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-09 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 hannes.tschofenig@gmx.net Tue Jul 30 06:48:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF5021E8084 for ; Tue, 30 Jul 2013 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.666 X-Spam-Level: X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW2gXX0JNl5A for ; Tue, 30 Jul 2013 06:48:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8611E81E2 for ; Tue, 30 Jul 2013 06:48:24 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M7m0a-1U8mRj1TYe-00vNEr for ; Tue, 30 Jul 2013 15:48:23 +0200 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2013 15:48:22 +0200 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:rsBiRDdB7S/E6enQAmdfRJF9iW+UEJpRvxPHQe4lmj5pV2Yz741 kprMQhVPi5eBuMzib1fNn8r1wh/oPX0XtoR8TwiOoFX8CPbJEYLQNyYaejFVNoMoPrvSaFD QoJ7IviVy4LvNtJ0yGPktIcphkC/eHWcvC81jbT9Ky/BA3+3DbdGvQXCIIH4qpGW15hUc84 6RTbwWJGxO4MRQVtiolRg== Subject: [TLS] draft-ietf-tls-oob-pubkey: Version -09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:48:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all,=20 I have just submitted an update to the TLS OOB document to incorporate = the remarks from Sean and Hauke.=20 The updated version can be found here:=20 https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR98QmAAoJEGhJURNOOiAtUZ0H/A/Ba7W5U7NhyQjcZsolT8xA wiPb7ac5+cL47fSxecH65Cfh9anmAy9fO06+50sRmhMvmxlg4+3H8II9GXWEwKXu iMGzbNGdXTytdXZ7y0vC5x0iungQ/xpzSyqRVeTHz/JjlYqpj4D/J46KBh24vDEx mUnoVkeqip18D4T+gzJOj/rD/qYtjurR5nKqvlmS+0xEK8jsZpSnE0lTQDMwBmgk SfVtuRdu8sa0peBcpq9/cLVvtN1lkeGBzi4z1EwUf2Tzh4ce41wkV/GlJ2e8QjI+ 2kt3iLrIAZMWWYrMLFtsVyS8dzFT5EaPXk8zRhzHPGLZOuvmmxQga4QlvuyO4yY=3D =3DEBDk -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Tue Jul 30 06:50:20 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345B021E80C6 for ; Tue, 30 Jul 2013 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.661 X-Spam-Level: X-Spam-Status: No, score=-102.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi2b6d6tUJ5O for ; Tue, 30 Jul 2013 06:50:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id BAB4711E81F4 for ; Tue, 30 Jul 2013 06:50:09 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MCOdh-1Uv7uD0HvF-009Abb for ; Tue, 30 Jul 2013 15:50:08 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <51EAAC53.6080704@hauke-m.de> Date: Tue, 30 Jul 2013 15:50:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B146A19-9281-488D-8F33-738BCF1FF9FB@gmx.net> References: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> <51E5338F.9030100@hauke-m.de> <74975B22-61CB-47AD-AEFF-A273C8F6ECC8@gmx.net> <51EAAC53.6080704@hauke-m.de> To: Hauke Mehrtens X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:3dgaUM3qyrr6mPQjt1DM1HIO97e23t+Irl+LDtLmqgjv9FWetFY GuPcKrmq0mZW4k/89DR8nGnqR9+b5VxhVzb0nowIQ4pzIk9Jito2tSLyUAd0bYQYVbcreiH P4+DZZbSJp4g/pcFUCDrjj6OKnjkqkp2cuHaibv047difEvth6gjfU9uT8USGqE7mqCf4p4 UyE7FGDvC1XM3ZURHT2Fw== Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:50:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Hauke,=20 I addressed your earlier comments with the most recent draft update. = There is this issue left:=20 >>> Could you add some list definition where the numbers assigned by >>> the IANA should be added later. I like how it is done in=20 >>> draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0]. >>=20 >> The above-mentioned draft uses a different registry but I guess you >> are asking for a snapshot of the current registry. For example, >> something like this: >>=20 >> - ------------------------------------------------------ Value >> Description Reference 0 X.509 >> [RFC6091] 1 OpenPGP [RFC6091] 3 = Raw >> Public Key [This RFC] 3-223 Unassigned 224-255 = Reserved for >> [RFC6091] Private Use - >> ------------------------------------------------------ >>=20 >> Is this correct? >=20 > Isn't the final number in the end of the standardization process added > to the draft? I was just thinking about adding a placeholder for that > number in the draft. For the Certificate Type there is already the > excepted number added in the draft, but for the > server_certificate_type and client_certificate_type there is a > placeholder missing. >=20 I have not added the current snapshot of the registry to the draft at = the moment.=20 I am not convinced I should do it since the (more accurate) data will in = the end be in the IANA repository.=20 Ciao Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR98SPAAoJEGhJURNOOiAtDUUH/jA1eMHfshjK1OSzyGpvlUH6 D6v56HePP09g0SJJgmZKGUcFjpgDSqvD8WE7so+RXdoKsoPfpsI4Mkh9XmxQWFbo HHWloVsqMzp22FpdhQb669/zsr6GKL9nyQkEWI1EU8qVIm1sMOy9AF/+Mm3y4M8p 4LyWJYja5pWY/EV7wBsLABdVTbTXJSKEWRoyMapn+WZeU5CV6UeH0q5RYu+I9dam lwT5uyNquQGCHFTkL3aXX4a1q5mNOQv8dTCMOom4kryvNLb+rLaUfK45XDnmY2/8 HTTNAVh0H/4c6PIABuNOpWcPles3tLtGesodFFRV8zT4In9bYBHUZUBIDEj4kJo=3D =3Dj/Zc -----END PGP SIGNATURE----- From agl@google.com Tue Jul 30 07:45:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E67221F8C93 for ; Tue, 30 Jul 2013 07:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggV3BBTJ-bpJ for ; Tue, 30 Jul 2013 07:45:27 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 28EDD11E81FF for ; Tue, 30 Jul 2013 07:45:27 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so881203obc.3 for ; Tue, 30 Jul 2013 07:45:25 -0700 (PDT) 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=GIJxHGWCW6i/FdHVxRUzmQSo7qZSxgpwAkzOSCAH+Jc=; b=d3zLjC8pc5HKwDIqrZTLSHGl9VIo6yX1mVdSFPbes092Q8Ih66uORHdbRGOk+GlqV+ agX1PSqwHh+lBrd5tAm0zmvHcqmmHDGbZTl9I/IJfVg4k/stawVwJUYCsZ6gPmEt4Ocu Pa9XBct6qOhGIY00guUM3qszBdyGqDTmrV7AiXEKchdpjJCV0+bWDqVX9N2mPsERgAu0 tHFnUgp/hPiaed8+MezNw9coHe/X4co5sTBhk+Zje7geyM8IOAoiQZIi0sPcumytP4RS 06/YcMMrnI0Z0NN3equ+mea4Qii5vwuNMZCavVHEPkBt+n6YMROsvQuNo6OyQwiNYAZ0 U+wg== X-Google-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:x-gm-message-state; bh=GIJxHGWCW6i/FdHVxRUzmQSo7qZSxgpwAkzOSCAH+Jc=; b=S/YuYQp2NKLFU7i5WYs7sPgfBowiH8vRQirCuIB3hTpUq0sxH/BUE2mDMF8I6LHJEs Z3Expc4SnJwp2Y/VrJry1a7bluQM9tqM5xmPLDch1+Q2Eq1aU06Wudn2gosXf42q5CvQ gu8HNoEr0+O/Uq7d+ay8C2NB62qalnByRWwL+X3mcSbNOy5lS6AlC/qOfr+a9QKq3DFu 8wfWC7amYBrXkwimjd6Aa4+n785kuj8pTAHCniddtBoHT1jRiby2vp8L2N+SIUMbjLhp YliWRpHZufsQFpT5Ahr7xpsbwqtu9S2NWP5Z5iuajQcq4dUuVx8ZHcfyWg5t+TJkG7rk vhRw== X-Received: by 10.182.200.230 with SMTP id jv6mr9428366obc.46.1375195525579; Tue, 30 Jul 2013 07:45:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Tue, 30 Jul 2013 07:45:05 -0700 (PDT) In-Reply-To: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> From: Adam Langley Date: Tue, 30 Jul 2013 10:45:05 -0400 Message-ID: To: Ted Krovetz Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn+fY6qag4PCKOUlPkE5Iz1s96C88j2WscfXz6NdjKvsOeIzsnbggUbSA5sd7DHCPO8E1aZXSNs/TMISkWMQ87OebITSsB4CnKb9a3jyuTtLZBRfkED1CHV+ZEKDg+N5Um6puuXzzAwvn8Rh3GE/J6S/UEgSyDnXopVV46F0LWRmiSuOW2pLRf89RUKj85turYlHJwW Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:45:28 -0000 On Mon, Jul 29, 2013 at 11:03 PM, Ted Krovetz wrote: > In an attempt to simplify from UMAC, I developed VMAC as an alternative that uses considerably less internal key and is significantly faster on 64-bit architectures. Even from L3 cache it is probably 2-3 times faster than Poly1305. > > http://fastcrypto.org/vmac/ > http://krovetz.net/csus/papers/vhash-revise.pdf > http://krovetz.net/csus/papers/vmac.pdf I agree that VMAC has considerably less memory footprint, around 168 bytes in total, and is faster. I will try to repeat the above benchmarks for VMAC this week. (And, hopefully, run some tests on ARM.) > I'd also suggest using Bernstein's Chacha instead of Bernstein's Salsa. It has the same core as Salsa, but Bernstein cleaned up the rough edges of its prolog and epilog, making it smaller, faster and nicer to program. Chacha is basically a better Salsa. > > http://cr.yp.to/chacha.html I do like ChaCha more than Salsa. However, in this case we don't have the theoretical foundations of polynomial authenticators to stand on. Salsa is what gets reviewed, ChaCha has had relatively little attention. The improvement from Salsa to ChaCha doesn't seem to be large enough to justify switching. Having said that, I'm fine with either. Cheers AGL From agl@google.com Tue Jul 30 07:53:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C00A21F9C8E for ; Tue, 30 Jul 2013 07:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giSjDX2GGqj7 for ; Tue, 30 Jul 2013 07:53:10 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9621E80DE for ; Tue, 30 Jul 2013 07:53:07 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n12so1345368oag.25 for ; Tue, 30 Jul 2013 07:53:06 -0700 (PDT) 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=S7tlxIfxrmguZSUTiYZEBmYGzZ5lh3YLCgDvaIlcIOQ=; b=ga2TE0to4K+Lkvd17sK3J1HML63RK8EpxIBccITt5ooVhyGeBYV6L7G2fykHFGTAu1 uhpuLZhMPljPWEv2hGX0PTArLdwsmfRp1/wJGnpbX+JSSxlXXttiTbyhCAPTcR3DAF5t DLpcFPR+hJj0UMTbfZ5IV7I3veX1aCpPkSpAlJuCvZEGeVgnUeLOm0cySKLzw0vvGfAq t1mqxr8KTzbOEpkihpq58r45dj6dDQmoxPlXgVN8J+MgvMD9Otoq4kRRKaEydXRh6GCN lYhTBL412dHHSV6TE2CsXqcBl4AGTaHv7ToFk7IlyL/lnAndQrGJOeq93IZh+4zPzb78 mJig== X-Google-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:x-gm-message-state; bh=S7tlxIfxrmguZSUTiYZEBmYGzZ5lh3YLCgDvaIlcIOQ=; b=VPW0kw9GZmMywwd9y4HNm/jTVqsUFRhcTnIJCIM+rfrkd+pb/0bDLsayqa39NycjRc QjXx55OI5jEKVWOKug7fgXs0dRJ45jCqr+/rSr0dYcPVJHWniqq2NAqbre8SHPox6iVY gvICvG/xnjhiu84/uozJQKE0HTy6A1Ri2VrW2Mqm6598rXtTVAUCaHa/Jv2bYxaD+wpI KDMniDFurD8hhMDT/P1EshYLRdCQzN5ub7E1Np3sl9/PR3AfqPD5U4QY1QN+QgK7njl+ spO4+5Wt8JQdmaphoHGyiSBjP6PCKeelvvamWkgscFAYgc8xQm6bFKOx9mW1X+tCcVaW me4g== X-Received: by 10.60.60.167 with SMTP id i7mr5208120oer.58.1375195986820; Tue, 30 Jul 2013 07:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Tue, 30 Jul 2013 07:52:46 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Tue, 30 Jul 2013 10:52:46 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn923c2O6mwD5etL1llaO2UnnPKPH86KIzm2+u7YzMABkRaiuc4pZLMUnEajZYTOgC7DkVh04RNQ1S1Vk82nO8MUDrSGeIBKCL2xZXq2eTQObga6jWXa8U5eHiesXe8mvu0mxb+61LB+JwFNCpVYzxNuHKc2ntFJdGpo2y/VapRsqBe28ndq0pOehEdykrTyXYm/Kz0 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:53:11 -0000 On Tue, Jul 30, 2013 at 5:00 AM, Nikos Mavrogiannopoulos wrote: > btw. was Poly1305 used with salsa20/12 in this comparison or AES? If > it is salsa20, I believe that the numbers would be quite different for > UMAC if used with salsa20 as well. I measured UMAC with AES as you had previously indicated that was what you were aiming at. (I measured Poly1305's raw speed as the difference is small.) If UMAC were measured without the AES operation then I think ~20ns could be removed, although I'm using tables from bench.cr.yp.to due to time. > Complexity is indeed an issue, but tweetocity doesn't seem to be a > clear advantage :) The simplicity is of some value, although I'll admit that the tweet left some things under specified :) Cheers AGL From geoffk@geoffk.org Tue Jul 30 11:26:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C65421E8063 for ; Tue, 30 Jul 2013 11:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EmlIFU1pZYW for ; Tue, 30 Jul 2013 11:26:22 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 671DA11E80F2 for ; Tue, 30 Jul 2013 11:26:22 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id C4A5F33D249; Tue, 30 Jul 2013 18:26:16 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Ben Laurie References: From: Geoffrey Keating Date: 30 Jul 2013 11:26:16 -0700 In-Reply-To: Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 18:26:27 -0000 Ben Laurie writes: > Also, defining ciphersuites for SSL 3, TLS 1.0/1.1 would be good, so we can > use them despite downgrade attacks. Surely if you discover that the remote end appears to support only SSL 3 but yet somehow supports Salsa, you should stop trying to communicate because you're under a downgrade attack? From hauke@hauke-m.de Tue Jul 30 12:35:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2C221E80A1 for ; Tue, 30 Jul 2013 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojsrCuhnjL3S for ; Tue, 30 Jul 2013 12:35:36 -0700 (PDT) Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5981821E80C0 for ; Tue, 30 Jul 2013 12:35:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id B8B4E857F; Tue, 30 Jul 2013 21:35:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezcMcxhjE75d; Tue, 30 Jul 2013 21:35:18 +0200 (CEST) Received: from [IPv6:2001:470:1f0b:447:ad8a:fbd:3d57:3b2e] (unknown [IPv6:2001:470:1f0b:447:ad8a:fbd:3d57:3b2e]) by hauke-m.de (Postfix) with ESMTPSA id 6A7A38F61; Tue, 30 Jul 2013 21:35:18 +0200 (CEST) Message-ID: <51F81572.8000300@hauke-m.de> Date: Tue, 30 Jul 2013 21:35:14 +0200 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hannes Tschofenig References: <20130715231127.14144.44003.idtracker@ietfa.amsl.com> <51E5338F.9030100@hauke-m.de> <74975B22-61CB-47AD-AEFF-A273C8F6ECC8@gmx.net> <51EAAC53.6080704@hauke-m.de> <3B146A19-9281-488D-8F33-738BCF1FF9FB@gmx.net> In-Reply-To: <3B146A19-9281-488D-8F33-738BCF1FF9FB@gmx.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 19:35:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/30/2013 03:50 PM, Hannes Tschofenig wrote: > Hi Hauke, > > > I addressed your earlier comments with the most recent draft > update. There is this issue left: > >>>> Could you add some list definition where the numbers assigned >>>> by the IANA should be added later. I like how it is done in >>>> draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0]. >>> >>> The above-mentioned draft uses a different registry but I guess >>> you are asking for a snapshot of the current registry. For >>> example, something like this: >>> >>> - ------------------------------------------------------ Value >>> Description Reference 0 X.509 [RFC6091] 1 >>> OpenPGP [RFC6091] 3 Raw Public Key >>> [This RFC] 3-223 Unassigned 224-255 Reserved for [RFC6091] >>> Private Use - >>> ------------------------------------------------------ >>> >>> Is this correct? > >> Isn't the final number in the end of the standardization process >> added to the draft? I was just thinking about adding a >> placeholder for that number in the draft. For the Certificate >> Type there is already the excepted number added in the draft, but >> for the server_certificate_type and client_certificate_type there >> is a placeholder missing. > > I have not added the current snapshot of the registry to the draft > at the moment. I am not convinced I should do it since the (more > accurate) data will in the end be in the IANA repository. > Hi Hannes, yes, I also think you should not add a number into the draft till it is assigned by the IANA. Now I get the meaning of this block: Value: 2 Description: Raw Public Key Reference: [[THIS RFC]] I was a little bit confused, but this is nice. ;-) Could you also add such a block for the TLS extensions? Value: TBD Extension name: client_certificate_type Reference: [[THIS RFC]] Value: TBD Extension name: server_certificate_type Reference: [[THIS RFC]] Hauke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJR+BVyAAoJEIZ0px9YPRMyp8wP/3cinAWiu+MzBQ8xVsKpEgf4 trcvzih6H1tmD0wuAdOuFhfHV0gzuTMKf5dzANDveiya+63z0jlcEI7Rv68yHxm+ y78n7hroxFJUp8pao4ucN+Q1zBlW9Q+ON02jqJLi7u45fx9PFZ9oi1t0xwyL7pMz fGyTpyrRnUnGp5tYhQqY4LWsakpSXlLYJDBI96N+VmLL3pelONXrz47DYlk2eN5S oMNu0SXuFsTpMqSUS/qQlyP7emVq/1V4G9tJ+sWb8KGEoV1FvURLVS7anbf+Stp7 blgVsZc6sF5Dn0Ud+t1ozjOkr/8NSMKz0aAj3/F6INPu9lbvYpwkibhHqR0CIEq6 gM65205K8PSV+AzlAXMMfTUh6sVw/awRykWq5MZgO6BVrLlX4+E1XFFNGzd3H+BB OheRMfURj3MPoUZ3HwAHaFWNt2jCQ0JV+owXkw/iRzd9sg9jWW+b5GGSWdTJlWgm OC4MZzIO7lYazKs9ML7vFbpYtpZbBj9VhklkgW861OLFYa5ngWlaPr9LXkojwvqF koBYsPSLFHr59LtW9vaVeTK3j60iSSJvT7QlavVFGzwjAlSjxsedMtlHauFAFYsl CV0ri0fCIHEFv2u1ektH+eixsnRTLKepwkO7hkBNAGOfcY7CLsYHUNXE+Pra59yH DY9hk5rfiC1s6U9KiaUT =e0hU -----END PGP SIGNATURE----- From agl@google.com Tue Jul 30 15:09:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B9D11E814F for ; Tue, 30 Jul 2013 15:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJxH4R2TnAM8 for ; Tue, 30 Jul 2013 15:09:17 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id CFDEA11E8125 for ; Tue, 30 Jul 2013 15:09:17 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so12679440obc.26 for ; Tue, 30 Jul 2013 15:09:17 -0700 (PDT) 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=hoNdxfcPXnshvmEDhhUpI3qRcWIUht3ZNMeoMwH9zLA=; b=BWgSJZC+PoZn+MBTWiitdnqFP4pXFPxqvhtpog36P+MBAjb8BAadJjd2b2tOOSB456 kK/lWKNRUo6GU3TOya2r56e+TM+1bFUf6ZXQcFuumt4fAbj0LVTwzBizsK48vBHRk7pt Gd8m3TzoS7ez53XEkc/iH+YPd5Bhc/PzjALuqvQ/K9pSqgR2IQPRml0IbiiyouaMg7sx PDkqVYj1dRX+TjrCEua3M1Xuaogl7ulQIaY73ioaQiSMRxOwGkTBLNpw8AVXTR6Q5AGD touj3Dprcw5BxHfsBQ03qQ0MpkrgSwP7vBmm7SAW5zKC7Mdgxlo8ux7HKfqDnhBHRgZX 6cOQ== X-Google-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:x-gm-message-state; bh=hoNdxfcPXnshvmEDhhUpI3qRcWIUht3ZNMeoMwH9zLA=; b=DSVs531mcOMSflalVvhorkoSJHhb1WcwkIM43ngUhcPPYpXk+tNEQ8alrGi8OM6CJz m50vr75/2ypH5LhdV6mEadyA6fHOt2uQL3eKM2pllKDudVytvBcS1y/N7v2hqJlfIW3V 1gIlkhB1sJm9898vL4gYKT5N7tVCwbobYV7tlnBx5xYCydh/sIxT2nklU8vP+I6MH4Oo XSzKcU320GDx87N2PtlOayibQ2wilqNet5nzYgWxI/b0rm84WVTg7FCnTQBeAgMpmmfc tFQfmcERAzuAXJjeb0AS959EQ5cjdOIIpggVlncM3twBID/NibHYSdOURUX3AsNACS8E TpvQ== X-Received: by 10.182.224.135 with SMTP id rc7mr57666251obc.52.1375222157372; Tue, 30 Jul 2013 15:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Tue, 30 Jul 2013 15:08:57 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Tue, 30 Jul 2013 18:08:57 -0400 Message-ID: To: Geoffrey Keating Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmKpLE/A2n1zMirK5EQNQvtNq32C/yUCDQp4IgAOyw/UvfjK1pRAe0VoDgjNXnUp631p/zQs8EEDbg50o+8GD5+syAkEbZFfemdRbdNCLSgWIVlhG/77IgsFcfyNyjT8pkefdDDi0iVZI2qxA3NuLtNKrAUm9lJynnwmrH8ruY+5I+67dHN2Shebi41GahSj1n3wJq1 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:09:18 -0000 On Tue, Jul 30, 2013 at 2:26 PM, Geoffrey Keating wrote: > Surely if you discover that the remote end appears to support only SSL > 3 but yet somehow supports Salsa, you should stop trying to > communicate because you're under a downgrade attack? Unfortunately there exist middleboxes that prevent > SSLv3 from being used, but which don't interfere with the encrypted traffic itself. Breaking these is costly, and fundamentally ineffective because the users will switch to a client that `works'. Ideally we would be able to support secure connections in the broadest range of situations. Cheers AGL