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.

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.

>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.

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.

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) ?

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.

> =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.

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 =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.

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 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.

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. ]

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 =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.

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.

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.

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?=
div>