From nobody Thu Sep 1 01:49:44 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382412D7B4 for ; Thu, 1 Sep 2016 01:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=newcastle.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTzfmLwnfMNF for ; Thu, 1 Sep 2016 01:49:24 -0700 (PDT) Received: from cheviot12.ncl.ac.uk (cheviot12.ncl.ac.uk [128.240.234.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6E412D888 for ; Thu, 1 Sep 2016 01:49:15 -0700 (PDT) Received: from exhubvm01.ncl.ac.uk ([128.240.234.5] helo=EXHUBVM01.campus.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1bfNgP-0006Gu-BL; Thu, 01 Sep 2016 09:49:13 +0100 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (213.199.154.145) by exhub.ncl.ac.uk (128.240.234.5) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 1 Sep 2016 09:48:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newcastle.onmicrosoft.com; s=selector1-newcastle-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IvpUD0ZIJ1EGpi5QQGm1M3MK9aDJdGZXhQ0Gqj2WRVY=; b=JWLzVpvXkOyuRY1rpHw9jSa68aMWi/YHW9fSGf1bkOZarn95yvmBiwJgX9RxCn5vI3Sz12Qk+ZQVg7WmSm+afwdRnvnn83o5LFyvhYU2Ls1HG2CVYIhS+2y1Rkp9NEk5zAFJeen82iiLI9b0VJdAHKQ8vbMV9DMSNNpVyUzcL5E= Received: from DB5PR0701MB1928.eurprd07.prod.outlook.com (10.167.228.24) by DB5PR0701MB1925.eurprd07.prod.outlook.com (10.167.228.21) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Thu, 1 Sep 2016 08:48:48 +0000 Received: from DB5PR0701MB1928.eurprd07.prod.outlook.com ([10.167.228.24]) by DB5PR0701MB1928.eurprd07.prod.outlook.com ([10.167.228.24]) with mapi id 15.01.0599.010; Thu, 1 Sep 2016 08:48:48 +0000 From: Feng Hao To: Randy Bush , Viktor Dukhovni Thread-Topic: [saag] Whether TOFU should be considered in secure DHCPv6? Thread-Index: AQHSA2zTmRNKQAv5uEC7T8PIIl3Y4qBi8sAAgAAPkACAAMP+gIAAFa0AgAABc4CAAEeFiYAALL7A Date: Thu, 1 Sep 2016 08:48:47 +0000 Message-ID: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=feng.hao@newcastle.ac.uk; x-originating-ip: [128.240.225.103] x-ms-office365-filtering-correlation-id: cc2d68aa-881d-4dd2-702e-08d3d244ca26 x-microsoft-exchange-diagnostics: 1; DB5PR0701MB1925; 6:H0s16L3XNTZ5cGDffKQWskI5RCh08hvh8mufiMWKIGBGjov8Dy/ja0Q8FHcPedme46dguDJg4BQSP+DXvvYY+1cP0X23ytxKUOgs8nfHB/MRTNH7dUyxEgZmQRhGckT/FCdRbnHAU+BaReCl7NqDTJbLKyNDbK5/hvfCq784Qv9U9A+i0w6qP3cfJelvRvUzTr6X5kjR0RBPEeNxvGnZLlgZh5PfT8ho2+2w4WqFbInpyz6v3JdL1M3U3gcQ6Pt7X++yO4GaLRIjUzwJ3Xz5iw6MwBdW9p+BoRKEB3fKm3g=; 5:Fd7+XvXzXsV4Qk62Odf59MPjNsP7PguwtSmxuhXLUi75q9rsblszFchI0R67ImOGi0+5di8kqhycFx/trjbqD3Ld/9V6JtGLyC0HFC+oMCLQKovPqVkc+U7B/yJdHqV5H8k4Wfkhi9Qj94d9NDnyGg==; 24:t9jTxUiVIeWFtTxs5HxZJc41sG2x3eT3Vq1x9gTX+CveOi21uWNQ97Pmthn0h+WjPPPNbnHXkrigMY91hACiNjHckdGrtlNYMXYLw+EoSeI=; 7:qRsCjeSNwhif5BD4KZJ53JdLIiGjN20GQG18OGYVsrDVpuxCVeZEhPKjcr8XSSmaTZIqxS6PzPqXSvH+f0NGlw8m9zAb88HOBk6pfD5vzelLI4cH9tndTM838/4A+AHsfslOa7zQv7wzS8pVyCRvuSatrzMFZr2U2hPyoLMDSn9sO/EU0ICbiGwY96rQ2YdA9ggrAPhC1XrT4QYae7l+fFBdHozrbNymzdVZFiZ1ttp+tKMHVoo638JlFBe8yQY9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0701MB1925; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR0701MB1925; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0701MB1925; x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(15594002)(199003)(189002)(13464003)(102836003)(6116002)(76576001)(33656002)(5660300001)(122556002)(2900100001)(2950100001)(77096005)(15975445007)(74316002)(10400500002)(3660700001)(92566002)(93886004)(586003)(105586002)(19580405001)(7736002)(54356999)(68736007)(5002640100001)(8936002)(7696003)(74482002)(97736004)(7846002)(81166006)(86362001)(189998001)(19580395003)(66066001)(305945005)(11100500001)(5001770100001)(106356001)(50986999)(81156014)(8676002)(9686002)(3846002)(76176999)(101416001)(551544002)(4326007)(2906002)(106116001)(3280700002)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0701MB1925; H:DB5PR0701MB1928.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: newcastle.ac.uk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2016 08:48:47.8916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c5012c9-b616-44c2-a917-66814fbe3e87 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0701MB1925 X-OriginatorOrg: newcastle.ac.uk Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 08:49:35 -0000 Maybe PAKE could be useful here for bootstrapping the initial trust? If no password is used (i.e., empty password), it works essentially the sam= e as TOFU (so backward compatible). In other cases (non-empty password), yo= u get better assurance of security and the authentication is based on the k= nowledge of a secret password. This is arguably more convenient than checki= ng the server key fingerprint (which is long and difficult to remember). Cheers, Feng -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Randy Bush Sent: 01 September 2016 06:59 To: Viktor Dukhovni Cc: Security Area Advisory Group Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? [ moving this back to saag. multiple escalations are too much for me ] > When uses TOFU for SSH to a small set of servers, or to connect to a=20 > small, mostly stable set of networks, it can be a reasonable fit. ssh referrs to this as a "leap of faith," (which n weaver prefers to my gmo= bd) not authentication. users are strongly advised not to go there. otoh, if you get the target host's ssh key fingerprints out of band, you ha= ve whatever level of authenticity the out of band mechanism has. randy _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Thu Sep 1 01:53:51 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B09712D878 for ; Thu, 1 Sep 2016 01:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgY1ixPH0u8F for ; Thu, 1 Sep 2016 01:53:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479D012D888 for ; Thu, 1 Sep 2016 01:53:47 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 21558282FA8 for ; Thu, 1 Sep 2016 08:53:46 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 1 Sep 2016 04:53:53 -0400 Content-Transfer-Encoding: 7bit Message-Id: <710BFA6E-4071-4B16-89B8-7E5ABD86C8AD@dukhovni.org> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> To: saag@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 08:53:49 -0000 > On Sep 1, 2016, at 1:58 AM, Randy Bush wrote: > > ssh referrs to this as a "leap of faith," (which n weaver > prefers to my gmobd) not authentication. users are strongly > advised not to go there. And yet, users do just that, and are better off for it, than using unencrypted telnet. > otoh, if you get the target host's ssh key fingerprints out of > band, you have whatever level of authenticity the out of band > mechanism has. Nobody is claiming that LoF/TOFU opportunistic security is magically immune to attacks on the initial association, or that these scale to a large and/or dynamic set of peers. What is reasonable to claim, is that just as SSH with LoF/TOFU is generally stronger than cleartext telnet, DHCP may LoF/TOFU may likewise benefit users. It seems your objection is opportunistic security generally, rather than its application to DHCP. I am not surprised that this is case, we are acculturated to not accepting less than complete security, and thus often choose to give users nothing because we can't give them everything. A productive path forward in this case would be put the abstract objection aside, and ponder whether TOFU is a reasonable option for users who want some assurance that when they return to a frequently used network, they are not instead unwittingly joining some other hostile network. While Boingo and the like are well positioned to get CA certificates (perhaps even EV certs), it is much less likely to happen with various home networks, ... The question then becomes one of user experience. Specifically, whether TOFU failures due to changing keys are inevitably going to train users to ignore all failures, and thus negate any benefit they might derive from cached keys. If DHCP never carries confidential traffic (so passive eavesdropping is not at issue) and thus might only be useful against active attacks, it is possible that DHCP might not be a good fit for O/S if overly frequent exceptions train users to ignore security warnings... So bottom line, I think that the *applicability* question for O/S to DHCP warrants some thought, beyond reflexive distaste for opportunistic security. Opportunistic security works when it is not intrusive, and raises few false alarms. It fails when it routinely gets in the way and is of low value to the user. -- Viktor. From nobody Thu Sep 1 06:59:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0B812D977 for ; Thu, 1 Sep 2016 06:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiCkxWinfEKn for ; Thu, 1 Sep 2016 06:59:32 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CDB12D986 for ; Thu, 1 Sep 2016 06:42:32 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id t7so85039311qkh.1 for ; Thu, 01 Sep 2016 06:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wQgcQcyRvj0DRDV1OaGnHcsT+GbnRXNrEXDr8/e/pBg=; b=uvqVVR+nsLCpOfD9tqBhgwCsnGbIXO42uIywl47BHlUi4TP+oAmRou7jA3Sfrmh1S/ fxrgEkxiBdk56pjpQqlvthveELulp7SZuM74D6IxFMzxbkVgPeArR+wa1qRC5wj2thXW HqA9JG8KoTU7NXSvI0CusyKWeJ17eEYx/oN0hGyE5YJX3htlcfeonwB05e5YWaUivLbt /vdiqVo7cWn6EyH6wbmsUntIvQ0a02k4BMp0JKQjF1AkUiBj2eikMe2/CkdsShECAkOW Ld5T1RmAO15j1ni5eUrNQSmZtZ6XG/i9eMbC7ePsh3rCVJSdyxua0OSBzWXBxWghA48P 0Taw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wQgcQcyRvj0DRDV1OaGnHcsT+GbnRXNrEXDr8/e/pBg=; b=XXmgC85lYBNba91/mWNPaT/gGXhkv+W74L3YQbzfGKyz3NSFYiKUqE2ztZlAiuIbN+ XexEsy65nejKjM+kTN+NlKLXI+wyLMpFASPDvzmnoliM4vUJMCi0iYAK4WMt+pusyomu 5LBVib1RThLXdnNU+/poARYLG6K2iQiAb71dE1jDWOdt28zqqmbnKelYxr9C9hlrevkR Pnfnto02YhkxRsK8cAWoWN0HzbvZ0aHAx32u4WTl5f7TneJXmsy7M7Gg2YOMJnXMBVzb Q/ZSD0oT1mneZKchoAl2KiPpNmXGoGd6YdR5O8fJ+umgB4801hE8MQ6bUK0Yp5+UmjTa chfA== X-Gm-Message-State: AE9vXwO9Tnz70A4JZStqUBECfUUqk7qjHyZWRUR5QBFAxZYLp2PHMDPxWULSwN+iNQhVHD8OPK+kij8Z2rsNwA== X-Received: by 10.55.52.134 with SMTP id b128mr18615017qka.284.1472737351637; Thu, 01 Sep 2016 06:42:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.44.111 with HTTP; Thu, 1 Sep 2016 06:42:31 -0700 (PDT) In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> From: Lishan Li Date: Thu, 1 Sep 2016 21:42:31 +0800 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a11497e8cb12089053b72623c Archived-At: Cc: Ted Lemon , JINMEI Tatuya , Security Area Advisory Group Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 13:59:35 -0000 --001a11497e8cb12089053b72623c Content-Type: text/plain; charset=UTF-8 Dear Randy, Sure, Tofu is not as good as one might desire. However, currenly, there is no anything else which is more likely to be deployed. This issue has troubled the draft for one year. And DHC WG needs some work for DHCP security and want this work move forward as soon as possible. So, I think that we should now focus on specifying something than can be deployed easily, such as tofu. If we find something elas which is better than tofu in the future, we can specify a new work to state it. What do you think of it? Thanks a lot for your continuous help and guidance. Best Regards, Lishan 2016-09-01 13:58 GMT+08:00 Randy Bush : > [ moving this back to saag. multiple escalations are too much > for me ] > > > When uses TOFU for SSH to a small set of servers, or to connect > > to a small, mostly stable set of networks, it can be a reasonable > > fit. > > ssh referrs to this as a "leap of faith," (which n weaver > prefers to my gmobd) not authentication. users are strongly > advised not to go there. > > otoh, if you get the target host's ssh key fingerprints out of > band, you have whatever level of authenticity the out of band > mechanism has. > > randy > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11497e8cb12089053b72623c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Randy,

Sure, Tofu is no= t as good as one might desire. However, currenly, there is no=C2=A0
anything else which is more likely to be deployed. This issue has troubl= ed the=C2=A0
draft for one year. And DHC WG needs some work for D= HCP security and want this=C2=A0
work move forward as soon as pos= sible.

So, I think that we should now focus on spe= cifying something than can be deployed=C2=A0
easily, such as tofu= . If we find something elas which is better than tofu in the=C2=A0
future, we can specify a new work to state it.

W= hat do you think of it? Thanks a lot for your continuous help and guidance.=


Best Regards,
Lishan

2016-09-0= 1 13:58 GMT+08:00 Randy Bush <randy@psg.com>:
[ moving this back to saag.=C2=A0 multiple escalations are = too much
=C2=A0 for me ]

> When uses TOFU for SSH to a small set of servers, or to connect
> to a small, mostly stable set of networks, it can be a reasonable
> fit.

ssh referrs to this as a "leap of faith," (which n weaver
prefers to my gmobd) not authentication.=C2=A0 users are strongly
advised not to go there.

otoh, if you get the target host's ssh key fingerprints out of
band, you have whatever level of authenticity the out of band
mechanism has.

randy

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

--001a11497e8cb12089053b72623c-- From nobody Thu Sep 1 07:09:43 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9CE12D972 for ; Thu, 1 Sep 2016 07:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OICmcjKtNZk7 for ; Thu, 1 Sep 2016 07:09:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2367A12B071 for ; Thu, 1 Sep 2016 06:58:43 -0700 (PDT) Received: from mbp-2.local ([IPv6:2601:1c0:cb00:5d1a:bdb9:d846:2f3d:a4bd]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u81DwdEN081019 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 1 Sep 2016 13:58:39 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:1c0:cb00:5d1a:bdb9:d846:2f3d:a4bd] claimed to be mbp-2.local To: Viktor Dukhovni , saag@ietf.org References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> <710BFA6E-4071-4B16-89B8-7E5ABD86C8AD@dukhovni.org> From: joel jaeggli Message-ID: <3ab9fe5f-22c3-cc86-180f-6ca4845ec083@bogus.com> Date: Thu, 1 Sep 2016 06:58:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <710BFA6E-4071-4B16-89B8-7E5ABD86C8AD@dukhovni.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mejaPcAOugnEt8XXHHBlblpiLuVqWbjqa" Archived-At: Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 14:09:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mejaPcAOugnEt8XXHHBlblpiLuVqWbjqa Content-Type: multipart/mixed; boundary="bLfITK8k6Rx1uMCcnHcJWpS7gCngf3hgq"; protected-headers="v1" From: joel jaeggli To: Viktor Dukhovni , saag@ietf.org Message-ID: <3ab9fe5f-22c3-cc86-180f-6ca4845ec083@bogus.com> Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> <710BFA6E-4071-4B16-89B8-7E5ABD86C8AD@dukhovni.org> In-Reply-To: <710BFA6E-4071-4B16-89B8-7E5ABD86C8AD@dukhovni.org> --bLfITK8k6Rx1uMCcnHcJWpS7gCngf3hgq Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/1/16 1:53 AM, Viktor Dukhovni wrote: >> On Sep 1, 2016, at 1:58 AM, Randy Bush wrote: >> >> ssh referrs to this as a "leap of faith," (which n weaver >> prefers to my gmobd) not authentication. users are strongly >> advised not to go there. > And yet, users do just that, and are better off for it, than > using unencrypted telnet. > >> otoh, if you get the target host's ssh key fingerprints out of >> band, you have whatever level of authenticity the out of band >> mechanism has. > Nobody is claiming that LoF/TOFU opportunistic security is > magically immune to attacks on the initial association, or > that these scale to a large and/or dynamic set of peers. > > What is reasonable to claim, is that just as SSH with > LoF/TOFU is generally stronger than cleartext telnet, > DHCP may LoF/TOFU may likewise benefit users. > > It seems your objection is opportunistic security generally, > rather than its application to DHCP. I am not surprised > that this is case, we are acculturated to not accepting > less than complete security, and thus often choose to give > users nothing because we can't give them everything. > > A productive path forward in this case would be put the > abstract objection aside, and ponder whether TOFU is > a reasonable option for users who want some assurance > that when they return to a frequently used network, they > are not instead unwittingly joining some other hostile > network. > > While Boingo and the like are well positioned to get > CA certificates (perhaps even EV certs), it is much less > likely to happen with various home networks, ... > > The question then becomes one of user experience. > Specifically, whether TOFU failures due to changing keys > are inevitably going to train users to ignore all failures, > and thus negate any benefit they might derive from cached > keys. If changing keys occurs with any frequency you're going to be beset by a lot more notifications that are not associated with bad actors then those that are. What is one's alternative to clicking through such a warning and proceeding? > > If DHCP never carries confidential traffic (so passive > eavesdropping is not at issue) and thus might only > be useful against active attacks, it is possible that > DHCP might not be a good fit for O/S if overly frequent > exceptions train users to ignore security warnings... > > So bottom line, I think that the *applicability* > question for O/S to DHCP warrants some thought, > beyond reflexive distaste for opportunistic security. > > Opportunistic security works when it is not intrusive, and > raises few false alarms. It fails when it routinely gets > in the way and is of low value to the user. > --bLfITK8k6Rx1uMCcnHcJWpS7gCngf3hgq-- --mejaPcAOugnEt8XXHHBlblpiLuVqWbjqa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlfINA8ACgkQ8AA1q7Z/VrLE4ACfbDeywhzC0nZ9p+OTITdsi9dy 7l8An3KQ3iTcoXfWyExkBbz9q2kwlkUL =dmbM -----END PGP SIGNATURE----- --mejaPcAOugnEt8XXHHBlblpiLuVqWbjqa-- From Ted.Lemon@nominum.com Thu Sep 1 10:06:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7371B12DABE for ; Thu, 1 Sep 2016 10:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IC_W-C8LgWd for ; Thu, 1 Sep 2016 10:06:34 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F021612D977 for ; Thu, 1 Sep 2016 10:06:33 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 1C0AC74077F; Thu, 1 Sep 2016 17:06:33 +0000 (UTC) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.235.68]) by CAS-04.WIN.NOMINUM.COM ([64.89.235.67]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 10:06:32 -0700 From: Ted Lemon To: "Salz, Rich" , Lishan Li , "Randy Bush" Thread-Topic: [saag] Whether TOFU should be considered in secure DHCPv6? Thread-Index: AQHSA4SXJADjYG9860yMZUWBHTxqvKBj289OgAB2yICAAAShgIAAAkGAgACFPJU= Date: Thu, 1 Sep 2016 17:06:32 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307A11F3CA6@mbx-01.win.nominum.com> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.66.83.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: JINMEI Tatuya , "saag@ietf.org" Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 17:25:07 -0000 You don't. All you know is "this is the same server that worked last time= ." The question is, in the case of DHCP, is that a useful piece of data? = I think it is; I'm certainly interested in hearing arguments that it is n= ot. E.g., does using that information make us _more_ vulnerable in some w= ay we haven't thought of? Does it not _really_ make us less vulnerable? = It would be helpful if these questions could be addressed. ________________________________________ From: Salz, Rich [rsalz@akamai.com] Sent: Wednesday, August 31, 2016 22:07 To: Lishan Li; Randy Bush Cc: JINMEI Tatuya; saag@ietf.org; Ted Lemon Subject: RE: [saag] Whether TOFU should be considered in secure DHCPv6? > In my initial thought, tofu is one method to achieve authentication. Look= ing forward to your further guidance.- Authentication is: you connect to something, and verify that the identity = it gives you is the one you expect. For example, the DNS name in a certifi= cate, when properly presented by a web server, allows you to authenticate t= hat server. In TOFU, how are you verifying the identity of the server? For example, wit= h SSH, unless you have out-of-band verification of the server's SSH key, yo= u have no idea if the server you are connected to is the one you want to co= nnect to. TOFU gives you "well if you come back here, you're coming back to the same= entity you first came to." But how do I know that it's really Randy Bush'= s server, and not his evil twin Randy Shrub? -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Sep 1 10:27:21 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9886112D1B9 for ; Thu, 1 Sep 2016 10:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkl6_NCAxidU for ; Thu, 1 Sep 2016 10:27:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B8312D19F for ; Thu, 1 Sep 2016 10:27:17 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 047B7282FA8 for ; Thu, 1 Sep 2016 17:27:16 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <3ab9fe5f-22c3-cc86-180f-6ca4845ec083@bogus.com> Date: Thu, 1 Sep 2016 13:27:24 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9C494AA2-73FF-40B7-B2DE-3C111DA218AC@dukhovni.org> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> <710BFA6E-4071-4B16-89B8-7E5ABD86C8AD@dukhovni.org> <3ab9fe5f-22c3-cc86-180f-6ca4845ec083@bogus.com> To: saag@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 17:27:19 -0000 > On Sep 1, 2016, at 9:58 AM, joel jaeggli wrote: > >> The question then becomes one of user experience. >> Specifically, whether TOFU failures due to changing keys >> are inevitably going to train users to ignore all failures, >> and thus negate any benefit they might derive from cached >> keys. > > If changing keys occurs with any frequency you're going to be beset by a > lot more notifications that are not associated with bad actors then > those that are. What is one's alternative to clicking through such a > warning and proceeding? This, finally, is the essential question! One might only enable key pinning for a few selected networks, where one reasonably either long-term key stability or some way of knowing that the key is scheduled to change. The specification might recommend that DHCP clients not do key pinning by default, and only do so when the user asks for it, and has been suitably warned to not use the feature indiscriminately. One might also design-in a mechanism for signed key rotation, along the lines of the TACK proposal, and thereby further reduce the chance of false alarms, because the few networks the user does visit frequently and verify will be able to transparently roll-over their authentication keys. If one gets this wrong, the feature might not be better than nothing, and might just give security a bad name. -- Viktor. From nobody Thu Sep 1 11:09:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB412D556 for ; Thu, 1 Sep 2016 11:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ2dgZKiYM6I for ; Thu, 1 Sep 2016 11:09:13 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5A212D1A5 for ; Thu, 1 Sep 2016 11:09:13 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 95ADD423723; Thu, 1 Sep 2016 18:09:12 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 73EEA42371F; Thu, 1 Sep 2016 18:09:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472753352; bh=zurF9Ehn2m/qAb97HtfLjZTXWOVrTiHmisfTocBZtg8=; l=2230; h=From:To:CC:Date:References:In-Reply-To:From; b=Y7oDmb8mIj/fYLr99e8OsTn5NXFP3uG5b2D5cp71Ouj6dDR+6qTgRqPTXa1qWi00r MKKFj5R0BqtTcMmHAsSUika+kEEuFRaKrjLHIr3wEtajE21mO5D18dkbi7YEQ5UP5i bhdpGiRSV3wTGCL3kj9aQQhL3Yj7rYRRJTZmG5jU= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 700DD1FC88; Thu, 1 Sep 2016 18:09:12 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 14:09:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 14:09:12 -0400 From: "Salz, Rich" To: Ted Lemon , Lishan Li , "Randy Bush" Thread-Topic: [saag] Whether TOFU should be considered in secure DHCPv6? Thread-Index: AQHSA2zEfGNkYV+700e+5Ux4m5UU8qBjNc4AgAAPkACAAMP+gIAAFa4AgAABcoCAAAShgP//vjIwgAE/RQD//8wzwA== Date: Thu, 1 Sep 2016 18:09:11 +0000 Message-ID: <8801f0999ffe4fe693ae2904d87161eb@usma1ex-dag1mb1.msg.corp.akamai.com> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> , <8D23D4052ABE7A4490E77B1A012B6307A11F3CA6@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307A11F3CA6@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.142] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: JINMEI Tatuya , "saag@ietf.org" Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:09:15 -0000 > You don't. All you know is "this is the same server that worked last ti= me." > The question is, in the case of DHCP, is that a useful piece of data? I= think it > is; I'm certainly interested in hearing arguments that it is not. E.g.,= does > using that information make us _more_ vulnerable in some way we haven't > thought of? Does it not _really_ make us less vulnerable? It would be > helpful if these questions could be addressed. I agree that knowing "this is the same server as last time" is useful. Mor= e importantly, knowing "this is not the same server as last time" is perhap= s more useful (evil coffee shop scenario). Is it an improvement? I think so, but perhaps it's a "two steps forward, on= e step back" kind of thing. On the other hand, an enterprise being able to= configure it's DHCP server in the workstations it gives out is a nice hook= to have. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz > ________________________________________ > From: Salz, Rich [rsalz@akamai.com] > Sent: Wednesday, August 31, 2016 22:07 > To: Lishan Li; Randy Bush > Cc: JINMEI Tatuya; saag@ietf.org; Ted Lemon > Subject: RE: [saag] Whether TOFU should be considered in secure DHCPv6? >=20 > > In my initial thought, tofu is one method to achieve authentication. Lo= oking > forward to your further guidance.- >=20 > Authentication is: you connect to something, and verify that the identit= y it > gives you is the one you expect. For example, the DNS name in a certific= ate, > when properly presented by a web server, allows you to authenticate that > server. >=20 > In TOFU, how are you verifying the identity of the server? For example, w= ith > SSH, unless you have out-of-band verification of the server's SSH key, yo= u > have no idea if the server you are connected to is the one you want to > connect to. >=20 > TOFU gives you "well if you come back here, you're coming back to the sa= me > entity you first came to." But how do I know that it's really Randy Bush= 's > server, and not his evil twin Randy Shrub? >=20 > -- > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz >=20 From nobody Thu Sep 1 11:15:52 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D912D108 for ; Thu, 1 Sep 2016 11:15:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8i3oAFB7zUG for ; Thu, 1 Sep 2016 11:15:49 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D588A12D0CE for ; Thu, 1 Sep 2016 11:15:48 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id e198so33232616lfb.2 for ; Thu, 01 Sep 2016 11:15:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=cNJP3s8SD01zUwUGoYS18o8z97qktvFsu/s2Ye3NfH8=; b=Rvq7XrIhVJVpxnwLHiswGRTSUor/G5DmD1hyDrZtoANyREdFO0HScmO8EVwMcUaa7d GuhpBG9kW1RXAomauTuaP4wbMxVLXkzlwM+zRW5nv5r+FXwfZw3l57/2JobEmeBz6wNE ZwJXneM7Dsn4960nb2I8bBtXxoEmqprTPfQ+fo3Owst81i2s/obKnexB76aYYtbP8wjk 3wi7wFWfVcJt8bM5CTh8z19d1+XzA413wQ3EeMeJgryYrfvMEHoGDNifgB2E22wJX+f2 uwdLjmvF8vfqYMkd1FQomNL4b/H9Y7+vNyaZojSSl3b1fOA1ZUSHuy9JeEXDQ06PMYvM eyAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cNJP3s8SD01zUwUGoYS18o8z97qktvFsu/s2Ye3NfH8=; b=JUC02Kt+j9btUWo/RrJgLkJHjCbcox/9TEQR1EZtw8XY/TM8JMYhxoAk+qoZFQXC/H fBGL+SX1452HXNkh8L2rK6Id8UdGfbdeNdapRsjw+4uLoc5G3bYSe4r3J8/nsqp/miSG ryyFtVmaq5KZ52H8vPNNbU4PtRCOjLeMUPW6S1rHMm1HWIHqNG3sDX9tMxBtbgNQV+3Y HNNf31tAVez5L4A9XSOzjH55XPd8o6RcUYHejbWjHgshyReY3kREtb396RJsUYOJqbck bp9sBRcxvQAJYvurt3ot2bRqnldTIvHy2vF9e+qwjwjfFGnzFQ2xJ+qMkpKphuGAOjxJ Qf2Q== X-Gm-Message-State: AE9vXwOGAy5KVEFE0dwXcYp6DlztBexiu8BiwuMhOhtjgAL4I/r73dm50xBStcAMsl2c5ensziGndfppSB8bCg== X-Received: by 10.25.218.75 with SMTP id r72mr4781391lfg.131.1472753746692; Thu, 01 Sep 2016 11:15:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 11:15:06 -0700 (PDT) From: Ted Lemon Date: Thu, 1 Sep 2016 14:15:06 -0400 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary=001a11401f36e9eab6053b763342 Archived-At: Subject: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:15:51 -0000 --001a11401f36e9eab6053b763342 Content-Type: text/plain; charset=UTF-8 I just reviewed the thread, and noticed that there hasn't actually been an explanation of how this is supposed to be useful. For those who are not intimately familiar with DHCP, here is how it works: - a client notices that it has joined a link - the client sends a solicit message - zero or more DHCP servers respond within a certain window (1s, by default). - the client picks one of these responses based on various criteria, or if it has no basis for preferring one, at random, or possibly just the first or last one that arrived. The details of this selection process are not specified in RFC 3315. - the client is now wedded to that DHCP server until it moves to a new link or the server goes away When a client connects to a link, either it will be a link the client has previously connected to, or not. If it is a link to which the client had previously connected, there may be a rogue DHCP server on the link that wasn't present last time the client connected. ToFU, with no user confirmation, blocks the rogue DHCP server from being chosen by the client, assuming that the previously used server is still present. When a client connects to a link to which it has never previously connected, it will pick a DHCP server. This DHCP server may or may not be a rogue DHCP server. If it is a rogue DHCP server, the client is potentially screwed, and the end user will potentially notice this, depending on what sort of attach the rogue server is attempting. The user can detect this and say "don't use this server anymore." If the client is connecting to a Boingo hotspot, Boingo can (a) filter out rogue DHCP packets and (b) sign the key it uses using a PKI cert chain that can be validated. The client can be configured to prefer keys signed by that entity. This can also be done for enterprise clients. There's no reason why this has to be difficult, and we can use the PKI infrastructure to make it work, or we can use DANE, in theory. So the ToFU use case is for connecting to a network speculatively. In this case, the worst case scenario if you don't have ToFU is that you wind up talking to a rogue DHCP server that is able to get information out of you by faking your configuration. What ToFU does is make it a lot harder for the rogue server to do this: it has to be the first server you talk to on that link. I don't think there's any point in re-keying in a typical case, and I don't think there's any point in interacting with the user in a typical case. There should not be security pop-ups. If the network isn't working, the user will stop using it; that's the UX we want. So this is why I think ToFU adds value. Does that make sense, or am I missing something? --001a11401f36e9eab6053b763342 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just reviewed the thread, and noticed that there hasn= 9;t actually been an explanation of how this is supposed to be useful.
=
For those who are not intimately familiar with DHCP, here is= how it works:
  • a client notices that it has joined a link
    • <= li>the client sends a solicit message
  • zero or more DHCP servers res= pond within a certain window (1s, by default).
  • the client picks one= of these responses based on various criteria, or if it has no basis for pr= eferring one, at random, or possibly just the first or last one that arrive= d. =C2=A0 The details of this selection process are not specified in RFC 33= 15.
  • the client is now wedded to that DHCP server until it moves to = a new link or the server goes away
When a client connects to = a link, either it will be a link the client has previously connected to, or= not. =C2=A0 If it is a link to which the client had previously connected, = there may be a rogue DHCP server on the link that wasn't present last t= ime the client connected. =C2=A0 ToFU, with no user confirmation, blocks th= e rogue DHCP server from being chosen by the client, assuming that the prev= iously used server is still present.

When a = client connects to a link to which it has never previously connected, it wi= ll pick a DHCP server. =C2=A0 This DHCP server may or may not be a rogue DH= CP server. =C2=A0 If it is a rogue DHCP server, the client is potentially s= crewed, and the end user will potentially notice this, depending on what so= rt of attach the rogue server is attempting. =C2=A0 The user can detect thi= s and say "don't use this server anymore."
If the client is connecting to a Boingo hotspot, Boingo can (a= ) filter out rogue DHCP packets and (b) sign the key it uses using a PKI ce= rt chain that can be validated. =C2=A0 The client can be configured to pref= er keys signed by that entity. =C2=A0 This can also be done for enterprise = clients. =C2=A0 There's no reason why this has to be difficult, and we = can use the PKI infrastructure to make it work, or we can use DANE, in theo= ry.

So the ToFU use case is for connecting to a ne= twork speculatively. =C2=A0 In this case, the worst case scenario if you do= n't have ToFU is that you wind up talking to a rogue DHCP server that i= s able to get information out of you by faking your configuration. =C2=A0 W= hat ToFU does is make it a lot harder for the rogue server to do this: it h= as to be the first server you talk to on that link.

I don't think there's any point in re-keying in a typical case, a= nd I don't think there's any point in interacting with the user in = a typical case. =C2=A0 There should not be security pop-ups. =C2=A0 If the = network isn't working, the user will stop using it; that's the UX w= e want.

So this is why I think ToFU adds value. = =C2=A0 Does that make sense, or am I missing something?
--001a11401f36e9eab6053b763342-- From nobody Thu Sep 1 11:44:08 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4231E12D5AF for ; Thu, 1 Sep 2016 11:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0s2Tn5ZbeHO for ; Thu, 1 Sep 2016 11:44:06 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B701C12D5C3 for ; Thu, 1 Sep 2016 11:44:05 -0700 (PDT) Received: from [128.9.184.40] ([128.9.184.40]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u81IhQxk018515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Sep 2016 11:43:26 -0700 (PDT) To: Ted Lemon , saag@ietf.org References: From: Joe Touch Message-ID: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> Date: Thu, 1 Sep 2016 11:43:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u81IhQxk018515 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:44:07 -0000 Hi, Ted, On 9/1/2016 11:15 AM, Ted Lemon wrote: > So this is why I think ToFU adds value. Does that make sense, or am > I missing something? Wouldn't this also then ensure that you're locked-in to a spoofer? I.e., it seems like there needs to be a way for users to "reset" things if needed. Joe From nobody Thu Sep 1 11:49:21 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5156E12D5F4 for ; Thu, 1 Sep 2016 11:49:20 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRAoNVeMUjAB for ; Thu, 1 Sep 2016 11:49:18 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6641512D5E8 for ; Thu, 1 Sep 2016 11:49:18 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id g62so67420007lfe.3 for ; Thu, 01 Sep 2016 11:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nWSvkU7YnSv/T26rloQJQ6FLmP+IRreeUBJiF2eWcko=; b=xE+uZH5VglusTarFCUsrPZPUOK/TXgWUYxqI/owRTHAdzNWmEofDUNmd6VYecfiLUq H4os6Rt3UaZLYI3NmXm+UQRyf3apbwJoVusnCZ2il5V8wTWoI7pxRD1tjNoiH8aiExJg MIN7P5RA34jQPHvVjy4fz6AXfLtKanpBKGLMjeol3xpW5gpQtZEsIZS0salg73zSqkQe w72nh57i17Q75LuWICz4+fNh/XW0ReizqTOwY+IOAQoc5gqCrLxw/0CSC9imq+jRB4ZC s8gZFuqoSXoxN2BznvWRD9O8fkKNcDElt12nJO29M1YN/SxoxZxnRvzdxq3QaRFvNP3n tzjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nWSvkU7YnSv/T26rloQJQ6FLmP+IRreeUBJiF2eWcko=; b=aRN3Ah1x3IseRDTFbtXHR/gTxL1HaDCKLJklaqTYRjSV3mEWlxm9zNVHFZ0iY67mkd oJoQNOz4ykREqKRvFUiu1mNVU87+VRKNEAkWD14onkroft5bS+aiMY+ehJahupin/slf wcrdy7NsFZSv3QEh2/FLxdRexz6a7j9qXEUrfqYz34zQ8/BlQ73quyxmvNNP9QxjEYf2 Bo8oCRfxVNeBplFGIasDC2gV/LPH703mlws6+dlbzdrM6Z5Y/Ov6Cz43KYXYfDW1nR1t 0atWcuWgv+jzzDkPsV063TFhCvKoEUVTNMJYcFq/o43fEbcw73suL8LZxdjy0wwSdwff iO1w== X-Gm-Message-State: AE9vXwMgKSf/eu1RnrSjis6uIehvhf3s0SCAfKQGoEWrXN5TLfLJJK4fZGNMaaJQdwrxEWdIQNPwP2u5Zdt1xQ== X-Received: by 10.25.201.69 with SMTP id z66mr4768577lff.226.1472755756469; Thu, 01 Sep 2016 11:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 11:48:35 -0700 (PDT) In-Reply-To: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Ted Lemon Date: Thu, 1 Sep 2016 14:48:35 -0400 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a114b246eb4bca0053b76abe6 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:49:20 -0000 --001a114b246eb4bca0053b76abe6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I think you are right. This is the "one step back" to which Rich was referring--he responded privately. I have copied my answer, because I think it's worth exploring this carefully, and I'm curious to hear your answer as well as Rich's: If the "wrong" server is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to connect to a different network, or complain, and somebody with network fu will help you. I think this is better than popping up security warnings, although I could be convinced otherwise. A "try to fix my network" button could help as well--if someone is pressing it, maybe the server the client bonded to sucks. Heuristics for detecting filtered connections could also work. Bear in mind that a rogue server that's present on the wire and presenting a cert at time T, but is not present at time T+100, will not prevent the client that bonded to the rogue at time T from getting configured by another server at time T+100. It's only if the rogue _and_ the other server are present that the client will prefer the rogue. An additional heuristic here might be to always prefer the server to which we most recently bonded when there is a choice; this would favor the incumbent server over the intermittent rogue. But ultimately there is no perfect solution; the question is, is this better than not using ToFU? =E2=80=8B --001a114b246eb4bca0053b76abe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I think you are right. =C2=A0 This is the "one s= tep back" to which Rich was referring--he responded privately. =C2=A0 = I have copied my answer, because I think it's worth exploring this care= fully, and I'm curious to hear your answer as well as Rich's:
<= br>
If the "wrong" ser= ver is giving you a working connection, you're no worse off than you we= re without ToFU; if it's not, then you're presumably going to conne= ct to a different network, or complain, and somebody with network fu will h= elp you. =C2=A0 I think this is better than popping up security warnings, a= lthough I could be convinced otherwise. =C2=A0 A "try to fix my networ= k" button could help as well--if someone is pressing it, maybe the ser= ver the client bonded to sucks. =C2=A0 Heuristics for detecting filtered co= nnections could also work.

=
Bear in mind that a rogue server that's= present on the wire and presenting a cert at time T, but is not present at= time T+100, will not prevent the client that bonded to the rogue at time T= from getting configured by another server at time T+100. =C2=A0 It's o= nly if the rogue _and_ the other server are present that the client will pr= efer the rogue.

An additional heuristic here might be to always prefe= r the server to which we most recently bonded when there is a choice; this = would favor the incumbent server over the intermittent rogue.

But ultim= ately there is no perfect solution; the question is, is this better than no= t using ToFU?
=E2=80=8B
--001a114b246eb4bca0053b76abe6-- From nobody Thu Sep 1 11:52:32 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C72112D642 for ; Thu, 1 Sep 2016 11:52:31 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M62fM5FI_T4z for ; Thu, 1 Sep 2016 11:52:29 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDBF12D62A for ; Thu, 1 Sep 2016 11:52:27 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id p41so49031949lfi.1 for ; Thu, 01 Sep 2016 11:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+XGWyE6UiX8CTUAQa7TI20R5DpYfVC1pvRuawldRYEo=; b=eAILWgSA1dzHkrMEQgZngsCxALWyonJcgzV09uHCBWcxq+Z02E0lXtVZygoip10dnQ 2geX9fnE6YuWCWf/5HJdv0JEpvYenrYAsx05M8s1WagbzKjHWbPHi+oFWRIDY9iAb/Ju 40q5KAisVOKXXim6yE2ZFZN238rYH3SO+Okm6ro2wyMos6vr7nlPVM7n/CnYk1g3spzB PPU1q9ityeBolRrsNWJpX2kS4XhnGOJ0L6Rbwpx+52n/pPs8LxDjbP2iWLfv2AeD5ds1 oqtBYuYneBkuy6nbeee5esA9R0WCtEbDrPNQp/xxHQzZMi57rTJTIUYVnpHGshnf8+ow yQoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+XGWyE6UiX8CTUAQa7TI20R5DpYfVC1pvRuawldRYEo=; b=LQH6QoRaoiUqOdQc7Tzy2XzICZITqn0OSqrn9gtQzqYvJnZPtT69KuNiA4b59WuQF0 HRTiMccUxRAPkYW3K86sUskH9filaJmVR7l1D6P5E0OIv+/XDO8wI6YR85Du1CHvfOBB rsOFgzCx2m306pWORweZSgWCTBW3OWduIioI2s9H0AcEm6zBGSkplpA/eVLyCMIxKavQ kerw7VoG05DiR2X+aztdaljk0toyhGnBfPW0+4FZ/tOycPqm/klPD1Tqrc0S/c4NQdiF GEfle1sEofgeVxbmQ91HMj9RLbISUQNYzm/xMEeqnAJXe4Hjd9Jm3BNOEdD8W9QiAKs4 6NHw== X-Gm-Message-State: AE9vXwPBndB86NfSdybSQOGbgEtn+frG1nfBGGYNn6Ja00hIgo1qaPHtct4vnGDpPYnfki/zTJhxYT7pk/J1jA== X-Received: by 10.25.201.69 with SMTP id z66mr4771501lff.226.1472755945617; Thu, 01 Sep 2016 11:52:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 11:51:44 -0700 (PDT) In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Ted Lemon Date: Thu, 1 Sep 2016 14:51:44 -0400 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a114b246efac1f5053b76b6f1 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 18:52:31 -0000 --001a114b246efac1f5053b76b6f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Another thing to say, which I think is why we don't hear about this much, is that most network infrastructure equipment lets you filter DHCP server messages from leaf links that aren't authorized to have a DHCP server attached to them. So you can argue that this is massive overkill because really we won't need this solution anyway. I think that's why Randy felt it was worth not bothering with ToFU. However, I think ToFU potentially works well on home networks, where the network operator doesn't have enough network fu to know how to filter DHCP, but where we can assume a stable incumbent DHCP server with a stable key. On Thu, Sep 1, 2016 at 2:48 PM, Ted Lemon wrote: > Yes, I think you are right. This is the "one step back" to which Rich > was referring--he responded privately. I have copied my answer, because= I > think it's worth exploring this carefully, and I'm curious to hear your > answer as well as Rich's: > > If the "wrong" server is giving you a working connection, you're no worse > off than you were without ToFU; if it's not, then you're presumably going > to connect to a different network, or complain, and somebody with network > fu will help you. I think this is better than popping up security > warnings, although I could be convinced otherwise. A "try to fix my > network" button could help as well--if someone is pressing it, maybe the > server the client bonded to sucks. Heuristics for detecting filtered > connections could also work. > > Bear in mind that a rogue server that's present on the wire and presentin= g > a cert at time T, but is not present at time T+100, will not prevent the > client that bonded to the rogue at time T from getting configured by > another server at time T+100. It's only if the rogue _and_ the other > server are present that the client will prefer the rogue. > > An additional heuristic here might be to always prefer the server to whic= h > we most recently bonded when there is a choice; this would favor the > incumbent server over the intermittent rogue. > > But ultimately there is no perfect solution; the question is, is this > better than not using ToFU? > =E2=80=8B > --001a114b246efac1f5053b76b6f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Another thing to say, which I think is why we don't he= ar about this much, is that most network infrastructure equipment lets you = filter DHCP server messages from leaf links that aren't authorized to h= ave a DHCP server attached to them. =C2=A0 So you can argue that this is ma= ssive overkill because really we won't need this solution anyway. =C2= =A0 I think that's why Randy felt it was worth not bothering with ToFU.= =C2=A0 However, I think ToFU potentially works well on home networks, wher= e the network operator doesn't have enough network fu to know how to fi= lter DHCP, but where we can assume a stable incumbent DHCP server with a st= able key.

On= Thu, Sep 1, 2016 at 2:48 PM, Ted Lemon <mellon@fugue.com> wr= ote:
Yes, I think you ar= e right. =C2=A0 This is the "one step back" to which Rich was ref= erring--he responded privately. =C2=A0 I have copied my answer, because I t= hink it's worth exploring this carefully, and I'm curious to hear y= our answer as well as Rich's:

If the "wrong" server is giving you a working connecti= on, you're no worse off than you were without ToFU; if it's not, th= en you're presumably going to connect to a different network, or compla= in, and somebody with network fu will help you. =C2=A0 I think this is bett= er than popping up security warnings, although I could be convinced otherwi= se. =C2=A0 A "try to fix my network" button could help as well--i= f someone is pressing it, maybe the server the client bonded to sucks. =C2= =A0 Heuristics for detecting filtered connections could also work.
Bea= r in mind that a rogue server that's present on the wire and presenting= a cert at time T, but is not present at time T+100, will not prevent the c= lient that bonded to the rogue at time T from getting configured by another= server at time T+100. =C2=A0 It's only if the rogue _and_ the other se= rver are present that the client will prefer the rogue.

An additional h= euristic here might be to always prefer the server to which we most recentl= y bonded when there is a choice; this would favor the incumbent server over= the intermittent rogue.

But ultimately there is no perfect solution; t= he question is, is this better than not using ToFU?
=E2=80=8B

--001a114b246efac1f5053b76b6f1-- From nobody Thu Sep 1 13:44:30 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE412D74A for ; Thu, 1 Sep 2016 13:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQXD9uBydiqA for ; Thu, 1 Sep 2016 13:44:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7DA12DAFC for ; Thu, 1 Sep 2016 13:44:27 -0700 (PDT) Received: from [128.9.184.62] ([128.9.184.62]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u81Ki2g4001807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Sep 2016 13:44:03 -0700 (PDT) To: Ted Lemon References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Joe Touch Message-ID: Date: Thu, 1 Sep 2016 13:43:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EE508B1BFE435F5438D98B92" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 20:44:28 -0000 This is a multi-part message in MIME format. --------------EE508B1BFE435F5438D98B92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, Ted, TOFU is worse thank doing nothing because it requires user intervention to override when it's wrong. I.e., it doesn't create the vulnerability, but it makes the following tradeoff: - if you connect to the right server first, TOFU protects you from subsequent "attacks" of new servers popping up - if you connect to the wrong server first, TOFU amplifies the strength of that attack by requiring additional action to "break" the association IMO, "trust but verify" should be used here, sort of how we deal with unknown X.509 certs. 1) if not "trusted" (on first use or any use where we haven't cached trust), ask the user whether they want a one-time override or to keep the cert 2) if the cert is kept, then silently trust it. anyone who keeps certs should know how to flush them if they make a mistake I.e., neither the concern nor the fix are new. Joe On 9/1/2016 11:48 AM, Ted Lemon wrote: > Yes, I think you are right. This is the "one step back" to which > Rich was referring--he responded privately. I have copied my answer, > because I think it's worth exploring this carefully, and I'm curious > to hear your answer as well as Rich's: > > If the "wrong" server is giving you a working connection, you're no > worse off than you were without ToFU; if it's not, then you're > presumably going to connect to a different network, or complain, and > somebody with network fu will help you. I think this is better than > popping up security warnings, although I could be convinced otherwise. > A "try to fix my network" button could help as well--if someone is > pressing it, maybe the server the client bonded to sucks. Heuristics > for detecting filtered connections could also work. > > Bear in mind that a rogue server that's present on the wire and > presenting a cert at time T, but is not present at time T+100, will > not prevent the client that bonded to the rogue at time T from getting > configured by another server at time T+100. It's only if the rogue > _and_ the other server are present that the client will prefer the rogue. > > An additional heuristic here might be to always prefer the server to > which we most recently bonded when there is a choice; this would favor > the incumbent server over the intermittent rogue. > > But ultimately there is no perfect solution; the question is, is this > better than not using ToFU? > ​ --------------EE508B1BFE435F5438D98B92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Ted,

TOFU is worse thank doing nothing because it requires user intervention to override when it's wrong.

I.e., it doesn't create the vulnerability, but it makes the following tradeoff:

    - if you connect to the right server first, TOFU protects you from subsequent "attacks" of new servers popping up

    - if you connect to the wrong server first, TOFU amplifies the strength of that attack by requiring additional action to "break" the association

IMO, "trust but verify" should be used here, sort of how we deal with unknown X.509 certs.

    1) if not "trusted" (on first use or any use where we haven't cached trust), ask the user whether they want a one-time override or to keep the cert

    2) if the cert is kept, then silently trust it. anyone who keeps certs should know how to flush them if they make a mistake

I.e., neither the concern nor the fix are new.

Joe


On 9/1/2016 11:48 AM, Ted Lemon wrote:
Yes, I think you are right.   This is the "one step back" to which Rich was referring--he responded privately.   I have copied my answer, because I think it's worth exploring this carefully, and I'm curious to hear your answer as well as Rich's:

If the "wrong" server is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to connect to a different network, or complain, and somebody with network fu will help you.   I think this is better than popping up security warnings, although I could be convinced otherwise.   A "try to fix my network" button could help as well--if someone is pressing it, maybe the server the client bonded to sucks.   Heuristics for detecting filtered connections could also work.

Bear in mind that a rogue server that's present on the wire and presenting a cert at time T, but is not present at time T+100, will not prevent the client that bonded to the rogue at time T from getting configured by another server at time T+100.   It's only if the rogue _and_ the other server are present that the client will prefer the rogue.

An additional heuristic here might be to always prefer the server to which we most recently bonded when there is a choice; this would favor the incumbent server over the intermittent rogue.

But ultimately there is no perfect solution; the question is, is this better than not using ToFU?
​

--------------EE508B1BFE435F5438D98B92-- From nobody Thu Sep 1 13:48:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A612D0BD for ; Thu, 1 Sep 2016 13:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdqFR6De5e4p for ; Thu, 1 Sep 2016 13:48:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76D8E12DB07 for ; Thu, 1 Sep 2016 13:48:21 -0700 (PDT) Received: from [128.9.184.62] ([128.9.184.62]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u81KltIc002530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Sep 2016 13:47:55 -0700 (PDT) To: Ted Lemon References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Joe Touch Message-ID: <3b3fab5b-5b89-f91a-1f56-9da62b14bb97@isi.edu> Date: Thu, 1 Sep 2016 13:47:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------13C6A70801A0FBD951921FA5" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 20:48:24 -0000 This is a multi-part message in MIME format. --------------13C6A70801A0FBD951921FA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit While we're adding other things: TOFU has two purposes: a) caching trust, i.e., reducing the window of opportunity of an attacker (but it then amplifies the strength of a successful attack, as noted in my other post) b) raising the bar for the attacker in general (they have to participate in the security protocol; they can't just "fling" messages). This was the basis of BTNS, i.e., to leverage the additional work of requiring an attacker to complete a DH exchange, even if the receiver didn't (or couldn't) verify the sender's identity. Is (b) relevant for the way you're using this trust for DHCP too? I.e., would this then make it more computationally intensive for an attacker in a way that is considered useful to "raise the bar"? Joe On 9/1/2016 11:51 AM, Ted Lemon wrote: > Another thing to say, which I think is why we don't hear about this > much, is that most network infrastructure equipment lets you filter > DHCP server messages from leaf links that aren't authorized to have a > DHCP server attached to them. So you can argue that this is massive > overkill because really we won't need this solution anyway. I think > that's why Randy felt it was worth not bothering with ToFU. However, > I think ToFU potentially works well on home networks, where the > network operator doesn't have enough network fu to know how to filter > DHCP, but where we can assume a stable incumbent DHCP server with a > stable key. > > On Thu, Sep 1, 2016 at 2:48 PM, Ted Lemon > wrote: > > Yes, I think you are right. This is the "one step back" to which > Rich was referring--he responded privately. I have copied my > answer, because I think it's worth exploring this carefully, and > I'm curious to hear your answer as well as Rich's: > > If the "wrong" server is giving you a working connection, you're > no worse off than you were without ToFU; if it's not, then you're > presumably going to connect to a different network, or complain, > and somebody with network fu will help you. I think this is > better than popping up security warnings, although I could be > convinced otherwise. A "try to fix my network" button could help > as well--if someone is pressing it, maybe the server the client > bonded to sucks. Heuristics for detecting filtered connections > could also work. > > Bear in mind that a rogue server that's present on the wire and > presenting a cert at time T, but is not present at time T+100, > will not prevent the client that bonded to the rogue at time T > from getting configured by another server at time T+100. It's > only if the rogue _and_ the other server are present that the > client will prefer the rogue. > > An additional heuristic here might be to always prefer the server > to which we most recently bonded when there is a choice; this > would favor the incumbent server over the intermittent rogue. > > But ultimately there is no perfect solution; the question is, is > this better than not using ToFU? > ​ > > --------------13C6A70801A0FBD951921FA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

While we're adding other things:

TOFU has two purposes:

a) caching trust, i.e., reducing the window of opportunity of an attacker (but it then amplifies the strength of a successful attack, as noted in my other post)

b) raising the bar for the attacker in general (they have to participate in the security protocol; they can't just "fling" messages). This was the basis of BTNS, i.e., to leverage the additional work of requiring an attacker to complete a DH exchange, even if the receiver didn't (or couldn't) verify the sender's identity.

Is (b) relevant for the way you're using this trust for DHCP too? I.e., would this then make it more computationally intensive for an attacker in a way that is considered useful to "raise the bar"?

Joe


On 9/1/2016 11:51 AM, Ted Lemon wrote:
Another thing to say, which I think is why we don't hear about this much, is that most network infrastructure equipment lets you filter DHCP server messages from leaf links that aren't authorized to have a DHCP server attached to them.   So you can argue that this is massive overkill because really we won't need this solution anyway.   I think that's why Randy felt it was worth not bothering with ToFU.   However, I think ToFU potentially works well on home networks, where the network operator doesn't have enough network fu to know how to filter DHCP, but where we can assume a stable incumbent DHCP server with a stable key.

On Thu, Sep 1, 2016 at 2:48 PM, Ted Lemon <mellon@fugue.com> wrote:
Yes, I think you are right.   This is the "one step back" to which Rich was referring--he responded privately.   I have copied my answer, because I think it's worth exploring this carefully, and I'm curious to hear your answer as well as Rich's:

If the "wrong" server is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to connect to a different network, or complain, and somebody with network fu will help you.   I think this is better than popping up security warnings, although I could be convinced otherwise.   A "try to fix my network" button could help as well--if someone is pressing it, maybe the server the client bonded to sucks.   Heuristics for detecting filtered connections could also work.

Bear in mind that a rogue server that's present on the wire and presenting a cert at time T, but is not present at time T+100, will not prevent the client that bonded to the rogue at time T from getting configured by another server at time T+100.   It's only if the rogue _and_ the other server are present that the client will prefer the rogue.

An additional heuristic here might be to always prefer the server to which we most recently bonded when there is a choice; this would favor the incumbent server over the intermittent rogue.

But ultimately there is no perfect solution; the question is, is this better than not using ToFU?
​


--------------13C6A70801A0FBD951921FA5-- From nobody Thu Sep 1 13:53:53 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C568412DB08 for ; Thu, 1 Sep 2016 13:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zsxwY_x0yBr for ; Thu, 1 Sep 2016 13:53:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0412DB03 for ; Thu, 1 Sep 2016 13:53:48 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E4FF243344D; Thu, 1 Sep 2016 20:53:47 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CB372433409; Thu, 1 Sep 2016 20:53:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472763227; bh=wC7e2aIuRMKZXCf+bNVgj6XHZaeSLJJaRAU20B8CuZk=; l=564; h=From:To:CC:Date:References:In-Reply-To:From; b=Nk9oyu3yK/X14Qv78rsXor9y5jjMbvc25/C+7YX83tKvYzXf+NDkXqy9TExzS2+oP btSW2FiFJXgyG7UVptCAcnvIPaG5hgkkHTGkUAhbtfJtS8WrQBPsPiuKxP2tJdSMMM Sw2cnrqZMZizvJVa9KdH63s++yX/Kgrgu4AuvM4M= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C3EC41FC8E; Thu, 1 Sep 2016 20:53:47 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 13:53:47 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 16:53:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 16:53:47 -0400 From: "Salz, Rich" To: Joe Touch , Ted Lemon Thread-Topic: [saag] A little more detail on ToFU for DHCPv6 Thread-Index: AQHSBHzjksesDgMA50+i7tKfYfpYpqBlO4OAgAABdICAAADhAIAAIHMA//++A7A= Date: Thu, 1 Sep 2016 20:53:46 +0000 Message-ID: <2313bf9741474073a4f8e526b56e679b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <3b3fab5b-5b89-f91a-1f56-9da62b14bb97@isi.edu> In-Reply-To: <3b3fab5b-5b89-f91a-1f56-9da62b14bb97@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.142] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 20:53:52 -0000 PiBUT0ZVIGhhcyB0d28gcHVycG9zZXM6DQoNCkkgdGhpbmsgaXQgaGFzIGEgdGhpcmQ6IHZlcnkg d2VhayBhdXRoZW50aWNhdGlvbi4gIEZvciBleGFtcGxlLCBtb3N0IHVzZXMgb2Ygc3NoIHdpdGhp biBhbiBvcmdhbml6YXRpb24sIHdoZXJlIHRoZSBwcmltYXJ5IG1vdGl2YXRpb24gaXMgaW50ZWdy aXR5IGFuZCBwcml2YWN5LiBXaGVuIEknbSB1c2luZyBrZXktYmFzZWQgYXV0aGVuLCBJJ20gbm90 IGdpdmluZyBteSBwYXNzd29yZCBhd2F5LiAgTm93YWRheXMgd2UnZCByZWxhdGUgaXQgdG8gb3Bw b3J0dW5pc3RpYyBlbmNyeXB0aW9uLCBwZXJoYXBzLg0KDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0 LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJp Y2hTYWx6DQoNCg0K From nobody Thu Sep 1 14:01:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1EA12DAFD for ; Thu, 1 Sep 2016 14:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmtX_Gv6Hgt8 for ; Thu, 1 Sep 2016 14:00:57 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326C912DAEC for ; Thu, 1 Sep 2016 14:00:57 -0700 (PDT) Received: from [10.123.91.212] (usc-secure-wireless-088-212.usc.edu [68.181.88.212]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u81L0Ftk004308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Sep 2016 14:00:17 -0700 (PDT) To: "Salz, Rich" , Ted Lemon References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <3b3fab5b-5b89-f91a-1f56-9da62b14bb97@isi.edu> <2313bf9741474073a4f8e526b56e679b@usma1ex-dag1mb1.msg.corp.akamai.com> From: Joe Touch Message-ID: <58132ce5-adc1-dd4a-d52c-1c4c8fb7dc7e@isi.edu> Date: Thu, 1 Sep 2016 14:00:12 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2313bf9741474073a4f8e526b56e679b@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 21:00:58 -0000 On 9/1/2016 1:53 PM, Salz, Rich wrote: >> TOFU has two purposes: > I think it has a third: very weak authentication. For example, most uses of ssh within an organization, where the primary motivation is integrity and privacy. When I'm using key-based authen, I'm not giving my password away. Nowadays we'd relate it to opportunistic encryption, perhaps. TOFU doesn't authenticate anything except "same as before", but that's just because you cached the info the first time you saw it. We used DH without signatures for IPsec to protect a connection once established - regardless of with whom it was established. I'm not sure how this is related to "opportunistic encryption" because I've seen that defined far too many ways (including mis-defined as applying to BTNS). Joe From nobody Thu Sep 1 14:05:04 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76112D771 for ; Thu, 1 Sep 2016 14:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huq8lrrlmR3W for ; Thu, 1 Sep 2016 14:05:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA8612DB02 for ; Thu, 1 Sep 2016 14:04:58 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9CB0A43344F; Thu, 1 Sep 2016 21:04:58 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 85F48433409; Thu, 1 Sep 2016 21:04:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472763898; bh=iLRrjYHn4JZlfRqHZsbevgIhEdkQj1ZDd0RAnbKMID8=; l=334; h=From:To:CC:Date:References:In-Reply-To:From; b=rk1kDAxn65YH+f/EpYmvSItv0KUWfspfxOxs03QKH/6LPI4Rf3yJgnlywN0PkE747 bQSSVLQ5OqIK/p2iVExOdJF+UppgENtlawLC28unuioGoJ3vE/wBYKVytKmsd02pda weV4mH6qAokuzeGv3a2CnDW6Jxr6RxMKrTYwucxg= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 7EB0C1FC8C; Thu, 1 Sep 2016 21:04:58 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 17:04:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 17:04:58 -0400 From: "Salz, Rich" To: Joe Touch , Ted Lemon Thread-Topic: [saag] A little more detail on ToFU for DHCPv6 Thread-Index: AQHSBHzjksesDgMA50+i7tKfYfpYpqBlO4OAgAABdICAAADhAIAAIHMA//++A7CAAEVvAP//viWA Date: Thu, 1 Sep 2016 21:04:57 +0000 Message-ID: <408f7eaee4b041ba9e719f137ae3cb37@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <3b3fab5b-5b89-f91a-1f56-9da62b14bb97@isi.edu> <2313bf9741474073a4f8e526b56e679b@usma1ex-dag1mb1.msg.corp.akamai.com> <58132ce5-adc1-dd4a-d52c-1c4c8fb7dc7e@isi.edu> In-Reply-To: <58132ce5-adc1-dd4a-d52c-1c4c8fb7dc7e@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.142] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 21:05:02 -0000 PiBJJ20gbm90IHN1cmUgaG93IHRoaXMgaXMgcmVsYXRlZCB0byAib3Bwb3J0dW5pc3RpYyBlbmNy eXB0aW9uIiBiZWNhdXNlIEkndmUNCj4gc2VlbiB0aGF0IGRlZmluZWQgZmFyIHRvbyBtYW55IHdh eXMNCg0KV2hpY2ggaXMgd2h5IEkgc2FpZCBwZXJoYXBzIDopDQotLSAgDQpTZW5pb3IgQXJjaGl0 ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6 IFJpY2hTYWx6DQoNCg0K From nobody Thu Sep 1 14:20:15 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F8C12DB08; Thu, 1 Sep 2016 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRMds2kTl1d6; Thu, 1 Sep 2016 14:20:11 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD0B12DB1B; Thu, 1 Sep 2016 14:20:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5BF231E9F; Thu, 1 Sep 2016 21:20:09 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B0gAQH9egMI; Thu, 1 Sep 2016 21:20:09 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id C3D641E72; Thu, 1 Sep 2016 21:20:08 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 1 Sep 2016 17:20:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> References: To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-li-dhc-secure-dhcpv6-deployment@ietf.org, Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 21:20:13 -0000 On Sep 1, 2016, at 2:15 PM, Ted Lemon wrote: >=20 > I just reviewed the thread, and noticed that there hasn't actually = been an explanation of how this is supposed to be useful. >=20 > For those who are not intimately familiar with DHCP, here is how it = works: > =E2=80=A2 a client notices that it has joined a link > =E2=80=A2 the client sends a solicit message > =E2=80=A2 zero or more DHCP servers respond within a certain = window (1s, by default). > =E2=80=A2 the client picks one of these responses based on = various criteria, or if it has no basis for preferring one, at random, = or possibly just the first or last one that arrived. The details of = this selection process are not specified in RFC 3315. > =E2=80=A2 the client is now wedded to that DHCP server until it = moves to a new link or the server goes away > When a client connects to a link, either it will be a link the client = has previously connected to, or not. If it is a link to which the = client had previously connected, there may be a rogue DHCP server on the = link that wasn't present last time the client connected. ToFU, with no = user confirmation, blocks the rogue DHCP server from being chosen by the = client, assuming that the previously used server is still present. In all of this discussion, I see nothing about 802.1X. i.e. if a user does 802.1X before DHCP... they have a security = association with the AAA server. Is there any way to leverage that for = DHCP? While there are many situations where the users don't do 802.1X, there = are many situations where they *will* do 802.1X. Those situations = should be addressed in the document. Why not have the AAA server introduce the DHCP server? i.e. send over = a copy of the certificate, or hints about the certificate to the DHCP = client. The client is free to ignore that information, of course. But = that information should probably be used in preference to any guesses = made by the client. > When a client connects to a link to which it has never previously = connected, it will pick a DHCP server. This DHCP server may or may not = be a rogue DHCP server. If it is a rogue DHCP server, the client is = potentially screwed, and the end user will potentially notice this, = depending on what sort of attach the rogue server is attempting. The = user can detect this and say "don't use this server anymore." If a client is connecting via 802.1X, it can be instructed as to which = DHCP server to use. In which case rogue DHCP servers just aren't a = problem, no matter what else is going on (or not) in the network. > If the client is connecting to a Boingo hotspot, Boingo can (a) filter = out rogue DHCP packets and (b) sign the key it uses using a PKI cert = chain that can be validated. The client can be configured to prefer = keys signed by that entity. This can also be done for enterprise = clients. There's no reason why this has to be difficult, and we can = use the PKI infrastructure to make it work, or we can use DANE, in = theory. Or via 802.1X. Which is widely deployed in enterprise environments, = and in mobile networks. Alan DeKok. From nobody Thu Sep 1 14:44:17 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44612D1ED for ; Thu, 1 Sep 2016 14:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUlPIAK5RpBg for ; Thu, 1 Sep 2016 14:44:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5518212D100 for ; Thu, 1 Sep 2016 14:44:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfZmM-00061x-Mb; Thu, 01 Sep 2016 21:44:10 +0000 Date: Fri, 02 Sep 2016 06:44:39 +0900 Message-ID: From: Randy Bush To: Lishan Li In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <3CE7E269-C895-49BC-972E-5CD33D128987@dukhovni.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Ted Lemon , JINMEI Tatuya , Security Area Advisory Group Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 21:44:15 -0000 > Sure, Tofu is not as good as one might desire. we know what tofu is and what it isn't. for ENCRYPTED dhcpv6, tofu is fine. for SECURE dhcpv6, imiho, it is not. randy From nobody Thu Sep 1 14:45:45 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E9512D1ED for ; Thu, 1 Sep 2016 14:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C5Frxjjmj5B for ; Thu, 1 Sep 2016 14:45:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D85012D13F for ; Thu, 1 Sep 2016 14:45:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfZno-00062N-De; Thu, 01 Sep 2016 21:45:40 +0000 Date: Fri, 02 Sep 2016 06:46:09 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307A11F3CA6@mbx-01.win.nominum.com> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: JINMEI Tatuya , "saag@ietf.org" Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 21:45:44 -0000 > All you know is "this is the same server that worked last time." the part i like best is when you get an auth failure on the second use. was the first one the mitm or the second? or both? randy From nobody Thu Sep 1 14:47:49 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1871912D100 for ; Thu, 1 Sep 2016 14:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM4DnMdXK1Ed for ; Thu, 1 Sep 2016 14:47:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5857E12B063 for ; Thu, 1 Sep 2016 14:47:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfZpn-00062y-Sq; Thu, 01 Sep 2016 21:47:44 +0000 Date: Fri, 02 Sep 2016 06:48:12 +0900 Message-ID: From: Randy Bush To: "Salz, Rich" In-Reply-To: <8801f0999ffe4fe693ae2904d87161eb@usma1ex-dag1mb1.msg.corp.akamai.com> References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "saag@ietf.org" , JINMEI Tatuya , Ted Lemon Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 21:47:48 -0000 > On the other hand, an enterprise being able to configure it's DHCP > server in the workstations it gives out is a nice hook to have. in yokohama, enterprise was the goal on which we agreed, specifically not the coffee shop. which was why we agreed no tofu. randy From nobody Thu Sep 1 15:53:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2EEF12B034 for ; Thu, 1 Sep 2016 15:53:55 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qk3LNW7t5u3i for ; Thu, 1 Sep 2016 15:53:53 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B65912D96A for ; Thu, 1 Sep 2016 15:53:53 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id e198so37821271lfb.2 for ; Thu, 01 Sep 2016 15:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W/XMY5FImcHjk0m7LYiVZWT3lgg28JdpMM1Y/xZ2Ghk=; b=0i9rIv6y+5QrR7jJHaCnFdSxZsy+fkNUMkI+cNr2TSGehhp7W5+8HUBHhN8CcKWedI k5iY3j2xb/yTiU6H3LZTiv+jC9jhFQVA7BE/lSHCcr6kCCs9CrC2WsoTuoH26afPvd7M 136XwthRkYT9BzfTJ7LB0NDA6AfWpwYpAn0jPW5l9Es7EGo5biPECIO8pTU6qsHMhBu5 hJnWSFU0zqRg+ZVWnZIe3Fw1i+j0aar/hAwWHHBeNteJLD6uLBTKva4lMdcMWWe4JgUd YSYFvp81gioz649M0Robm+e7G1shaf7arH02feuEYnpFdZIDcr5iXni46WZxfI1d0Pcn I13g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W/XMY5FImcHjk0m7LYiVZWT3lgg28JdpMM1Y/xZ2Ghk=; b=DhZZooRGzQyeZNJcM44g9SeOLGow3zdiEJjGh5QSmBn89B094GI6o5UquYC3mQ/OUl iS0snRITYx/rwxDwIf9IAq7DKBbjpAJiAiZ30SibSY1bAL40Mi/WXCC92WOHsylHPe20 8mlZMWEF6Wmlg+pkH5dMDqsBevmaBbqjLmGx2YbP0D9KEnAxHcBVwgzzvVN519DFzIEx Yv7zhEInbIbRH04gvXeFkCSOlaCGk6l7NRxSUOyUydbKFDZ2PM5eUUc89JyjX0hhe62Q G99pCqjABq2rDIvXykgya/I7BZbVYlxQzBuVu4PL2ovhtUz5jx2ojZo09h5gXZ6ZKkDR Hv4w== X-Gm-Message-State: AE9vXwOBH4K4Q0gR6tceeM0AqBppleVco+iDRMiwL28/cYNjhMhVr2bS4/HxwATILLOvGGRt/UAL2hJJuuh1TQ== X-Received: by 10.25.26.194 with SMTP id a185mr6154150lfa.167.1472770431436; Thu, 01 Sep 2016 15:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 15:53:10 -0700 (PDT) In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <8801f0999ffe4fe693ae2904d87161eb@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ted Lemon Date: Thu, 1 Sep 2016 18:53:10 -0400 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a11403bd866de22053b7a165e Archived-At: Cc: Ted Lemon , "saag@ietf.org" , JINMEI Tatuya Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 22:53:56 -0000 --001a11403bd866de22053b7a165e Content-Type: text/plain; charset=UTF-8 Yes, that's what you told us to do, and then we got a comment from Stephen that he thought we should do ToFU, so here we are. I always thought ToFU was a good idea, so I'm happy to go with Stephen's request. On Thu, Sep 1, 2016 at 5:48 PM, Randy Bush wrote: > > On the other hand, an enterprise being able to configure it's DHCP > > server in the workstations it gives out is a nice hook to have. > > in yokohama, enterprise was the goal on which we agreed, specifically > not the coffee shop. which was why we agreed no tofu. > > randy > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11403bd866de22053b7a165e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, that's what you told us to do, and then we got a = comment from Stephen that he thought we should do ToFU, so here we are.
I always thought ToFU was a good idea, so I'm happy to = go with Stephen's request.

On Thu, Sep 1, 2016 at 5:48 PM, Randy Bush <randy@psg= .com> wrote:
> On the other hand, an enterprise being able to configure it's D= HCP
> server in the workstations it gives out is a nice hook to have.

in yokohama, enterprise was the goal on which we agreed, specificall= y
not the coffee shop.=C2=A0 which was why we agreed no tofu.

randy

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

--001a11403bd866de22053b7a165e-- From nobody Thu Sep 1 15:58:40 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA9512DB08 for ; Thu, 1 Sep 2016 15:58:39 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlfTkJGytOrK for ; Thu, 1 Sep 2016 15:58:37 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821A412D7A1 for ; Thu, 1 Sep 2016 15:58:37 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id g62so71434088lfe.3 for ; Thu, 01 Sep 2016 15:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M5BVpxRku4rkCTXIWyx8MIdk8IgN1zlu1V7+wqHfSDs=; b=L0nyfac95a/h9z/lDA8CcMh05WpTawF0CyMlKZpFnofMasa6tBbdU8xadFALdekDlt JgXjF4gLxU+a2oEbCnJBFKkpCsn29xZWx57ic67xC9oy1cxF+Z0KDBWNbnQwOHL+FkiZ mdYTHQfD/CUXvC8lhjeqlxW6me32b4Bx5FtZFLQczsUkDW49et9N6AlznZO4TG3rNBRw 9MPbc7teif0QnmfEn7Ax2Yc84pKK6WxBgHZIlkJaJNzUtSCP921LQQHregcHaTmTcrGG SnHzQcj3i3DohV+ofC+MyREs/Zf1m7Zog92mAMUX8s6xIeR/SAbionmVTkttygJ2ijKE mufA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M5BVpxRku4rkCTXIWyx8MIdk8IgN1zlu1V7+wqHfSDs=; b=BTrOIqFwS0EqBMdLppHRj349SNkfgCN7GGjOgZOo5SKoIXGKKn07sVcCBH+qy/U++M TydqHc5z1brnFxi0YZiIee3odFznwk93J8LaxBRj9TNXVQoYibV/mlZOf2/yuLv82bRG ZLedLl7S3h5eHpfejKw/DyRx7aOAEoQDyiIoVxLAuLabuKt1J2ikLKpe5SZRJI4bh1Fn wEDZpj4FM8nj4ZPLvN4pFPdV4Ki9pn+tpQZbauxFXszANcOlHVVIZfqvpQkqMFn7u/wP 3L++VEgcW/sIU6nMgBnS2dGbMATZzme0ueClPjlS/fh3yDijHnwb/yzHz9KSeyu8l39T nqNg== X-Gm-Message-State: AE9vXwOpWY12RSGs6c4szDqkB6M5zpDuV5FqRCcKmFyyIbjlWKTt22PIu/i+YuZwUR4FW6DtnWbbp8kx3ErNlw== X-Received: by 10.25.201.69 with SMTP id z66mr4975366lff.226.1472770715543; Thu, 01 Sep 2016 15:58:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 15:57:54 -0700 (PDT) In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Ted Lemon Date: Thu, 1 Sep 2016 18:57:54 -0400 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a114b246e560050053b7a2772 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 22:58:39 -0000 --001a114b246e560050053b7a2772 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch wrote: > TOFU is worse thank doing nothing because it requires user intervention to > override when it's wrong. > It's as if you haven't read anything I've written. Can you go back and do that, and then respond to what I wrote, and not just slogan at me? Sorry to be less than appreciative--I do appreciate having a discussion, but the discussion needs to be talking about real issues in order to be useful. The reality is that when a user gets attacked by a rogue server, there is _always_ going to have to be user intervention. To evaluate the proposal meaningfully, we have to answer two questions: does ToFU make such interventions more or less likely, and does it make them appreciably worse or better? 1) if not "trusted" (on first use or any use where we haven't cached > trust), ask the user whether they want a one-time override or to keep the > cert > I'm sorry, but this is nonsense. You should never ask a user to trust a cert--they are not equipped to make this decision, and you are training them to be susceptible to malware. Either you have a basis for trusting a cert, or you do not. If you do not, then you simply don't trust it. Full stop. You do not ask the user whether to trust it. --001a114b246e560050053b7a2772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 1, 2016 at 4:43 PM, Joe Touch <touch@isi.edu> wrote:
=
=20 =20 =20

TOFU is worse thank doing nothing because it requires user intervention to override when it's wrong.

It's as if you haven't read anything I've written. =C2= =A0 Can you go back and do that, and then respond to what I wrote, and not = just slogan at me? =C2=A0 Sorry to be less than appreciative--I do apprecia= te having a discussion, but the discussion needs to be talking about real i= ssues in order to be useful.

The reality is that w= hen a user gets attacked by a rogue server, there is _always_ going to have= to be user intervention. =C2=A0 To evaluate the proposal meaningfully, we = have to answer two questions: does ToFU make such interventions more or les= s likely, and does it make them appreciably worse or better?

=

=C2=A0 =C2=A0 1) if not "trusted" (on first use or any use= where we haven't cached trust), ask the user whether they want a one-time override or to keep the cert


I'm= sorry, but this is nonsense. =C2=A0 You should never ask a user to trust a= cert--they are not equipped to make this decision, and you are training th= em to be susceptible to malware. =C2=A0 Either you have a basis for trustin= g a cert, or you do not. =C2=A0 If you do not, then you simply don't tr= ust it.=C2=A0 Full stop. =C2=A0 You do not ask the user whether to trust it= .
--001a114b246e560050053b7a2772-- From nobody Thu Sep 1 16:03:45 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501FC12DB20 for ; Thu, 1 Sep 2016 16:03:44 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcrfpGlSNluK for ; Thu, 1 Sep 2016 16:03:41 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7A012D791 for ; Thu, 1 Sep 2016 16:03:41 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id p41so53052071lfi.1 for ; Thu, 01 Sep 2016 16:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4XDl2UJdz4acj2OiCGx5lG9USNa7LLrlLr/mphUHf8Q=; b=d7C0Oa4jVydA9CQAVAgYShaAqWqRJxpY96ftpahpDc9wzDbF778cVwCjytktHZr+UI 9RCu1EGlOtK+bOtivmk4lmedXTCnSPRThb0MXEXddbd2oJuhX9/JymCMnuYyG1Nmpl0d TErLnY9B85wZgo6Gn8r5DoKTgdtO/cgY+8nxP7z+F/QOLkWxqzqA8k5CAkeGApY1vBC6 s+JMnB4xBq6DOCb8ofIJf1XPq31cA9k5zOckQryCVFv0NWuzzrHnv9e/Z6T66vRHc20C ilTnuLZDtMD5I4Gf6tNOJW/dBAG0Rd76RWm0Ds+R/PThqdjKTVFYx+wECc0RVzTp88Zb ZZxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4XDl2UJdz4acj2OiCGx5lG9USNa7LLrlLr/mphUHf8Q=; b=Il5jfEbvAtz6VUvtzu2qRrLAlVa6ybOpef61qiM9sdveaXvTCMm1l27dTFtl4/Av+Y CAoeJkAgi/mgSUusM9Qokyj2/iwvzBVTpGlSFqOdP4VlqOZmubpVHfYF1gCENqC68g48 4GXwnkxmW8U8YCV/kp1gISwdk1Pc3RALp8rE8Qm+2mWYhl9AI0qQItjRIhjIqBDXhemx N8B85w/QoUYD99VQs7TGKBrj8ZEPrr7tQoFi5BQUKv2gASHuANdaTTxIzuAPK+XpUq9b b43+FKUZNNYpl3H7SubF3b/i12vp+1T8cf+arNovwnmWmDQDeRB+nJGj2QYiJ/rOZJlx UwlA== X-Gm-Message-State: AE9vXwMWkQZ7OYy/KpBFQPmS3omP1Lvu0UnO22tsnzh9GknjJvZTfpXxL0AKscBf0QYJizVn2a8AuxfvwRVtwA== X-Received: by 10.46.0.97 with SMTP id 94mr5727668lja.60.1472771019179; Thu, 01 Sep 2016 16:03:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 16:02:58 -0700 (PDT) In-Reply-To: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> From: Ted Lemon Date: Thu, 1 Sep 2016 19:02:58 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a1142c3c46f1a87053b7a39f1 Archived-At: Cc: draft-li-dhc-secure-dhcpv6-deployment@ietf.org, Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 23:03:44 -0000 --001a1142c3c46f1a87053b7a39f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm going to give a somewhat unhelpful response, but the question that pops to mine when you suggest that is, why don't we also do this for web pages and for ssh? That is, if you have 802.1x, why not use that security association to authenticate ssh servers? I think the answer is clearly that you would never do this; I can see why you might think that it would be okay to do it for DHCP, but I still think it's worth trying to explicitly answer the question. In any case, from my perspective, what you're suggesting sounds like something that would never be deployed. When and how effectively is 802.1x deployed? Are those the same sites that we are trying to help with DHCP authentication? If you have 802.1x, why aren't you doing DHCP filtering? I don't think this is an important use case, but if it is, a pre-shared cert will solve the problem, and you don't want to use ToFU anyway. On Thu, Sep 1, 2016 at 5:20 PM, Alan DeKok wrote: > On Sep 1, 2016, at 2:15 PM, Ted Lemon wrote: > > > > I just reviewed the thread, and noticed that there hasn't actually been > an explanation of how this is supposed to be useful. > > > > For those who are not intimately familiar with DHCP, here is how it > works: > > =E2=80=A2 a client notices that it has joined a link > > =E2=80=A2 the client sends a solicit message > > =E2=80=A2 zero or more DHCP servers respond within a certain wind= ow (1s, > by default). > > =E2=80=A2 the client picks one of these responses based on variou= s > criteria, or if it has no basis for preferring one, at random, or possibl= y > just the first or last one that arrived. The details of this selection > process are not specified in RFC 3315. > > =E2=80=A2 the client is now wedded to that DHCP server until it m= oves to a > new link or the server goes away > > When a client connects to a link, either it will be a link the client > has previously connected to, or not. If it is a link to which the clien= t > had previously connected, there may be a rogue DHCP server on the link th= at > wasn't present last time the client connected. ToFU, with no user > confirmation, blocks the rogue DHCP server from being chosen by the clien= t, > assuming that the previously used server is still present. > > In all of this discussion, I see nothing about 802.1X. > > i.e. if a user does 802.1X before DHCP... they have a security > association with the AAA server. Is there any way to leverage that for > DHCP? > > While there are many situations where the users don't do 802.1X, there > are many situations where they *will* do 802.1X. Those situations should > be addressed in the document. > > Why not have the AAA server introduce the DHCP server? i.e. send over = a > copy of the certificate, or hints about the certificate to the DHCP > client. The client is free to ignore that information, of course. But > that information should probably be used in preference to any guesses mad= e > by the client. > > > When a client connects to a link to which it has never previously > connected, it will pick a DHCP server. This DHCP server may or may not = be > a rogue DHCP server. If it is a rogue DHCP server, the client is > potentially screwed, and the end user will potentially notice this, > depending on what sort of attach the rogue server is attempting. The us= er > can detect this and say "don't use this server anymore." > > If a client is connecting via 802.1X, it can be instructed as to which > DHCP server to use. In which case rogue DHCP servers just aren't a > problem, no matter what else is going on (or not) in the network. > > > If the client is connecting to a Boingo hotspot, Boingo can (a) filter > out rogue DHCP packets and (b) sign the key it uses using a PKI cert chai= n > that can be validated. The client can be configured to prefer keys sign= ed > by that entity. This can also be done for enterprise clients. There's > no reason why this has to be difficult, and we can use the PKI > infrastructure to make it work, or we can use DANE, in theory. > > Or via 802.1X. Which is widely deployed in enterprise environments, an= d > in mobile networks. > > Alan DeKok. > > --001a1142c3c46f1a87053b7a39f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm going to give a somewhat unhelpful response, but t= he question that pops to mine when you suggest that is, why don't we al= so do this for web pages and for ssh? =C2=A0 That is, if you have 802.1x, w= hy not use that security association to authenticate ssh servers? =C2=A0 I = think the answer is clearly that you would never do this; I can see why you= might think that it would be okay to do it for DHCP, but I still think it&= #39;s worth trying to explicitly answer the question.

In= any case, from my perspective, what you're suggesting sounds like some= thing that would never be deployed. =C2=A0 When and how effectively is 802.= 1x deployed? =C2=A0 Are those the same sites that we are trying to help wit= h DHCP authentication? =C2=A0 If you have 802.1x, why aren't you doing = DHCP filtering? =C2=A0 I don't think this is an important use case, but= if it is, a pre-shared cert will solve the problem, and you don't want= to use ToFU anyway.

<= br>
On Thu, Sep 1, 2016 at 5:20 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 1, 2016, at 2:15 PM, Ted Lemon <<= a href=3D"mailto:mellon@fugue.com">mellon@fugue.com> wrote:
>
> I just reviewed the thread, and noticed that there hasn't actually= been an explanation of how this is supposed to be useful.
>
> For those who are not intimately familiar with DHCP, here is how it wo= rks:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 a client notices that it has joine= d a link
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 the client sends a solicit message=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 zero or more DHCP servers respond = within a certain window (1s, by default).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 the client picks one of these resp= onses based on various criteria, or if it has no basis for preferring one, = at random, or possibly just the first or last one that arrived.=C2=A0 =C2= =A0The details of this selection process are not specified in RFC 3315.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 the client is now wedded to that D= HCP server until it moves to a new link or the server goes away
> When a client connects to a link, either it will be a link the client = has previously connected to, or not.=C2=A0 =C2=A0If it is a link to which t= he client had previously connected, there may be a rogue DHCP server on the= link that wasn't present last time the client connected.=C2=A0 =C2=A0T= oFU, with no user confirmation, blocks the rogue DHCP server from being cho= sen by the client, assuming that the previously used server is still presen= t.

=C2=A0 In all of this discussion, I see nothing about 802.1X.

=C2=A0 i.e. if a user does 802.1X before DHCP... they have a security assoc= iation with the AAA server.=C2=A0 Is there any way to leverage that for DHC= P?

=C2=A0 While there are many situations where the users don't do 802.1X,= there are many situations where they *will* do 802.1X.=C2=A0 Those situati= ons should be addressed in the document.

=C2=A0 Why not have the AAA server introduce the DHCP server?=C2=A0 i.e. se= nd over a copy of the certificate, or hints about the certificate to the DH= CP client.=C2=A0 The client is free to ignore that information, of course.= =C2=A0 But that information should probably be used in preference to any gu= esses made by the client.

> When a client connects to a link to which it has never previously conn= ected, it will pick a DHCP server.=C2=A0 =C2=A0This DHCP server may or may = not be a rogue DHCP server.=C2=A0 =C2=A0If it is a rogue DHCP server, the c= lient is potentially screwed, and the end user will potentially notice this= , depending on what sort of attach the rogue server is attempting.=C2=A0 = =C2=A0The user can detect this and say "don't use this server anym= ore."

=C2=A0 If a client is connecting via 802.1X, it can be instructed as= to which DHCP server to use.=C2=A0 In which case rogue DHCP servers just a= ren't a problem, no matter what else is going on (or not) in the networ= k.

> If the client is connecting to a Boingo hotspot, Boingo can (a) filter= out rogue DHCP packets and (b) sign the key it uses using a PKI cert chain= that can be validated.=C2=A0 =C2=A0The client can be configured to prefer = keys signed by that entity.=C2=A0 =C2=A0This can also be done for enterpris= e clients.=C2=A0 =C2=A0There's no reason why this has to be difficult, = and we can use the PKI infrastructure to make it work, or we can use DANE, = in theory.

=C2=A0 Or via 802.1X.=C2=A0 Which is widely deployed in enterprise e= nvironments, and in mobile networks.

=C2=A0 Alan DeKok.


--001a1142c3c46f1a87053b7a39f1-- From nobody Thu Sep 1 16:12:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F25912DB20 for ; Thu, 1 Sep 2016 16:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhhuhMvq2g2l for ; Thu, 1 Sep 2016 16:12:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BAD12D7A2 for ; Thu, 1 Sep 2016 16:12:13 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfb9U-0006Kt-O7; Thu, 01 Sep 2016 23:12:09 +0000 Date: Fri, 02 Sep 2016 08:12:37 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: References: <09c0e199-07e7-81b2-e414-3920672950b7@cs.tcd.ie> <8801f0999ffe4fe693ae2904d87161eb@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Ted Lemon , "saag@ietf.org" , JINMEI Tatuya Subject: Re: [saag] Whether TOFU should be considered in secure DHCPv6? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 23:12:14 -0000 > Yes, that's what you told us to do, and then we got a comment from > Stephen that he thought we should do ToFU, so here we are. >> in yokohama, enterprise was the goal on which we agreed, specifically >> not the coffee shop. which was why we agreed no tofu. not exactly. that is what we agreed in order to actually try to have *secure* dhcpv6. because we did not understand how to actually provide a *secure* solution outside of the enterprise-like space. as far as i can see, we still don't. randy From nobody Thu Sep 1 16:13:14 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A96112D08E for ; Thu, 1 Sep 2016 16:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHAfnwyMkjAZ for ; Thu, 1 Sep 2016 16:13:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C14312B007 for ; Thu, 1 Sep 2016 16:13:11 -0700 (PDT) Received: from [10.123.91.212] (usc-secure-wireless-088-212.usc.edu [68.181.88.212]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u81NCLUo018682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Sep 2016 16:12:30 -0700 (PDT) To: Ted Lemon References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Joe Touch Message-ID: <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> Date: Thu, 1 Sep 2016 16:12:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F5486D346C7CE636F857FD84" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 23:13:13 -0000 This is a multi-part message in MIME format. --------------F5486D346C7CE636F857FD84 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/1/2016 3:57 PM, Ted Lemon wrote: > On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch > wrote: > > TOFU is worse thank doing nothing because it requires user > intervention to override when it's wrong. > > It's as if you haven't read anything I've written. /You said two things: 1) "/When a client connects to a link to which it has never previously connected, it will pick a DHCP server. This DHCP server may or may not be a rogue DHCP server. If it is a rogue DHCP server, the client is potentially screwed, and the end user will potentially notice this, depending on what sort of attach the rogue server is attempting. The user can detect this and say "don't use this server anymore."" and later "I don't think there's any point in re-keying in a typical case, and I don't think there's any point in interacting with the user in a typical case. There should not be security pop-ups. If the network isn't working, the user will stop using it; that's the UX we want." You also then said: 2) "If the "wrong" server is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to connect to a different network, or complain, and somebody with network fu will help you. I think this is better than popping up security warnings, although I could be convinced otherwise. A "try to fix my network" button could help as well--if someone is pressing it, maybe the server the client bonded to sucks. Heuristics for detecting filtered connections could also work." That's what I disagree with. Did I miss another post where you said something different? IMO, there is an existing UI for handling this - to make the user aware of the TOFU case when it first occurs and ask for them to confirm whether they want to continue that trust or make it a one-time case. I.e., trust-now or on first use (TNOOFU), not just TOFU. // > > The reality is that when a user gets attacked by a rogue server, there > is _always_ going to have to be user intervention. Your version of user intervention and mine are different. You say simply "stop using the network". IMO, investing in the trust should be opt-im and explicit, not silent and automatic. Those are very different things. > To evaluate the proposal meaningfully, we have to answer two > questions: does ToFU make such interventions more or less likely, and > does it make them appreciably worse or better? > > 1) if not "trusted" (on first use or any use where we haven't > cached trust), ask the user whether they want a one-time override > or to keep the cert > > I'm sorry, but this is nonsense. You should never ask a user to > trust a cert--they are not equipped to make this decision, and you are > training them to be susceptible to malware. Either you have a basis > for trusting a cert, or you do not. If you do not, then you simply > don't trust it. Full stop. You do not ask the user whether to trust it. Presumably you're aware that this is how most systems do things, including web browsers, operating systems, etc? Are you arguing that you should always pay for network/OS "fu" to have someone help when this happens? That's not the how the real world already works. Joe --------------F5486D346C7CE636F857FD84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 9/1/2016 3:57 PM, Ted Lemon wrote:
On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch <touch@isi.edu> wrote:

TOFU is worse thank doing nothing because it requires user intervention to override when it's wrong.

It's as if you haven't read anything I've written.
You said two things:

1) "When a client connects to a link to which it has never previously connected, it will pick a DHCP server.   This DHCP server may or may not be a rogue DHCP server.   If it is a rogue DHCP server, the client is potentially screwed, and the end user will potentially notice this, depending on what sort of attach the rogue server is attempting.   The user can detect this and say "don't use this server anymore."" and later "I don't think there's any point in re-keying in a typical case, and I don't think there's any point in interacting with the user in a typical case.   There should not be security pop-ups.   If the network isn't working, the user will stop using it; that's the UX we want."

You also then said:
2) "If the "wrong" server is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to connect to a different network, or complain, and somebody with network fu will help you.   I think this is better than popping up security warnings, although I could be convinced otherwise.   A "try to fix my network" button could help as well--if someone is pressing it, maybe the server the client bonded to sucks.   Heuristics for detecting filtered connections could also work."

That's what I disagree with. Did I miss another post where you said something different?

IMO, there is an existing UI for handling this - to make the user aware of the TOFU case when it first occurs and ask for them to confirm whether they want to continue that trust or make it a one-time case. I.e., trust-now or on first use (TNOOFU), not just TOFU.


The reality is that when a user gets attacked by a rogue server, there is _always_ going to have to be user intervention.

Your version of user intervention and mine are different. You say simply "stop using the network". IMO, investing in the trust should be opt-im and explicit, not silent and automatic. Those are very different things.

  To evaluate the proposal meaningfully, we have to answer two questions: does ToFU make such interventions more or less likely, and does it make them appreciably worse or better?

    1) if not "trusted" (on first use or any use where we haven't cached trust), ask the user whether they want a one-time override or to keep the cert

I'm sorry, but this is nonsense.   You should never ask a user to trust a cert--they are not equipped to make this decision, and you are training them to be susceptible to malware.   Either you have a basis for trusting a cert, or you do not.   If you do not, then you simply don't trust it.  Full stop.   You do not ask the user whether to trust it.

Presumably you're aware that this is how most systems do things, including web browsers, operating systems, etc?

Are you arguing that you should always pay for network/OS "fu" to have someone help when this happens? That's not the how the real world already works.

Joe


--------------F5486D346C7CE636F857FD84-- From nobody Thu Sep 1 16:24:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BEB12D642 for ; Thu, 1 Sep 2016 16:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXy8IeiwoTcZ for ; Thu, 1 Sep 2016 16:23:57 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2376312D08E for ; Thu, 1 Sep 2016 16:23:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 68E961E72; Thu, 1 Sep 2016 23:23:56 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXMvWlCUozwy; Thu, 1 Sep 2016 23:23:56 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id F15A6C37; Thu, 1 Sep 2016 23:23:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 1 Sep 2016 19:23:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 23:23:59 -0000 > On Sep 1, 2016, at 7:02 PM, Ted Lemon wrote: >=20 > I'm going to give a somewhat unhelpful response, but the question that = pops to mine when you suggest that is, why don't we also do this for web = pages and for ssh? Because of historical designs and implementations. Which shouldn't = *prevent* us from doing the Right Thing moving forward. Network access has to bootstrap from somewhere. Right now, without = 802.1X, it's largely "la la la, I trust everyone". I submit that this = is a bad idea. Securing DHCP helps. But wouldn't it be nice to know that the = organization who granted you network access also granted you network = credentials? i.e. IP addresses? No? Why not? > That is, if you have 802.1x, why not use that security association = to authenticate ssh servers? The ABFAB working group leverages the AAA infrastructure to = authenticate users to SSH servers. Which is pretty darned similar. But to answer your question, the answer is simple. Bootstrapping = network access is not the same as accessing services on the net. > I think the answer is clearly that you would never do this; I can = see why you might think that it would be okay to do it for DHCP, but I = still think it's worth trying to explicitly answer the question. I find it worth trying to explain what problem you're trying to solve, = instead of posing riddles. In the case of 802.1X, we have secure network access. The network = proves it's identity to the end device, and they securely exchange = credentials. Once that's done, all that information is forgotten, and = we do DHCP. No authentication. No security. This draft helps do = secure DHCP, but there's no tie between network access (ethernet) and = network access (IP addresses). Uh... really? Is this really the *best* we can do? > In any case, from my perspective, what you're suggesting sounds like = something that would never be deployed. When and how effectively is = 802.1x deployed? Everywhere. 3G, Wifi, wired, enterprise, ISP, telco... > Are those the same sites that we are trying to help with DHCP = authentication? I would suggest yes. > If you have 802.1x, why aren't you doing DHCP filtering? Sure. But DHCP filtering happens in the network. There's no way for = the DHCP client to know that DHCP filtering is happening. Why not *explicit* security? > I don't think this is an important use case, but if it is, a = pre-shared cert will solve the problem, and you don't want to use ToFU = anyway. Hmm... if you say so. Alan DeKok. From nobody Thu Sep 1 16:31:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4712B03B for ; Thu, 1 Sep 2016 16:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixk8uUpjzwW3 for ; Thu, 1 Sep 2016 16:31:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E1E12D08E for ; Thu, 1 Sep 2016 16:31:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfbRz-0006Or-Rp; Thu, 01 Sep 2016 23:31:16 +0000 Date: Fri, 02 Sep 2016 08:31:44 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: saag@ietf.org Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 23:31:19 -0000 > The reality is that when a user gets attacked by a rogue server, there > is _always_ going to have to be user intervention. not just on attack. if you gmobd, the first time the client meets any new server, it needs to ask the user if server with cert should be trusted. and, similarly to ssh, you probably want it to pin that credential. randy From nobody Thu Sep 1 18:30:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6CF12D72A for ; Thu, 1 Sep 2016 18:30:29 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQX_bMuSM7_6 for ; Thu, 1 Sep 2016 18:30:27 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74F812D67C for ; Thu, 1 Sep 2016 18:30:26 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id e198so39575919lfb.2 for ; Thu, 01 Sep 2016 18:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKxRd+fqmlq0uE82Lhw9xExuRsugOWDevIsFD0XXRds=; b=jPirCAuk7MalbQuzXJ9//QMO1g3pXUNMQuwRGgo/1zXiaqj4aE5wO/reV/5pwDFKpm NvHy5fHFd8pbOGWKkQn8leuW56/B0QDKOjPOXntVm0EtF1mjrRw5g2dDG9eiycenDEMB K/sz28B4MnXyXDzRNgdRIfNwWfjXSPispgTnfcDSmNjoGVasmCWEYz7x1so+phispTFM 3zGw/ertrBYQZhdbRwiLI4x2OZwyFBGWLKgJh+wOg1bm1830XcryKCFKzfDc6KdJcUo7 MzT8YslXz2DE17ZvQhLiv8sJueZai24ZIMvIyZQn4jqH83joMJq5kQ9G5hLNXCAW9rVy PA3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DKxRd+fqmlq0uE82Lhw9xExuRsugOWDevIsFD0XXRds=; b=bsSLzL8G7Siz1z4HkEU06SJqU/iBKz2Y9qVPWHE6Z5bMpEDtvIJ3lD9Zue3kQp9xdl yO+e+qBaEkgSyXhOqWiEkz344CPZJaZjSG9788+eRrLYJCOI2OZfREu8B+kytuJz7SkA BXs/1lQemNpQSjOVggmsa9xKCuHsedGKhSjuIfoWeUI2YLyzrBFC3yIY4vrCbuSh6b+k W6ui0zHoBvzwB8VUEvdRhCFaLANIswDrD4io2Byd4ekKUo7dUu0RicYP77NnifYVOBfC TX2EdlO1uDPfDwuZ6kIQv+zV3u3XJqX0FvpmXsXoex4V+NvhHe7nRn5C4Ce5hFVA7psf wq+w== X-Gm-Message-State: AE9vXwM3b9tGmUDJyNtSxqbwNDlsbpl2vn8JsXu+bmrxLzrMHBLsCFp+5bS4mfTxNiv20bzd3V8UIBENzE427Q== X-Received: by 10.25.131.150 with SMTP id f144mr5287418lfd.53.1472779824786; Thu, 01 Sep 2016 18:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 18:29:44 -0700 (PDT) In-Reply-To: <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> From: Ted Lemon Date: Thu, 1 Sep 2016 21:29:44 -0400 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113f20b84a0512053b7c46f6 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 01:30:30 -0000 --001a113f20b84a0512053b7c46f6 Content-Type: text/plain; charset=UTF-8 I am arguing that you are far better off being unable to use something that is not secure than you are being trained by software written by people who should know better to behave in a way that almost guarantees that you will eventually be victimized. Any UI asking a user to make a decision about trust should be crafted in such a way that it doesn't train the user to do things that will screw them later. We fail horribly at this, in general. Users aren't stupid, but it will never be the case that they will be able to figure out how to make trust decisions unless we really take seriously how we present those decisions to them, and do not present decisions to them that they will not be able to make correctly when an attacker asks them to do the same thing. On Thu, Sep 1, 2016 at 7:12 PM, Joe Touch wrote: > > > On 9/1/2016 3:57 PM, Ted Lemon wrote: > > On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch wrote: > >> TOFU is worse thank doing nothing because it requires user intervention >> to override when it's wrong. >> > It's as if you haven't read anything I've written. > > > > *You said two things: 1) "*When a client connects to a link to which it > has never previously connected, it will pick a DHCP server. This DHCP > server may or may not be a rogue DHCP server. If it is a rogue DHCP > server, the client is potentially screwed, and the end user will > potentially notice this, depending on what sort of attach the rogue server > is attempting. The user can detect this and say "don't use this server > anymore."" and later "I don't think there's any point in re-keying in a > typical case, and I don't think there's any point in interacting with the > user in a typical case. There should not be security pop-ups. If the > network isn't working, the user will stop using it; that's the UX we want." > > You also then said: > 2) "If the "wrong" server is giving you a working connection, you're no > worse off than you were without ToFU; if it's not, then you're presumably > going to connect to a different network, or complain, and somebody with > network fu will help you. I think this is better than popping up security > warnings, although I could be convinced otherwise. A "try to fix my > network" button could help as well--if someone is pressing it, maybe the > server the client bonded to sucks. Heuristics for detecting filtered > connections could also work." > > That's what I disagree with. Did I miss another post where you said > something different? > > IMO, there is an existing UI for handling this - to make the user aware of > the TOFU case when it first occurs and ask for them to confirm whether they > want to continue that trust or make it a one-time case. I.e., trust-now or > on first use (TNOOFU), not just TOFU. > > > The reality is that when a user gets attacked by a rogue server, there is > _always_ going to have to be user intervention. > > > Your version of user intervention and mine are different. You say simply > "stop using the network". IMO, investing in the trust should be opt-im and > explicit, not silent and automatic. Those are very different things. > > To evaluate the proposal meaningfully, we have to answer two questions: > does ToFU make such interventions more or less likely, and does it make > them appreciably worse or better? > >> 1) if not "trusted" (on first use or any use where we haven't cached >> trust), ask the user whether they want a one-time override or to keep the >> cert >> > I'm sorry, but this is nonsense. You should never ask a user to trust a > cert--they are not equipped to make this decision, and you are training > them to be susceptible to malware. Either you have a basis for trusting a > cert, or you do not. If you do not, then you simply don't trust it. Full > stop. You do not ask the user whether to trust it. > > > Presumably you're aware that this is how most systems do things, including > web browsers, operating systems, etc? > > Are you arguing that you should always pay for network/OS "fu" to have > someone help when this happens? That's not the how the real world already > works. > > Joe > > > --001a113f20b84a0512053b7c46f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am arguing that you are far better off being unable to u= se something that is not secure than you are being trained by software writ= ten by people who should know better to behave in a way that almost guarant= ees that you will eventually be victimized. =C2=A0 Any UI asking a user to = make a decision about trust should be crafted in such a way that it doesn&#= 39;t train the user to do things that will screw them later. =C2=A0 We fail= horribly at this, in general. =C2=A0 Users aren't stupid, but it will = never be the case that they will be able to figure out how to make trust de= cisions unless we really take seriously how we present those decisions to t= hem, and do not present decisions to them that they will not be able to mak= e correctly when an attacker asks them to do the same thing.

On Thu, Sep 1, 2016 at 7:1= 2 PM, Joe Touch <touch@isi.edu> wrote:
=20 =20 =20



On 9/1/2016 3:57 PM, Ted Lemon wrote:
On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch <touch@isi.edu> wrote:

TOFU is worse thank doing nothing because it requires user intervention to override when it's wrong.

It's as if you haven't read anything I've writ= ten.
You said two things:

1) "When a client connects to a link to which it has never previously connected, it will pick a DHCP server. =C2=A0 This DHCP serv= er may or may not be a rogue DHCP server. =C2=A0 If it is a rogue DHCP server, the client is potentially screwed, and the end user will potentially notice this, depending on what sort of attach the rogue server is attempting. =C2=A0 The user can detect this and say "don= 't use this server anymore."" and later "I don't think ther= e's any point in re-keying in a typical case, and I don't think there's any poin= t in interacting with the user in a typical case. =C2=A0 There should not be security pop-ups. =C2=A0 If the network isn't working, the user wil= l stop using it; that's the UX we want."

You also then said:
2) "If the "wrong" serv= er is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to co= nnect to a different network, or complain, and somebody with network fu will help you. =C2=A0 I think this is better than popping up security warnings, although I could be convinced otherwise. =C2=A0 A "try= to fix my network" button could help as well--if someone is pressing it= , maybe the server the client bonded to sucks. =C2=A0 Heuristics for detecting filtered connections could also work."

That's what I disagree with. Did I miss another post where you said something different?

IMO, there is an existing UI for handling this - to make the user aware of the TOFU case when it first occurs and ask for them to confirm whether they want to continue that trust or make it a one-time case. I.e., trust-now or on first use (TNOOFU), not just TOFU.


The reality is that when a user gets attacked by a rogue server, there is _always_ going to have to be user intervention.

Your version of user intervention and mine are different. You say simply "stop using the network". IMO, investing in the trust = should be opt-im and explicit, not silent and automatic. Those are very different things.

=C2=A0 To evaluate the proposal meaningfully, we have to answer two questions: does ToFU make such interventions more or less likely, and does it make them appreciably worse or better?

=C2=A0 =C2=A0 1) if not "trusted" (on first us= e or any use where we haven't cached trust), ask the user whether they want a one-time override or to keep the cert

I'm sorry, but this is nonsense. =C2=A0 You should nev= er ask a user to trust a cert--they are not equipped to make this decision, and you are training them to be susceptible to malware. =C2=A0 Either you have a basis for trusting a cert, = or you do not. =C2=A0 If you do not, then you simply don't t= rust it.=C2=A0 Full stop. =C2=A0 You do not ask the user whether t= o trust it.

 Presumably you're aware that this is how most systems do things, including web browsers, operating systems, etc?

Are you arguing that you should always pay for network/OS "fu"= ; to have someone help when this happens? That's not the how the real world already works.

Joe



--001a113f20b84a0512053b7c46f6-- From nobody Thu Sep 1 18:46:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD9212DB46 for ; Thu, 1 Sep 2016 18:46:09 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVxUrOobR8gm for ; Thu, 1 Sep 2016 18:46:07 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5F412DB3D for ; Thu, 1 Sep 2016 18:46:06 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g62so73299686lfe.3 for ; Thu, 01 Sep 2016 18:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1ClRIuc8BakiD+xS2hfUVAf0/g6NT8HEsEnQXvBwPAM=; b=l6w9vdn5f6hbRmcGyu5U16Q7UTbTvZ9OBUjFPPmcMCj4D/Ne8OiFgXkon57nLg7iwD 8cF2D7DpVyZp1pduqnmWiaBsJTqMJTp1/qify3r/LAc6ceNmDtdUmshpvl59HmD1V7kB vt1hkk8VNtlkGHrwpwnEg0kVS6P8ae0dOlVhKeqFMxExwyxuTVTaRA5KxQiQQTl/Zvh/ WBLVA2zIoCbbLhsAD0RBO1CdBH0v5m+vBs3tF19lmocK+AQMx2ABl5jpsy0GSC+FW/FB bNshl6LfRxQvbae0tv9m25Bd2TMT9MTaS/4UMpFUu2o7yxeFydn+HYzdQFEcdKU3MF7E Ce+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ClRIuc8BakiD+xS2hfUVAf0/g6NT8HEsEnQXvBwPAM=; b=JMKPnQ/FLhX1maVZAtPu+l924J5ijpqEwksJdatKNI5MtyQTZnei6nKOVQ3ZgFatTb UfejE/mm16yz9xH9/TqVCDDBNQsaBKquafw8dyjzoztqZ9f6+IntgtLWU1TtvB6AEXj9 Ehmv495Dag2qXjMKfaMwGNz+RH6VVgdo3UODLuNy01dPQv1arqV2uk7Xc1Dy/talLgTa X2VK2dQvYlo9ibYqaHO8+Qw8gMLB6Gc2GaN2OuaP4TF+5I1uKa5OMz7m+4aPcueOkJBi xjlETSqQmZc3d3FOZdvJvVOSeUJMyEnUn94gcfZaSkCOZh4v7ottBN+lUSr6eWUdTSlR d+0Q== X-Gm-Message-State: AE9vXwMEz0R+Pcs4HfUqSyDkU6gKiOlA0nZcx5ETbMqk8b76FP+ia47Y0mDeE2SvFCDuOFs/gYa5X7OBtEsNIA== X-Received: by 10.25.42.207 with SMTP id q198mr5058247lfq.181.1472780764686; Thu, 01 Sep 2016 18:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 18:45:23 -0700 (PDT) In-Reply-To: References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> From: Ted Lemon Date: Thu, 1 Sep 2016 21:45:23 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a11411dba4fb82f053b7c7ec0 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 01:46:09 -0000 --001a11411dba4fb82f053b7c7ec0 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 1, 2016 at 7:23 PM, Alan DeKok wrote: > > > On Sep 1, 2016, at 7:02 PM, Ted Lemon wrote: > > > > I'm going to give a somewhat unhelpful response, but the question that > pops to mine when you suggest that is, why don't we also do this for web > pages and for ssh? > > Because of historical designs and implementations. Which shouldn't > *prevent* us from doing the Right Thing moving forward. > No, it's because it would be a bad idea. You are trusting the wrong entity if you allow 802.1x to assure you that you are talking to your bank. > Network access has to bootstrap from somewhere. Right now, without > 802.1X, it's largely "la la la, I trust everyone". I submit that this is a > bad idea. > Sure, for contexts in which the 802.1x functional model works. > Securing DHCP helps. But wouldn't it be nice to know that the > organization who granted you network access also granted you network > credentials? i.e. IP addresses? > There are several unwarranted assumptions in this question: - you've been explicitly, not implicitly, granted access to the network - the operator of layer 2 is also the operator of the DHCP server In situations where both of these assumptions are true, yes, you might as well use the same keys to authenticate layer 2 and layer 3. > > That is, if you have 802.1x, why not use that security association to > authenticate ssh servers? > > The ABFAB working group leverages the AAA infrastructure to authenticate > users to SSH servers. Which is pretty darned similar. > This is a fascinating collection of work--I just peeked at the arch document. That said, I can't imagine a situation in which I would find myself using it. I believe that such situations exist, but my point is that this is not a good general approach--it is solving a very constrained problem. > But to answer your question, the answer is simple. Bootstrapping > network access is not the same as accessing services on the net. > Yup. I think we agree that when it's possible to bootstrap both layer 2 and layer 3 using the same keying infrastructure, that's the right thing to do. > I find it worth trying to explain what problem you're trying to solve, > instead of posing riddles. > I thought I already did that. It was not my intention to be annoying--I'm just trying to figure out if the reasoning I presented made sense, and I'm getting answers that don't really seem to connect to that. In the case of 802.1X, we have secure network access. The network > proves it's identity to the end device, and they securely exchange > credentials. Once that's done, all that information is forgotten, and we > do DHCP. No authentication. No security. This draft helps do secure > DHCP, but there's no tie between network access (ethernet) and network > access (IP addresses). > DHCP has for a long time had the ability to do this using pre-shared keys, which would be supported by AAA and would work with 802.1x. There are zero deployments of the pre-shared key solution. The reason is that it doesn't really make sense in the DHCP use model. > In any case, from my perspective, what you're suggesting sounds like > something that would never be deployed. When and how effectively is > 802.1x deployed? > > Everywhere. 3G, Wifi, wired, enterprise, ISP, telco... > I never use 802.1x at all in my daily life. The only time I've ever seen it deployed is at IETF and at my company's office in Redwood City, where, I hasten to add, it works so poorly that I sometimes use the guest network, or the wired network, which does not use 802.1x. > > Are those the same sites that we are trying to help with DHCP > authentication? > > I would suggest yes. > I think those are very much the exception in terms of real-world DHCP usage. In order to justify the rather massive effort that would be involved in making this work for DHCP, the first question I would ask is, do you actually need to authenticate the client again if you are using 802.1x? I think the answer is a resounding no. I think if the IETF developed a solution to this problem, exactly zero people would deploy it. If you think that's not the case, do you know of people who are clamoring for this feature? > > If you have 802.1x, why aren't you doing DHCP filtering? > > Sure. But DHCP filtering happens in the network. There's no way for > the DHCP client to know that DHCP filtering is happening. > > Why not *explicit* security? > Sure. Use the same cert to identify both the 802.1x server and the DHCP server. Done. You don't need to use ToFU for this use case, and I don't think you should. --001a11411dba4fb82f053b7c7ec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 1, 2016 at 7:23 PM, Alan DeKok <aland@deployingradius.com<= /a>> wrote:
> On Sep 1, 2016, at 7:02 PM, Ted Lemon <mellon@fugue.com> wrote:
>
> I'm going to give a somewhat unhelpful response, but the question = that pops to mine when you suggest that is, why don't we also do this f= or web pages and for ssh?

=C2=A0 Because of historical designs and implementations.=C2=A0 Whic= h shouldn't *prevent* us from doing the Right Thing moving forward.
=

No, it's because it would be a bad ide= a. =C2=A0 You are trusting the wrong entity if you allow 802.1x to assure y= ou that you are talking to your bank.
=C2=A0
=C2=A0 Network access has to bootstrap from somewhere.=C2= =A0 Right now, without 802.1X, it's largely "la la la, I trust eve= ryone".=C2=A0 I submit that this is a bad idea.
<= br>
Sure, for contexts in which the 802.1x functional model works= .
=C2=A0
=C2=A0 Securing DHCP= helps.=C2=A0 But wouldn't it be nice to know that the organization who= granted you network access also granted you network credentials?=C2=A0 i.e= . IP addresses?

There are several unwar= ranted assumptions in this question:
  • you've been expl= icitly, not implicitly, granted access to the network
  • the operator = of layer 2 is also the operator of the DHCP server
In situations w= here both of these assumptions are true, yes, you might as well use the sam= e keys to authenticate layer 2 and layer 3.
=C2=A0
>=C2=A0 =C2=A0That is, if you= have 802.1x, why not use that security association to authenticate ssh ser= vers?

=C2=A0 The ABFAB working group leverages the AAA infrastructure to a= uthenticate users to SSH servers.=C2=A0 Which is pretty darned similar.
=

This is a fascinating collection of work--= I just peeked at the arch document. =C2=A0 That said, I can't imagine a= situation in which I would find myself using it. =C2=A0 I believe that suc= h situations exist, but my point is that this is not a good general approac= h--it is solving a very constrained problem.
=C2=A0
=C2=A0 But to answer your question, the answer is simple.=C2=A0 Bootstrappi= ng network access is not the same as accessing services on the net.

Yup. =C2=A0 I think we agree that when it'= s possible to bootstrap both layer 2 and layer 3 using the same keying infr= astructure, that's the right thing to do.
=C2=A0
=C2=A0 I find it worth trying to explain what probl= em you're trying to solve, instead of posing riddles.
<= div>
I thought I already did that. =C2=A0 It was not my inten= tion to be annoying--I'm just trying to figure out if the reasoning I p= resented made sense, and I'm getting answers that don't really seem= to connect to that.

=C2= =A0 In the case of 802.1X,=C2=A0 we have secure network access.=C2=A0 The n= etwork proves it's identity to the end device, and they securely exchan= ge credentials.=C2=A0 Once that's done, all that information is forgott= en, and we do DHCP.=C2=A0 No authentication.=C2=A0 No security.=C2=A0 This = draft helps do secure DHCP, but there's no tie between network access (= ethernet) and network access (IP addresses).

DHCP has for a long time had the ability to do this using pre-shared = keys, which would be supported by AAA and would work with 802.1x. =C2=A0 Th= ere are zero deployments of the pre-shared key solution. =C2=A0 The reason = is that it doesn't really make sense in the DHCP use model.
<= br>
> In any case, = from my perspective, what you're suggesting sounds like something that = would never be deployed.=C2=A0 =C2=A0When and how effectively is 802.1x dep= loyed?

=C2=A0 Everywhere.=C2=A0 3G, Wifi, wired, enterprise, ISP, telco...<= br>

I never use 802.1x at all in my daily l= ife. =C2=A0 The only time I've ever seen it deployed is at IETF and at = my company's office in Redwood City, where, I hasten to add, it works s= o poorly that I sometimes use the guest network, or the wired network, whic= h does not use 802.1x.
=C2=A0
>=C2=A0 =C2=A0Are those the same sites that we are trying to help with D= HCP authentication?

=C2=A0 I would suggest yes.

I th= ink those are very much the exception in terms of real-world DHCP usage.=C2= =A0 In order to justify the rather massive effort that would be involved in= making this work for DHCP, the first question I would ask is, do you actua= lly need to authenticate the client again if you are using 802.1x? =C2=A0 I= think the answer is a resounding no. =C2=A0 I think if the IETF developed = a solution to this problem, exactly zero people would deploy it. =C2=A0 If = you think that's not the case, do you know of people who are clamoring = for this feature?
=C2=A0
>=C2=A0 =C2=A0If you have 802.1x, why aren't you doing DHCP filterin= g?

=C2=A0 Sure.=C2=A0 But DHCP filtering happens in the network.=C2=A0 = There's no way for the DHCP client to know that DHCP filtering is happe= ning.

=C2=A0 Why not *explicit* security?

Sur= e. =C2=A0 Use the same cert to identify both the 802.1x server and the DHCP= server. =C2=A0 Done. =C2=A0 You don't need to use ToFU for this use ca= se, and I don't think you should.
--001a11411dba4fb82f053b7c7ec0-- From nobody Thu Sep 1 18:47:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2112D815 for ; Thu, 1 Sep 2016 18:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z26B_ffXcp4f for ; Thu, 1 Sep 2016 18:47:25 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5305712D74E for ; Thu, 1 Sep 2016 18:47:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id DA18DE2048; Thu, 1 Sep 2016 21:47:22 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 09940-01; Thu, 1 Sep 2016 21:47:18 -0400 (EDT) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 52118E2049; Thu, 1 Sep 2016 21:47:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1472780838; bh=9N6jxG61CnWeS+GfwbiCikUMhfk7tksApY7TzZfJi8Y=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=fWEEczvLx54bPAc6lkze1MEwCo7zhc3gniElLgv6Er9bC1y+m0Mz7kFY3C8fyaRoL 0xpcXICIoYCeM1Cjsj3nIKj0dZ1VEBXfZzI3KVKHNWXPIb3ljpP1s6F8vNI8ssxn/W KHq/Dh5Hoxkm/vzNNjQAbqtDK6sUzY42rpX7XH+k= Received: from 2001:470:e448:2:ea2a:eaff:fe7d:235 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Thu, 1 Sep 2016 21:47:18 -0400 Message-ID: <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> Date: Thu, 1 Sep 2016 21:47:18 -0400 From: "Derek Atkins" To: "Ted Lemon" User-Agent: SquirrelMail/1.4.22-14.fc20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 01:47:27 -0000 I disagree that users are not stupid. But then again software that forces a security choice is just as stupid. For a Starbucks environment I can see a placard at the desk that has the fingerprint of the local DHCP server. So if the software says "do you trust this?" (ala SSH) then there is some reason to believe that users would have something to compare it to. For my home network, I know what it should be, and I can tell my guests. The issue would be locations where the admins don't know or don't care. I think SSH works pretty well in general. But it's definitely a PITA when a server gets re-keyed, and I'm a pretty technical user. I don't think an average user would know what to do, and SSH certainly doesn't have a button to accept the new key when it's been changed. It just gives a pretty large error and quits. I don't know what UI a ToFU DHCP client could provide that would be better.. but SSH is definitely not the epitome of UI. -derek On Thu, September 1, 2016 9:29 pm, Ted Lemon wrote: > I am arguing that you are far better off being unable to use something > that > is not secure than you are being trained by software written by people who > should know better to behave in a way that almost guarantees that you will > eventually be victimized. Any UI asking a user to make a decision about > trust should be crafted in such a way that it doesn't train the user to do > things that will screw them later. We fail horribly at this, in general. > Users aren't stupid, but it will never be the case that they will be > able > to figure out how to make trust decisions unless we really take seriously > how we present those decisions to them, and do not present decisions to > them that they will not be able to make correctly when an attacker asks > them to do the same thing. > > On Thu, Sep 1, 2016 at 7:12 PM, Joe Touch wrote: > >> >> >> On 9/1/2016 3:57 PM, Ted Lemon wrote: >> >> On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch wrote: >> >>> TOFU is worse thank doing nothing because it requires user intervention >>> to override when it's wrong. >>> >> It's as if you haven't read anything I've written. >> >> >> >> *You said two things: 1) "*When a client connects to a link to which it >> has never previously connected, it will pick a DHCP server. This DHCP >> server may or may not be a rogue DHCP server. If it is a rogue DHCP >> server, the client is potentially screwed, and the end user will >> potentially notice this, depending on what sort of attach the rogue >> server >> is attempting. The user can detect this and say "don't use this server >> anymore."" and later "I don't think there's any point in re-keying in a >> typical case, and I don't think there's any point in interacting with >> the >> user in a typical case. There should not be security pop-ups. If the >> network isn't working, the user will stop using it; that's the UX we >> want." >> >> You also then said: >> 2) "If the "wrong" server is giving you a working connection, you're no >> worse off than you were without ToFU; if it's not, then you're >> presumably >> going to connect to a different network, or complain, and somebody with >> network fu will help you. I think this is better than popping up >> security >> warnings, although I could be convinced otherwise. A "try to fix my >> network" button could help as well--if someone is pressing it, maybe the >> server the client bonded to sucks. Heuristics for detecting filtered >> connections could also work." >> >> That's what I disagree with. Did I miss another post where you said >> something different? >> >> IMO, there is an existing UI for handling this - to make the user aware >> of >> the TOFU case when it first occurs and ask for them to confirm whether >> they >> want to continue that trust or make it a one-time case. I.e., trust-now >> or >> on first use (TNOOFU), not just TOFU. >> >> >> The reality is that when a user gets attacked by a rogue server, there >> is >> _always_ going to have to be user intervention. >> >> >> Your version of user intervention and mine are different. You say simply >> "stop using the network". IMO, investing in the trust should be opt-im >> and >> explicit, not silent and automatic. Those are very different things. >> >> To evaluate the proposal meaningfully, we have to answer two >> questions: >> does ToFU make such interventions more or less likely, and does it make >> them appreciably worse or better? >> >>> 1) if not "trusted" (on first use or any use where we haven't >>> cached >>> trust), ask the user whether they want a one-time override or to keep >>> the >>> cert >>> >> I'm sorry, but this is nonsense. You should never ask a user to trust >> a >> cert--they are not equipped to make this decision, and you are training >> them to be susceptible to malware. Either you have a basis for >> trusting a >> cert, or you do not. If you do not, then you simply don't trust it. >> Full >> stop. You do not ask the user whether to trust it. >> >> >> Presumably you're aware that this is how most systems do things, >> including >> web browsers, operating systems, etc? >> >> Are you arguing that you should always pay for network/OS "fu" to have >> someone help when this happens? That's not the how the real world >> already >> works. >> >> Joe >> >> >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Sep 1 18:48:23 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718FA12DB43 for ; Thu, 1 Sep 2016 18:48:22 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gcCoHgKz0T9 for ; Thu, 1 Sep 2016 18:48:21 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F3E12D74E for ; Thu, 1 Sep 2016 18:48:20 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id g62so73323836lfe.3 for ; Thu, 01 Sep 2016 18:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BCRYaQXkVBUAzb2Ua0XYIvFRhMHfPHFPukz9RLsbp5M=; b=uPVw82z7dU8WHH5A18zxrqbXrR15S51rCoqmLTxO3sU53D75SdJcRmS9IX5TrpD1d5 eYqFTDFipf+FGAyRYsGFFdOA6tSwE21+3L2JqFgAvNsASc/BTfeYeXgonsLq7S+sQmHb qJNOGR1np+zPbwNGNMzBDKkAwJGf5Jz2wBe2SE5E884nmxGFO9wDIRA1pyffUkNTA+ui ACpPZiJwsbHOWWYmpdK2C35VfZXfpwUYyvIV1+/p8bKVtxgKFNM0KCOjQBGHRRgj/Nuk Rr82AWuZz9MiYWZBYxUWe/srOs2qayrWGri4bIsM4GF0eKiXHpW7zLUZ7cTdgj8spjJP wo9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BCRYaQXkVBUAzb2Ua0XYIvFRhMHfPHFPukz9RLsbp5M=; b=iJcdVGoJVwsAG4/WwXDkw7nBqFfQPfAUsudLDxtx6TKewQ25Xi2B5JNeD8EZ/ViD8X 6dTmwcXQ9/Bi3RHgSvcNrRCqKoQFTWWizNjV5cyz/gHT+5dWuVGAYGsH20KhcLi2R6RH R7QMoulCuMiKVcJKnbYwg+7SztTbzIWRuDUBVTcs1NOsGiNrCds7vNq7ct8s9zzYk4j/ cAUoZXv23i7yS8SIrSpTg7qdjvu6fn1y+oNBYCmbZ+73VDQ89I/6Z0JvIYo4v0f+5DTj mmds58khFsty/Y3/SDJerFigCjcd8+A9NPxGTQ1sWXA98EIa5U01CvH+IW+eZoPTaoEW S+HQ== X-Gm-Message-State: AE9vXwMXzCx7U4J2zVDPOisKZBqDqrXlPlJTV0XNV+eFDHNnGcqFtCW3lCEQEGa52IO3lcZVvlXgBU9vhZbfXw== X-Received: by 10.46.69.9 with SMTP id s9mr2638170lja.7.1472780898894; Thu, 01 Sep 2016 18:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 1 Sep 2016 18:47:38 -0700 (PDT) In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> From: Ted Lemon Date: Thu, 1 Sep 2016 21:47:38 -0400 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a114b05f04f8c41053b7c86c1 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 01:48:22 -0000 --001a114b05f04f8c41053b7c86c1 Content-Type: text/plain; charset=UTF-8 No, you explicitly do not need to ask the user whether to trust a specific server. That is not the use case for ToFU DHCPv6. For that, you just install a pre-shared cert. I guess you could do the cert installation using a ToFU-like UI, but I think that's a bad idea--it trains the user to make leaps of faith that I don't think are warrented. On Thu, Sep 1, 2016 at 7:31 PM, Randy Bush wrote: > > The reality is that when a user gets attacked by a rogue server, there > > is _always_ going to have to be user intervention. > > not just on attack. if you gmobd, the first time the client meets any > new server, it needs to ask the user if server with cert should > be trusted. and, similarly to ssh, you probably want it to pin that > credential. > > randy > --001a114b05f04f8c41053b7c86c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, you explicitly do not need to ask the user whether to = trust a specific server. =C2=A0 That is not the use case for ToFU DHCPv6. = =C2=A0 For that, you just install a pre-shared cert. =C2=A0 I guess you cou= ld do the cert installation using a ToFU-like UI, but I think that's a = bad idea--it trains the user to make leaps of faith that I don't think = are warrented.

On Thu, Sep 1, 2016 at 7:31 PM, Randy Bush <randy@psg.com> wr= ote:
> The reality is= that when a user gets attacked by a rogue server, there
> is _always_ going to have to be user intervention.

not just on attack.=C2=A0 if you gmobd, the first time the client me= ets any
new server, it needs to ask the user if server with cert <blah> shoul= d
be trusted.=C2=A0 and, similarly to ssh, you probably want it to pin that credential.

randy

--001a114b05f04f8c41053b7c86c1-- From nobody Thu Sep 1 21:33:56 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5731312D18A for ; Thu, 1 Sep 2016 21:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZec6f-aUoEH for ; Thu, 1 Sep 2016 21:33:53 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF1E12B02D for ; Thu, 1 Sep 2016 21:33:53 -0700 (PDT) Received: from [128.9.184.156] ([128.9.184.156]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u824XEkA006668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Sep 2016 21:33:15 -0700 (PDT) To: Ted Lemon References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> From: Joe Touch Message-ID: <72fcc068-c825-e545-d5dd-475c71cacd32@isi.edu> Date: Thu, 1 Sep 2016 21:33:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2727CD8C87AAF79E5D7BAD84" X-MailScanner-ID: u824XEkA006668 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 04:33:55 -0000 This is a multi-part message in MIME format. --------------2727CD8C87AAF79E5D7BAD84 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/1/2016 6:29 PM, Ted Lemon wrote: > I am arguing that you are far better off being unable to use something > that is not secure than you are being trained by software written by > people who should know better to behave in a way that almost > guarantees that you will eventually be victimized. Any UI asking a > user to make a decision about trust should be crafted in such a way > that it doesn't train the user to do things that will screw them > later. We fail horribly at this, in general. Users aren't stupid, > but it will never be the case that they will be able to figure out how > to make trust decisions unless we really take seriously how we present > those decisions to them, and do not present decisions to them that > they will not be able to make correctly when an attacker asks them to > do the same thing. I understand your position, but disagree exactly because users have many years of experience with the counterexample for matters that have much more direct consequences - namely, Internet commerce. You asked my position, and that's it. I appreciate that we disagree. Joe > > On Thu, Sep 1, 2016 at 7:12 PM, Joe Touch > wrote: > > > > On 9/1/2016 3:57 PM, Ted Lemon wrote: >> On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch > > wrote: >> >> TOFU is worse thank doing nothing because it requires user >> intervention to override when it's wrong. >> >> It's as if you haven't read anything I've written. > /You said two things: > > 1) "/When a client connects to a link to which it has never > previously connected, it will pick a DHCP server. This DHCP > server may or may not be a rogue DHCP server. If it is a rogue > DHCP server, the client is potentially screwed, and the end user > will potentially notice this, depending on what sort of attach the > rogue server is attempting. The user can detect this and say > "don't use this server anymore."" and later "I don't think there's > any point in re-keying in a typical case, and I don't think > there's any point in interacting with the user in a typical case. > There should not be security pop-ups. If the network isn't > working, the user will stop using it; that's the UX we want." > > You also then said: > 2) "If the "wrong" server is giving you a working connection, > you're no worse off than you were without ToFU; if it's not, then > you're presumably going to connect to a different network, or > complain, and somebody with network fu will help you. I think > this is better than popping up security warnings, although I could > be convinced otherwise. A "try to fix my network" button could > help as well--if someone is pressing it, maybe the server the > client bonded to sucks. Heuristics for detecting filtered > connections could also work." > > That's what I disagree with. Did I miss another post where you > said something different? > > IMO, there is an existing UI for handling this - to make the user > aware of the TOFU case when it first occurs and ask for them to > confirm whether they want to continue that trust or make it a > one-time case. I.e., trust-now or on first use (TNOOFU), not just > TOFU. > > // >> >> The reality is that when a user gets attacked by a rogue server, >> there is _always_ going to have to be user intervention. > > Your version of user intervention and mine are different. You say > simply "stop using the network". IMO, investing in the trust > should be opt-im and explicit, not silent and automatic. Those are > very different things. > >> To evaluate the proposal meaningfully, we have to answer two >> questions: does ToFU make such interventions more or less likely, >> and does it make them appreciably worse or better? >> >> 1) if not "trusted" (on first use or any use where we >> haven't cached trust), ask the user whether they want a >> one-time override or to keep the cert >> >> I'm sorry, but this is nonsense. You should never ask a user to >> trust a cert--they are not equipped to make this decision, and >> you are training them to be susceptible to malware. Either you >> have a basis for trusting a cert, or you do not. If you do not, >> then you simply don't trust it. Full stop. You do not ask the >> user whether to trust it. > > Presumably you're aware that this is how most systems do things, > including web browsers, operating systems, etc? > > Are you arguing that you should always pay for network/OS "fu" to > have someone help when this happens? That's not the how the real > world already works. > > Joe > > > --------------2727CD8C87AAF79E5D7BAD84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 9/1/2016 6:29 PM, Ted Lemon wrote:
I am arguing that you are far better off being unable to use something that is not secure than you are being trained by software written by people who should know better to behave in a way that almost guarantees that you will eventually be victimized.   Any UI asking a user to make a decision about trust should be crafted in such a way that it doesn't train the user to do things that will screw them later.   We fail horribly at this, in general.   Users aren't stupid, but it will never be the case that they will be able to figure out how to make trust decisions unless we really take seriously how we present those decisions to them, and do not present decisions to them that they will not be able to make correctly when an attacker asks them to do the same thing.

I understand your position, but disagree exactly because users have many years of experience with the counterexample for matters that have much more direct consequences - namely, Internet commerce.

You asked my position, and that's it. I appreciate that we disagree.

Joe



On Thu, Sep 1, 2016 at 7:12 PM, Joe Touch <touch@isi.edu> wrote:



On 9/1/2016 3:57 PM, Ted Lemon wrote:
On Thu, Sep 1, 2016 at 4:43 PM, Joe Touch <touch@isi.edu> wrote:

TOFU is worse thank doing nothing because it requires user intervention to override when it's wrong.

It's as if you haven't read anything I've written.
You said two things:

1) "When a client connects to a link to which it has never previously connected, it will pick a DHCP server.   This DHCP server may or may not be a rogue DHCP server.   If it is a rogue DHCP server, the client is potentially screwed, and the end user will potentially notice this, depending on what sort of attach the rogue server is attempting.   The user can detect this and say "don't use this server anymore."" and later "I don't think there's any point in re-keying in a typical case, and I don't think there's any point in interacting with the user in a typical case.   There should not be security pop-ups.   If the network isn't working, the user will stop using it; that's the UX we want."

You also then said:
2) "If the "wrong" server is giving you a working connection, you're no worse off than you were without ToFU; if it's not, then you're presumably going to connect to a different network, or complain, and somebody with network fu will help you.   I think this is better than popping up security warnings, although I could be convinced otherwise.   A "try to fix my network" button could help as well--if someone is pressing it, maybe the server the client bonded to sucks.   Heuristics for detecting filtered connections could also work."

That's what I disagree with. Did I miss another post where you said something different?

IMO, there is an existing UI for handling this - to make the user aware of the TOFU case when it first occurs and ask for them to confirm whether they want to continue that trust or make it a one-time case. I.e., trust-now or on first use (TNOOFU), not just TOFU.


The reality is that when a user gets attacked by a rogue server, there is _always_ going to have to be user intervention.

Your version of user intervention and mine are different. You say simply "stop using the network". IMO, investing in the trust should be opt-im and explicit, not silent and automatic. Those are very different things.

  To evaluate the proposal meaningfully, we have to answer two questions: does ToFU make such interventions more or less likely, and does it make them appreciably worse or better?

    1) if not "trusted" (on first use or any use where we haven't cached trust), ask the user whether they want a one-time override or to keep the cert

I'm sorry, but this is nonsense.   You should never ask a user to trust a cert--they are not equipped to make this decision, and you are training them to be susceptible to malware.   Either you have a basis for trusting a cert, or you do not.   If you do not, then you simply don't trust it.  Full stop.   You do not ask the user whether to trust it.

 Presumably you're aware that this is how most systems do things, including web browsers, operating systems, etc?

Are you arguing that you should always pay for network/OS "fu" to have someone help when this happens? That's not the how the real world already works.

Joe




--------------2727CD8C87AAF79E5D7BAD84-- From nobody Thu Sep 1 22:31:15 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE37612B050 for ; Thu, 1 Sep 2016 22:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4RTt42pGz5M for ; Thu, 1 Sep 2016 22:31:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FC1128B44 for ; Thu, 1 Sep 2016 22:31:12 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6ECC4284954 for ; Fri, 2 Sep 2016 05:31:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <72fcc068-c825-e545-d5dd-475c71cacd32@isi.edu> Date: Fri, 2 Sep 2016 01:31:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <72fcc068-c825-e545-d5dd-475c71cacd32@isi.edu> To: Security Area Advisory Group X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Security Area Advisory Group List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 05:31:15 -0000 > On Sep 2, 2016, at 12:33 AM, Joe Touch wrote: >=20 > I understand your position, but disagree exactly because users have = many years of experience with the counterexample for matters that have = much more direct consequences - namely, Internet commerce. One might note that Web-based e-commerce is squarely in the world of = mandatory, not opportunistic, security. And, in that space,=0D work still remains = to be done to design adequate security reporting UIs. For opportunistic security, look at SMTP, where Google's email = transparency report shows outbound TLS use varying from 84--87% and inbound from 76--80%. = But this uses unauthenticated TLS. And we're discussing TOFU, not anonymous = encryption. Pertinent RFC 7435 text: * The trust-on-first-use (TOFU) authentication approach assumes that an unauthenticated public key obtained on first contact (and retained for future use) will be good enough to secure future communication. TOFU-based protocols do not protect against an attacker who can hijack the first contact communication and require more care from the end user when systems update their cryptographic keys. TOFU can make it difficult to distinguish routine key management from a malicious attack. * While the use of OS is preempted by a non-OS explicit policy, such a non-OS policy can be counter-productive when it demands more than many peers can in fact deliver. A non-OS policy should be used with care, lest users find it too restrictive and act to disable security entirely. * When less than complete protection is negotiated, there is no need to prompt the user with "your security may be degraded, please click OK" dialogs. The negotiated protection is as good as can be expected. Even if not comprehensive, it is often better than the traditional outcome of either "no protection" or "communications failure". * ... Failure to encrypt may be more often a symptom of an interoperability problem than an active attack. In such a situation, occasional fallback to cleartext may serve the greater good. Even though some traffic is sent in the clear, the alternative is to ask the administrator or user to manually work-around such interoperability problems. If the incidence of such problems is non- negligible, the user or administrator might find it more expedient to just disable Opportunistic Security. * While the use of OS is preempted by a non-OS explicit policy, such a non-OS policy can be counter-productive when it demands more than many peers can in fact deliver. A non-OS policy should be used with care, lest users find it too restrictive and act to disable security entirely. The bottom line is that opportunistic security that is intrusive is counter-productive. What this means for TOFU with DHCP is that mere key pinning should not be a blanket, on by default mechanism. If the feature cannot be made essentially unnoticeable to users, it must be off by default, and enabled by knowledgeable users only in = appropriate circumstances. As for applicability of TOFU in DHCP, it seems to me that at least for most WiFi networks, one really wants to know that one is connecting to a legitimate switch, more than that the DHCP response is authentic. Once one has joined the right network, one might hope that some day the network will protect end-nodes from unauthorized DHCP servers or ARP spoofing of the router IP address, ... Indeed one might expect public WiFi networks to not allow wireless end-nodes to communicate with each other, presenting an illusion of a point-to-point private Layer2/3 connection to each node. At that point DHCP authentication is not needed. So there needs to be a fairly detailed use-case analysis that delineates the situations in which TOFU is useful with DHCP, and how false alarms are kept to a sufficiently low rate to rarely if ever be seen by users. Does it make sense to authenticate DHCP and the network separately? Would TACK be a practical approach to reducing key rotation false alarms? Is secure DHCP useful on shared broadcast networks that don't isolate end-nodes from each other? ... We don't seem to be discussing any detailed use-cases, and similarly detailed proposed designs. A useful outcome from the current thread seems unlikely... --=20 Viktor.= From nobody Thu Sep 1 22:58:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE02B12B038 for ; Thu, 1 Sep 2016 22:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJMxAowqdDpI for ; Thu, 1 Sep 2016 22:58:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E1A128B44 for ; Thu, 1 Sep 2016 22:58:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1bfhUM-0007x9-7x; Fri, 02 Sep 2016 05:58:06 +0000 Date: Fri, 02 Sep 2016 14:58:34 +0900 Message-ID: From: Randy Bush To: Derek Atkins In-Reply-To: <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: Security Area Advisory Group Subject: [saag] introduction (was: gmobd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 05:58:09 -0000 [ in yokohama, i was asked to help with with the dhcp6 draft. i was a fool to agree. will not make same mistake again. } but this is of interest to me. i think of the space as 'introduction' and it is a large and deep problem across many protocols. > For a Starbucks environment I can see a placard at the desk that has > the fingerprint of the local DHCP server. So if the software says "do > you trust this?" (ala SSH) then there is some reason to believe that > users would have something to compare it to. we started experimenting in this space at work, where wifi passwords are changed monthly (don't ask), and are quite long and painful. qr-codes pasted on wall were the favorite. i am less comfortable with scanning a qr code in a coffee shop. but i would hope that, if we started using qr codes in this space, we would develop scanware with which we could be comfortable. randy From nobody Thu Sep 1 23:45:33 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097E9127A91; Thu, 1 Sep 2016 23:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.07 X-Spam-Level: X-Spam-Status: No, score=-15.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wna4Blhbw9k3; Thu, 1 Sep 2016 23:45:30 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264F3127A90; Thu, 1 Sep 2016 23:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3357; q=dns/txt; s=iport; t=1472798730; x=1474008330; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=rudcVEOVm6emKsjA9YLgeG/SYhK6+hDoyoJGC29s7eg=; b=TlCkMptjOYU8OgOE1o/iMfCbtyBfXW4GdGffZ7sS3zhviKed7JvauW65 gPGNt7AvPszizFQEngvg4pTkfIt4suwVAArA1DP/MPc2H+Fb6zrobZhM5 hWf9h2GHbVh98vH0UY42pECLpzKDc/I2fs0yLya+JYTkHjvN+4IOOwCdo 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKBQAjH8lX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgywBAQEBAYEfuQWCAoYcAoIREwECAQEBAQEBAV4nhGEBAQEDASNWBQsLDgo?= =?us-ascii?q?qAgJXBgEMCAEBiD4IrV6MWAEBAQEBAQEDAQEBAQEBARIOiCcIgk2EKoMYgloBB?= =?us-ascii?q?JlSgz6Bc4oDiV2FfJBDIAMxgkkbgU86hzEBAQE?= X-IronPort-AV: E=Sophos;i="5.30,270,1470700800"; d="asc'?scan'208";a="647772812" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2016 06:45:28 +0000 Received: from [10.61.213.154] ([10.61.213.154]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u826jRw1029304; Fri, 2 Sep 2016 06:45:28 GMT To: Ted Lemon , Alan DeKok References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> From: Eliot Lear Message-ID: <7fa75e8c-3297-fa71-e7be-93e9d0f8caec@cisco.com> Date: Fri, 2 Sep 2016 08:45:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="J6EKj4HMmkQDPEaX0dnOFXvb8oSHkqrAV" Archived-At: Cc: draft-li-dhc-secure-dhcpv6-deployment@ietf.org, Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 06:45:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J6EKj4HMmkQDPEaX0dnOFXvb8oSHkqrAV Content-Type: multipart/mixed; boundary="bq2mebuFp2nuvsrTvJHlTH8x5lrfLNnQh"; protected-headers="v1" From: Eliot Lear To: Ted Lemon , Alan DeKok Cc: draft-li-dhc-secure-dhcpv6-deployment@ietf.org, Security Area Advisory Group Message-ID: <7fa75e8c-3297-fa71-e7be-93e9d0f8caec@cisco.com> Subject: Re: [saag] A little more detail on ToFU for DHCPv6 References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> In-Reply-To: --bq2mebuFp2nuvsrTvJHlTH8x5lrfLNnQh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ted, On 9/2/16 1:02 AM, Ted Lemon wrote: > I'm going to give a somewhat unhelpful response, but the question that > pops to mine when you suggest that is, why don't we also do this for > web pages and for ssh? That is, if you have 802.1x, why not use that > security association to authenticate ssh servers? I think the answer > is clearly that you would never do this; I can see why you might think > that it would be okay to do it for DHCP, but I still think it's worth > trying to explicitly answer the question. I'll take a swing. In the case of a web or ssh server, the organizational stretch and complexity necessary to establish this trust may be a bridge too far.=20 PANA et al would have gone a lot further than it otherwise did. In the case of DHCP, however, usually this stuff lives within the same organization, and so there is hope that one could establish such a bindin= g. > In any case, from my perspective, what you're suggesting sounds like > something that would never be deployed. When and how effectively is > 802.1x deployed? It's effectively 802.11ai (e.g., WPA-Enterprise) and is fairly widely deployed in that context. > Are those the same sites that we are trying to help with DHCP > authentication? If you have 802.1x, why aren't you doing DHCP > filtering? I don't think this is an important use case, but if it > is, a pre-shared cert will solve the problem, and you don't want to > use ToFU anyway. At this point, no. But that could easily become a "yes". In fact it might be the best way to go in the long term. Eliot --bq2mebuFp2nuvsrTvJHlTH8x5lrfLNnQh-- --J6EKj4HMmkQDPEaX0dnOFXvb8oSHkqrAV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXySAKAAoJEIe2a0bZ0nozpfUH/1kFRJ8u4+lpwYySr7C6yIz+ o/HRJhZmxf7TL1i2xQBPYR4/5MCNwdfFnWeyhqB/6DnH1mEXTp4LzhDIuCHkGyx0 Uvu8pfeorkknLECA1UZjKFUEFSosm6mLIoJL/JWAFq2h+pW2KVkuKtrft+qPbGZb ToMKoKfTuReYHxevnVeMDn3eKKf0Mmz4ymsP5K7mZi2qUevjshdE6Mv2PlwKPf4R km+XY2/Mm7i/aV6u/PZBXXK/vV/uONcL5MzMEMQOJONoc0yoMfk72f3YqKyD6ww5 jzggM3+fpJrAmMKGTYN3kj9lU/DgQ4SCkVO7ga3spHvfIFZ1OUQPQTc6NUnfWhk= =BrrT -----END PGP SIGNATURE----- --J6EKj4HMmkQDPEaX0dnOFXvb8oSHkqrAV-- From nobody Fri Sep 2 00:36:24 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F2C12D090 for ; Fri, 2 Sep 2016 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAnCaEURYfMi for ; Fri, 2 Sep 2016 00:36:21 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720D712D0E7 for ; Fri, 2 Sep 2016 00:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5513; q=dns/txt; s=iport; t=1472801780; x=1474011380; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ZgE1R2KfcN8n8Dvata3zeSOJFk9OtphSLnnxJn85Zmk=; b=RwDJc+0V1X0SWFUlYEfnYcu374VYukEfQXjUWgsq0P8qxhq4ojYH07ku xJIY532qm3pLbkLRi8o9z1FPypUiMHQtkYNEIshfzgukwf8/1SpvM6KC9 lirfuvlobpPne+HH5ZHBwyoMrEy4xZSwal9GUzZZKIHH6Bvomehzdjfvt Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTCQA4K8lX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgywBAQEBAYEfhBmvX4cPhhwCghMRAQIBAQEBAQEBXieEYgEBAwEjVgULCwQ?= =?us-ascii?q?KNAICVwYBDAgBAYg+CK1ejFUBAQEBAQEBAQEBAQEBAQEBAQEBAQEODognglWEK?= =?us-ascii?q?oMYgloBBJlSgz6Bc4oEiV2FfJBDNCCEPzqHMQEBAQ?= X-IronPort-AV: E=Sophos;i="5.30,270,1470700800"; d="asc'?scan'208,217";a="687495396" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2016 07:36:17 +0000 Received: from [10.61.213.154] ([10.61.213.154]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u827aG1u008907; Fri, 2 Sep 2016 07:36:16 GMT To: Ted Lemon , Alan DeKok References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> From: Eliot Lear Message-ID: <85e433f1-de89-7a27-d71f-a44b6bea7999@cisco.com> Date: Fri, 2 Sep 2016 09:36:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7FPVFrImsXDHQJWOE1k4BtlBfDId8EUf9" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 07:36:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7FPVFrImsXDHQJWOE1k4BtlBfDId8EUf9 Content-Type: multipart/mixed; boundary="4mO3L2JIanI9Qt8KVkFAPXkiqqope2N2P"; protected-headers="v1" From: Eliot Lear To: Ted Lemon , Alan DeKok Cc: Security Area Advisory Group Message-ID: <85e433f1-de89-7a27-d71f-a44b6bea7999@cisco.com> Subject: Re: [saag] A little more detail on ToFU for DHCPv6 References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> In-Reply-To: --4mO3L2JIanI9Qt8KVkFAPXkiqqope2N2P Content-Type: multipart/alternative; boundary="------------81D1311DCCDC773ABE027196" This is a multi-part message in MIME format. --------------81D1311DCCDC773ABE027196 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi again, On 9/2/16 3:45 AM, Ted Lemon wrote: > Securing DHCP helps. But wouldn't it be nice to know that the > organization who granted you network access also granted you > network credentials? i.e. IP addresses? > > > There are several unwarranted assumptions in this question: > > * you've been explicitly, not implicitly, granted access to the netwo= rk > 802.1X makes it explicit. > * the operator of layer 2 is also the operator of the DHCP server > That's probably worth exploring a bit more, and there's not going to be a single definitive example here. However, it may be that pushing this stuff into L2 access is still a better idea than trying to tweak DHCP.=20 On the other hand, a model that maybe borrows from the trust of 1X *when it exists* and does something else when it doesn't may be worth exploring. But isn't this also related to capport? Eliot --------------81D1311DCCDC773ABE027196 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi again,


On 9/2/16 3:45 AM, Ted Lemon wrote:

=C2=A0 Securing DHCP helps.=C2=A0 But wouldn't it be nice to know = that the organization who granted you network access also granted you network credentials?=C2=A0 i.e. IP addresses?

There are several unwarranted assumptions in this question:
  • you've been explicitly, not implicitly, granted access to the network

802.1X makes it explicit.

  • the operator of layer 2 is also the operator of the DHCP server

That's probably worth exploring a bit more, and there's not going to be a single definitive example here.=C2=A0 However, it may be that pushing this stuff into L2 access is still a better idea than trying to tweak DHCP.=C2=A0 On the other hand, a model that maybe borrows fr= om the trust of 1X when it exists and does something else when it doesn't may be worth exploring.=C2=A0 But isn't this also related = to capport?

Eliot


--------------81D1311DCCDC773ABE027196-- --4mO3L2JIanI9Qt8KVkFAPXkiqqope2N2P-- --7FPVFrImsXDHQJWOE1k4BtlBfDId8EUf9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJXySvwAAoJEIe2a0bZ0nozZncH/188vCEXxUACuflQptVIC7WI VUfJsHofS+nQv0B0KD3H366cPHMA+ddzWiYYE4oF5D2w78/TQezSVirAs9jrsLS0 B5IB5mxtNFZ886nrtzhcY2vtJcFLIs0SXnDt2GXyaEXQF59K5lh6DlmvgHzViCRJ y2/cSED2qKe1aZ+lG1b22/ZGrc/0ivH8TMbE1fp2bJxXkqBcQVG7hD+aAihs4ahT OoKSdakyO7UCFga/In1o2q1lr6D9XKQcn/sabZEDtqVghNFkkcX8LPYQpT0pn4lM lJgeIiD0ndTVUwDjnA8+jWQcxf9PNmJXPB/1x/Z44dDTU9F9+ZQhhm8xl02lPv8= =D4T4 -----END PGP SIGNATURE----- --7FPVFrImsXDHQJWOE1k4BtlBfDId8EUf9-- From nobody Fri Sep 2 02:49:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F016C12D51D for ; Fri, 2 Sep 2016 02:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaUvLqcrRYik for ; Fri, 2 Sep 2016 02:49:10 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1335B12D764 for ; Fri, 2 Sep 2016 02:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/8DB0IPC9eSyBxQPTEeIE6ZyaHhbTx6a0s1bXvXawY4=; b=Wjw2o9hVkuTZFC3CvUPsEtDJhKuO9pIeKRsDoouQYZ2W3KppwsxB5ArMVE3i1GBF/Blm06FcylNOWKx03Ar8rnIRLUSXGTItiMGQvXsZjbM5tLUJW53+nxNoyku0z551MbEKRMcqYJLJchvk7Nu+I95SAbccWS572RPGyEs574o= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-73-ef6vE5wOMZC5APZ9mDhHbA-1; Fri, 02 Sep 2016 10:49:02 +0100 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com (10.165.239.15) by VI1PR07MB1584.eurprd07.prod.outlook.com (10.165.239.18) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Fri, 2 Sep 2016 09:49:00 +0000 Received: from VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) by VI1PR07MB1581.eurprd07.prod.outlook.com ([10.165.239.15]) with mapi id 15.01.0587.013; Fri, 2 Sep 2016 09:49:01 +0000 From: Josh Howlett To: Ted Lemon , Alan DeKok Thread-Topic: [saag] A little more detail on ToFU for DHCPv6 Thread-Index: AQHSBHzmyklSMFZVm0GSG9Sk26YrBKBlJD+AgAAcvQCAAAXZAIAAJ4iAgACABFA= Date: Fri, 2 Sep 2016 09:49:00 +0000 Message-ID: References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.135.32.196] x-ms-office365-filtering-correlation-id: 254bcb74-853f-4d31-1781-08d3d3165e1b x-microsoft-exchange-diagnostics: 1; VI1PR07MB1584; 20:j8kD6gDuIBwefBXJVEBTwFczvdwMg7w49Ak0RCdmmGMiF3I1xLS3I57mLgd5vdAYDv9i0RcnTCvnTEL618RD7Uc1CYAJBnidjauBpSj+XeMuptMap+6HG2Nbo9g2wWWEBctSPqddPpCH8nKuqSPXHU9p4iSr1uGZy/e0i2GoL9M= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1584; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:VI1PR07MB1584; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1584; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(377454003)(50986999)(97736004)(189998001)(74316002)(68736007)(102836003)(3846002)(76176999)(7846002)(7696003)(74482002)(19580405001)(7736002)(54356999)(305945005)(5002640100001)(33656002)(87936001)(19580395003)(5001770100001)(2950100001)(92566002)(77096005)(86362001)(2906002)(9686002)(10400500002)(8936002)(5660300001)(105586002)(3660700001)(81156014)(101416001)(106356001)(586003)(6116002)(81166006)(2900100001)(93886004)(4326007)(122556002)(106116001)(66066001)(8676002)(3280700002)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1584; H:VI1PR07MB1581.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2016 09:49:00.8514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1584 X-MC-Unique: ef6vE5wOMZC5APZ9mDhHbA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 09:49:26 -0000 T24gVGh1LCBTZXAgMSwgMjAxNiBhdCA3OjIzIFBNLCBBbGFuIERlS29rIDxhbGFuZEBkZXBsb3lp bmdyYWRpdXMuY29tPiB3cm90ZToNCj4NCj4gPiBPbiBTZXAgMSwgMjAxNiwgYXQgNzowMiBQTSwg VGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiB3cm90ZToNCj7CoD4gPsKgVGhhdCBpcywgaWYg eW91IGhhdmUgODAyLjF4LCB3aHkgbm90IHVzZSB0aGF0IHNlY3VyaXR5IGFzc29jaWF0aW9uIHRv IGF1dGhlbnRpY2F0ZSBzc2ggc2VydmVycz8NCg0KPsKgPiBUaGUgQUJGQUIgd29ya2luZyBncm91 cCBsZXZlcmFnZXMgdGhlIEFBQSBpbmZyYXN0cnVjdHVyZSB0byBhdXRoZW50aWNhdGUgDQo+ID4g dXNlcnMgdG8gU1NIIHNlcnZlcnMuwqAgV2hpY2ggaXMgcHJldHR5IGRhcm5lZCBzaW1pbGFyLg0K DQo+IFRoaXMgaXMgYSBmYXNjaW5hdGluZyBjb2xsZWN0aW9uIG9mIHdvcmstLUkganVzdCBwZWVr ZWQgYXQgdGhlIGFyY2ggZG9jdW1lbnQuIMKgIFRoYXQgc2FpZCwgSSBjYW4ndCBpbWFnaW5lIGEN Cj4gc2l0dWF0aW9uIGluIHdoaWNoIEkgd291bGQgZmluZCBteXNlbGYgdXNpbmcgaXQuIMKgIEkg YmVsaWV2ZSB0aGF0IHN1Y2ggc2l0dWF0aW9ucyBleGlzdCwgYnV0IG15IHBvaW50IGlzIHRoYXQg dGhpcyBpcw0KPiBub3QgYSBnb29kIGdlbmVyYWwgYXBwcm9hY2gtLWl0IGlzIHNvbHZpbmcgYSB2 ZXJ5IGNvbnN0cmFpbmVkIHByb2JsZW0uDQrCoA0KSnVzdCB0byBiZSBjbGVhciwgQUJGQUIncyBz Y29wZSBpcyBtdWNoIGJyb2FkZXIgdGhhbiBTU0guIE91ciBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0 cyBhIG51bWJlciBvZiBhcHBsaWNhdGlvbnMgdmlhIFVuaXggR1NTLUFQSSAmIFdpbmRvd3MgU1NQ SSAoaW5jbHVkaW5nIE9wZW5TU0ggYW5kIFB1dHR5KS4NCg0KSSBoYXZlIGZvciBzb21lIHRpbWUg YmVlbiBtZWFuaW5nIHRvIHRlc3Qgb3VyIEFCRkFCIGltcGxlbWVudGF0aW9uIHdpdGggYSBETlMg aW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyBUU0lHIChSRkMgMjg0NSksIHN1Y2ggdGhhdCB0cnVz dCBjb3VsZCBiZSBlc3RhYmxpc2hlZCBpbiBETlMgdXNpbmcgYSBBQUEgaW5mcmFzdHJ1Y3R1cmUg KGFzIG9wcG9zZWQgdG8gUEtJLWJhc2VkIGFwcHJvYWNoZXMpLiBJdCB3b3VsZCBiZSBpbnRlcmVz dGluZyB0byBjb25zaWRlciB3aGV0aGVyIGFuIGFwcHJvYWNoIGFuYWxvZ291cyB0byBUU0lHIGNv dWxkIGJlIHRha2VuIHdpdGggREhDUC4gRm9sa3MgcnVubmluZyBESENQIGFyZSBvZnRlbiBhbHNv IGluIHRoZSBidXNpbmVzcyBvZiBydW5uaW5nIEFBQTsgdGhlIGFiaWxpdHkgdG8gYmFjayBvZmYg dHJ1c3QgZGVjaXNpb25zIHRvIGEgY29tbW9uIGluZnJhc3RydWN0dXJlIG1pZ2h0IGJlIGF0dHJh Y3RpdmUuIA0KDQpKb3NoLg0KDQpKaXNjIGlzIGEgcmVnaXN0ZXJlZCBjaGFyaXR5IChudW1iZXIg MTE0OTc0MCkgYW5kIGEgY29tcGFueSBsaW1pdGVkIGJ5IGd1YXJhbnRlZSB3aGljaCBpcyByZWdp c3RlcmVkIGluIEVuZ2xhbmQgdW5kZXIgQ29tcGFueSBOby4gNTc0NzMzOSwgVkFUIE5vLiBHQiAx OTcgMDYzMiA4Ni4gSmlzY+KAmXMgcmVnaXN0ZXJlZCBvZmZpY2UgaXM6IE9uZSBDYXN0bGVwYXJr LCBUb3dlciBIaWxsLCBCcmlzdG9sLCBCUzIgMEpBLiBUIDAyMDMgNjk3IDU4MDAuDQoNCkppc2Mg U2VydmljZXMgTGltaXRlZCBpcyBhIHdob2xseSBvd25lZCBKaXNjIHN1YnNpZGlhcnkgYW5kIGEg Y29tcGFueSBsaW1pdGVkIGJ5IGd1YXJhbnRlZSB3aGljaCBpcyByZWdpc3RlcmVkIGluIEVuZ2xh bmQgdW5kZXIgY29tcGFueSBudW1iZXIgMjg4MTAyNCwgVkFUIG51bWJlciBHQiAxOTcgMDYzMiA4 Ni4gVGhlIHJlZ2lzdGVyZWQgb2ZmaWNlIGlzOiBPbmUgQ2FzdGxlIFBhcmssIFRvd2VyIEhpbGws IEJyaXN0b2wgQlMyIDBKQS4gVCAwMjAzIDY5NyA1ODAwLiAgDQo= From nobody Fri Sep 2 04:19:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291C512D187 for ; Fri, 2 Sep 2016 04:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DnQWNDND7D9 for ; Fri, 2 Sep 2016 04:19:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084FC12B037 for ; Fri, 2 Sep 2016 04:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08422BE56; Fri, 2 Sep 2016 12:19:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5NDWRFg8hBK; Fri, 2 Sep 2016 12:19:19 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80B02BE33; Fri, 2 Sep 2016 12:19:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472815159; bh=zDI3D3fbRswhe6ZfqdxaC1c/6645/vI/G6blSgJu8GU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cV0tx+4oJ9WQ7m2w15+JwAS/woH2PtvqAX0dmq3p0oPneePz+r6pvhNjsdTedGyPY DZoIhTzUDjZBEdR2RBtykOzfHJRyGGBJIqHNXv/zGOtPaH+xQxA3jZmOSKzQx6WEoV Jy6W+KHoTnA3pqEJfIjjkDPfZSJdbuqWKGHb9iyE= To: Randy Bush , Derek Atkins References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 2 Sep 2016 12:19:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010509020801070709030801" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] introduction X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 11:19:27 -0000 This is a cryptographically signed message in MIME format. --------------ms010509020801070709030801 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/09/16 06:58, Randy Bush wrote: > [ in yokohama, i was asked to help with with the dhcp6 draft. i was a > fool to agree. will not make same mistake again. } Thanks though for being willing. > but this is of interest to me. i think of the space as 'introduction' > and it is a large and deep problem across many protocols. Yes. It'd be really interesting if there were a way to make progress there. TBH, I'm not sure how we can do that though. Suggestions very welcome. > >> For a Starbucks environment I can see a placard at the desk that has >> the fingerprint of the local DHCP server. So if the software says "do= >> you trust this?" (ala SSH) then there is some reason to believe that >> users would have something to compare it to. >=20 > we started experimenting in this space at work, where wifi passwords ar= e > changed monthly (don't ask), and are quite long and painful. qr-codes > pasted on wall were the favorite. >=20 > i am less comfortable with scanning a qr code in a coffee shop. but i > would hope that, if we started using qr codes in this space, we would > develop scanware with which we could be comfortable. I like QR codes too for this kind of thing. When I suggested using 'em for a thing though I had a bunch of people tell me that too few people have readers they actually use for QR codes to be that useful. I'm not sure if there're any public numbers about that though. Cheers, S. >=20 > randy >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --------------ms010509020801070709030801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDIx MTE5MThaMC8GCSqGSIb3DQEJBDEiBCBn70KCsn6LcJKfBnyGAIgE13miAWxlTWPiHOdrAIMr njBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBV9H32p923glvva/jb65WmvkC/Wix2vWTFOchjLe6RmBcccLOIX5jn Ryjqu1FG2qlFcfB6Myinew272vfMKznHzNH3X+jO+gWynzEMqYrVN65wt58W1L3IGopFEF9G Zcjq3/m5bKDHsYuUyqy9kOgpaAmUG/ZzSAzTF0dU5+ULcpowpVoHmqJUFS2+2HoiY8c6Cb4r /9eHBSvhxU61UFNRmBxrRITAKM6TGAuQrKmHvy9WQBx4pbuvQmzSDZTW2osVo1wzWiOy4X3b B55c9V0TgyfsSwMaeHVlsTYVgFKYKoH8EcKuS2mm2As37It/IYS5TeTpB0Ef3vLpCvBY20dc AAAAAAAA --------------ms010509020801070709030801-- From nobody Fri Sep 2 05:31:48 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CD012B017 for ; Fri, 2 Sep 2016 05:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRooPq77u9Lk for ; Fri, 2 Sep 2016 05:31:43 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B2112B00F for ; Fri, 2 Sep 2016 05:31:43 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id p41so64038729lfi.1 for ; Fri, 02 Sep 2016 05:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8mRLLydkyvpvjftwaF7VqPQ1xvHWVO+PVdHt++yzAjg=; b=A5OrQ+qGeouUlpIYxwKYL6cznXXw6Hw3O+A50Yh6MqvFQ9v2RbgkdhaJjPqbX43/YL 8AbqqkdV2C/GvlCLxWONEirKpQoddoQNur/o0WHdoi5NvTmlEFH1H5fMZvBnDZy8moeq 4fe86Si3DeofL2An9TGcUtvGRTVnq1ll15rjGnfYPXNWT2hQbtvRdQgedng8fPaY1h8s ltoeSKvjfLHDR9JiuMpdV78odoxa+k6k58zCVKtJG1U1dWP/3TJJV9Kr1FeSyIHMjNDM B04uokWeOQYdbqo2VqwSwetMhwwJlHwnepMOtR1wyx1/UC2GvYaF/fxYRqPHtrIOKN5d +SXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8mRLLydkyvpvjftwaF7VqPQ1xvHWVO+PVdHt++yzAjg=; b=hiNzn4o2qN0TSyev0Q9QjY8KM8lKPYf4vtefPnFKz2pMjvtzp3WZKM5QkzFe0edzvu VbrTdd3D2jaLecHfAtRVCmVyCmrPIBQRDYRHX9R3YMNxG8cbWsmxTrrn4C1Tfdo/mvm9 e2RFWhirLEGjdufrLRQztRRzUqdIypNbRsxby8CECMQKF//KagZXJTVGLCIlYs68oLND BwCpPI7q652Lrlu4SolgNlc+ZXTgEPXtCvYk7DT3oBmtuXaZwZnTKMcE6J/lwdp58ZTZ o0mNq+J1d+4+P8049yuITnOFwthXS17QZw4WmGn4/7AILchQDajHUMVTSUK8UU+g2lYK N+AA== X-Gm-Message-State: AE9vXwPfS2QiW+d2BxlRSFMbz0JDMdeE+O7O1kF8kjmmmWHQYPkfA22ZhX2pJT0NlMRi1HB0rZe2GrXla6D+PA== X-Received: by 10.25.91.133 with SMTP id p127mr5822609lfb.39.1472819500475; Fri, 02 Sep 2016 05:31:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Fri, 2 Sep 2016 05:30:59 -0700 (PDT) In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <72fcc068-c825-e545-d5dd-475c71cacd32@isi.edu> From: Ted Lemon Date: Fri, 2 Sep 2016 08:30:59 -0400 Message-ID: To: Security Area Advisory Group Content-Type: multipart/alternative; boundary=001a1141209c251bc7053b85835e Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 12:31:48 -0000 --001a1141209c251bc7053b85835e Content-Type: text/plain; charset=UTF-8 On Fri, Sep 2, 2016 at 1:31 AM, Viktor Dukhovni wrote: > The bottom line is that opportunistic security that is intrusive is > counter-productive. What this means for TOFU with DHCP is that mere > key pinning should not be a blanket, on by default mechanism. If > the feature cannot be made essentially unnoticeable to users, it must > be off by default, and enabled by knowledgeable users only in appropriate > circumstances. > This seems to me to be the key point of contention--I agree with everything you wrote above it, but it's important to understand what we are talking about here, and I think using the term "key pinning" severely confuses the discussion. As I understand it, and I'm sure you will correct me if I am wrong, since I know you know more about this than I do, key pinning is when you have a cert that signs a key, and you remember _that key_ as the correct key for the identity being claimed with the cert. If you later get a new cert also claiming that identity but for a different key, you reject it as a registry attack. This is not at all what we are talking about here. We are in fact assuming that a given DHCP server identity will be protected by the same key forever. If you want to use a new key, you should use a new identity, to avoid key pinning. This is a key point that I missed, which may have led us down this branch of the discussion. You do not want to ever have a new key for the same server identity, because doing so will produce exactly the bad outcome you are concerned about, and would add no value at all. For ToFU, the thing that I think you took for key pinning is simply a key caching heuristic that does not require user involvement to be useful. If I get a DHCP message signed by a key that I previously cached, and there were no problems with the previously-cached key, then I will prefer that DHCP server over another DHCP server that also responded either using no authentication, or using a key that I have not cached. If I get responses from more than one DHCP server whose key I have cached, I will choose from the signed responses using the same algorithm I would normally use to choose from a selection of unsigned responses. This assures that the worst case scenario is the same behavior I currently get with unsecured DHCP. The only UI to add here is a "the network is flaky" button, which could actually be another heuristic. If "the network is flaky" then the DHCP key I picked may be the wrong one, so mark it as suspect and try the other. As for applicability of TOFU in DHCP, it seems to me that at least for > most WiFi networks, one really wants to know that one is connecting to > a legitimate switch, more than that the DHCP response is authentic. > Yes, exactly. > Once one has joined the right network, one might hope that some day > the network will protect end-nodes from unauthorized DHCP servers > or ARP spoofing of the router IP address, ... Indeed one might > expect public WiFi networks to not allow wireless end-nodes > to communicate with each other, presenting an illusion of a > point-to-point private Layer2/3 connection to each node. At > that point DHCP authentication is not needed. > Right. I think this is actually pretty typical for professionally-managed hotspot networks already. > So there needs to be a fairly detailed use-case analysis that > delineates the situations in which TOFU is useful with DHCP, > and how false alarms are kept to a sufficiently low rate to > rarely if ever be seen by users. > Yup. > Does it make sense to authenticate DHCP and the network separately? > Yes. In many networks layer two is operated by a different entity than layer 3, and requiring them to share keys is inappropriate. > Would TACK be a practical approach to reducing key rotation false > alarms? Keys should never, ever be rotated for ToFU. Server identities are not precious. If you want to rotate keys, change both the key and the identity. > Is secure DHCP useful on shared broadcast networks that > don't isolate end-nodes from each other? ... > I think so. > We don't seem to be discussing any detailed use-cases, and similarly > detailed proposed designs. A useful outcome from the current thread > seems unlikely.. Thinking about your response has already been useful to me in thinking about the details of how to specify this. Thank you for that. --001a1141209c251bc7053b85835e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 2, 2016 at 1:31 AM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
The bottom line is= that opportunistic security that is intrusive is
counter-productive.=C2=A0 What this means for TOFU with DHCP is that mere key pinning should not be a blanket, on by default mechanism.=C2=A0 If
the feature cannot be made essentially unnoticeable to users, it must
be off by default, and enabled by knowledgeable users only in appropriate circumstances.

This seems to me to be t= he key point of contention--I agree with everything you wrote above it, but= it's important to understand what we are talking about here, and I thi= nk using the term "key pinning" severely confuses the discussion.=

As I understand it, and I'm sure you will cor= rect me if I am wrong, since I know you know more about this than I do, key= pinning is when you have a cert that signs a key, and you remember _that k= ey_ as the correct key for the identity being claimed with the cert. =C2=A0= If you later get a new cert also claiming that identity but for a differen= t key, you reject it as a registry attack.

This is= not at all what we are talking about here. =C2=A0 We are in fact assuming = that a given DHCP server identity will be protected by the same key forever= . =C2=A0 If you want to use a new key, you should use a new identity, to av= oid key pinning. =C2=A0 This is a key point that I missed, which may have l= ed us down this branch of the discussion.=C2=A0 You do not want to ever hav= e a new key for the same server identity, because doing so will produce exa= ctly the bad outcome you are concerned about, and would add no value at all= .

For ToFU, the thing that I think you took for ke= y pinning is simply a key caching heuristic that does not require user invo= lvement to be useful. =C2=A0 If I get a DHCP message signed by a key that I= previously cached, and there were no problems with the previously-cached k= ey, then I will prefer that DHCP server over another DHCP server that also = responded either using no authentication, or using a key that I have not ca= ched.

If I get responses from more than one DHCP s= erver whose key I have cached, I will choose from the signed responses usin= g the same algorithm I would normally use to choose from a selection of uns= igned responses. =C2=A0 This assures that the worst case scenario is the sa= me behavior I currently get with unsecured DHCP. =C2=A0 The only UI to add = here is a "the network is flaky" button, which could actually be = another heuristic. =C2=A0 If "the network is flaky" then the DHCP= key I picked may be the wrong one, so mark it as suspect and try the other= .

As for applicability o= f TOFU in DHCP, it seems to me that at least for
most WiFi networks, one really wants to know that one is connecting to
a legitimate switch, more than that the DHCP response is authentic.

Yes, exactly.
=C2=A0
Once one has joined the right network, one might hope = that some day
the network will protect end-nodes from unauthorized DHCP servers
or ARP spoofing of the router IP address, ...=C2=A0 Indeed one might
expect public WiFi networks to not allow wireless end-nodes
to communicate with each other, presenting an illusion of a
point-to-point private Layer2/3 connection to each node.=C2=A0 At
that point DHCP authentication is not needed.

Right. =C2=A0 I think this is actually pretty typical for profession= ally-managed hotspot networks already.
=C2=A0
So there needs to be a fairly detailed use-case analysis t= hat
delineates the situations in which TOFU is useful with DHCP,
and how false alarms are kept to a sufficiently low rate to
rarely if ever be seen by users.

Yup.
=C2=A0
Does it make sense to authenticate DHCP and the network separately?

Yes. =C2=A0 In many networks layer two is oper= ated by a different entity than layer 3, and requiring them to share keys i= s inappropriate.
=C2=A0
Would TACK be a practical approach to reducing key rotation false
alarms?

Keys should never, ever be rotated = for ToFU. =C2=A0 Server identities are not precious. =C2=A0 If you want to = rotate keys, change both the key and the identity.
=C2=A0
Is secure DHCP useful on shared broadcast netw= orks that
don't isolate end-nodes from each other? ...

<= /div>
I think so.
=C2=A0
We don't seem to be discussing any detailed use-cases, and similarly detailed proposed designs.=C2=A0 A useful outcome from the current thread seems unlikely..

Thinking about your respon= se has already been useful to me in thinking about the details of how to sp= ecify this. =C2=A0 =C2=A0Thank you for that.

--001a1141209c251bc7053b85835e-- From nobody Fri Sep 2 05:36:46 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B6512B02A for ; Fri, 2 Sep 2016 05:36:45 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpJFLu3bRuXv for ; Fri, 2 Sep 2016 05:36:43 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9929712D16D for ; Fri, 2 Sep 2016 05:36:39 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id e198so49039025lfb.2 for ; Fri, 02 Sep 2016 05:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PlhMIm0ieJvDE6329Tq4s5L5xJC0OH5LyDzKyCIyJRc=; b=bYfuiUmBW7DFZag9yQpAnEwLVSRLvYFHDP62SOI1xP+eyCk7+lRrbAXlQUth+Tqe+M o3nnAO7gvK8VmA/vpDgbtYJSCswHOujUCykwmfABBOfcjjm4rjQ9NZ5TeZiYRLIkAmKp bLTwiDojLzgxYv5jbJ2diOuC3NL2GyER9mMrOJd98/alKmQTBCToiimDZginRloKlCBi j9XWsSOf6779e3Tat2H0HIOJiEFe7zz02Fg7A3lnn+Hbm8kJFJwTxLoLUdSGNwreXiyc RQuUytotrE8Q89aJ9XCR9u+txZ8T66VYBV/hnhQT4Uru3qsoYknui7FiaZmxD83oJRsb tl6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PlhMIm0ieJvDE6329Tq4s5L5xJC0OH5LyDzKyCIyJRc=; b=a4EMf+MWJMiH0VPRWCKaSVQlAk4aGnkOfrHVEEGFU8srjU/0sBFRnKoTX3wiXAaxkZ XDn6mD3WvOxGVR16/af75X0E67QscVHOYgDApUq/Yt4xMyfKfeEq8+QIxDsBRnHKFCe3 rrZlL1rMv17X34JEBBOiwX3lgFCDdHDxLPtfvDv8IQG9oSFM5HgkKtSndrOeTNmRGZIU ugLphqHo7yTCc9AsWl87Z4gicxR2G/qy3nhcjaNxz3cNLwjbn1qNJEQKlACFfxpz0blt tgcGdQ+/HelvVwUJ7Fp2vI0HWDa3bXeKfi9N/gris8QJn4zemBscASL43yPoWQ45C/G/ nOLA== X-Gm-Message-State: AE9vXwPT1hIQePo23yWxH6z6Z7smuWa2JXHacC27KJpLskKo+3OYFLS0MT+VJaqVC7tGuPr5TEDIqtS70oGYvQ== X-Received: by 10.25.26.194 with SMTP id a185mr7089658lfa.167.1472819797459; Fri, 02 Sep 2016 05:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Fri, 2 Sep 2016 05:35:56 -0700 (PDT) In-Reply-To: <85e433f1-de89-7a27-d71f-a44b6bea7999@cisco.com> References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> <85e433f1-de89-7a27-d71f-a44b6bea7999@cisco.com> From: Ted Lemon Date: Fri, 2 Sep 2016 08:35:56 -0400 Message-ID: To: Security Area Advisory Group Content-Type: multipart/alternative; boundary=001a11403bd8d89886053b85943b Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 12:36:46 -0000 --001a11403bd8d89886053b85943b Content-Type: text/plain; charset=UTF-8 On Fri, Sep 2, 2016 at 3:36 AM, Eliot Lear wrote: > There are several unwarranted assumptions in this question: > > - you've been explicitly, not implicitly, granted access to the network > > > 802.1X makes it explicit. > Right, what I meant here is that arguably the absence of 802.1x is a base assumption for what we are working on. If you have 802.1x, you probably don't need DHCP security, although perhaps you would want encryption. But if you want encryption, you can use PKI for the server key--you don't need ToFU. --001a11403bd8d89886053b85943b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 2, 2016 at 3:36 AM, Eliot Lear <lear@cisco.com> wrote:<= br>
=20 =20 =20
There are several unwarran= ted assumptions in this question:
  • you've been explicitly, not implicitly, granted access to the network

 802.1X makes it explicit.

Right, = what I meant here is that arguably the absence of 802.1x is a base assumpti= on for what we are working on. =C2=A0 If you have 802.1x, you probably don&= #39;t need DHCP security, although perhaps you would want encryption. =C2= =A0 But if you want encryption, you can use PKI for the server key--you don= 't need ToFU.=C2=A0
--001a11403bd8d89886053b85943b-- From nobody Fri Sep 2 05:41:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EC212D7FF for ; Fri, 2 Sep 2016 05:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj8-76JgK2d7 for ; Fri, 2 Sep 2016 05:41:17 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F41712B024 for ; Fri, 2 Sep 2016 05:41:17 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id g62so82653295lfe.3 for ; Fri, 02 Sep 2016 05:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5AT4JJPA1k8kRmSfSueXznbt1kXSiWj9TegF640NVVs=; b=CkyE1mWhrRR4W763M1Wk2SRe7oXOy2VTtuT1zX4pjSKykstDDmF3KpY4xTMIPfZIXo mN/z7V56hdf1uMmEHFinVPA+Cx0otXSmJkxj1Rmwy+5f3aV6Fso0s77a6N2c0nIHg39U /Vvkcl3eNNeFfnQQpFPe4zZ1IkKePaSb2XaXGBymX21+vbnJ8E9J3iIADqGDt5wAXxI7 9HgaRrilf551QMZdekQdDjVcQk76PcDSI5PUYJ3Xjl9CYfaEZMxY12mlyBcTBjAR6oaL UU9GLtOY2bu/4xDnOii8ixz+ZBMiOQpXiu2bwDCG7mJRz1rMxqzNbziXsw8w2cFFfoDs jdIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5AT4JJPA1k8kRmSfSueXznbt1kXSiWj9TegF640NVVs=; b=UZN+QxWnefvZctKFaDy4O8TdEe+fmjvwM+Mw3LWhLexIcBfBKIhxzwYaiTt3CnA2yD cCo5dnbq3dh27rAQ8PZUWqJttqhUTOmp2CjUOXehjrMSmB1rNfniqLQJm5tjK2G6VjSZ exuMUdAoi6wiSHHHW5A1MgBu8m/xtKLeLiuAefwZPup1V7L634DaljXpaQEOkg0N1S2w IPXJ/tDGhB0O9gL0mnp8ylbcAUvsLUplNdzcroNJ2oyW4XF1dOOzRb2pwJ7I0kqtKXEO D9Z76Jd3BWtzCBvyN2DR9iGKbSj1l1ai66hMskwsXOXEr+HEU7R4D+CbvcBRY1NX5JhU eZUg== X-Gm-Message-State: AE9vXwPUvUW+6smAQBj8LiEbqjHny4DuHKycwNqv8vFoa1HZcNNiquCMQ//oe5TYk+rhwO+CpvT1GAEwMdlVSA== X-Received: by 10.25.26.194 with SMTP id a185mr7096600lfa.167.1472820075277; Fri, 02 Sep 2016 05:41:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Fri, 2 Sep 2016 05:40:34 -0700 (PDT) In-Reply-To: References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> From: Ted Lemon Date: Fri, 2 Sep 2016 08:40:34 -0400 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a11403bd867baee053b85a597 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] introduction (was: gmobd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 12:41:19 -0000 --001a11403bd867baee053b85a597 Content-Type: text/plain; charset=UTF-8 I'm sorry, but you guys are getting distracted by the shiny tech. A QR code is a way to _ensure_ that the rogue DHCP server gets to pwn you, not a way to protect you from a rogue DHCP server. If I want to attack everyone in a Starbucks, all I have to do is set up my rogue server and paste a nicely printed QR code over the one that's up, while the barista is making my quad three-pump glatte. On Fri, Sep 2, 2016 at 1:58 AM, Randy Bush wrote: > [ in yokohama, i was asked to help with with the dhcp6 draft. i was a > fool to agree. will not make same mistake again. } > > but this is of interest to me. i think of the space as 'introduction' > and it is a large and deep problem across many protocols. > > > For a Starbucks environment I can see a placard at the desk that has > > the fingerprint of the local DHCP server. So if the software says "do > > you trust this?" (ala SSH) then there is some reason to believe that > > users would have something to compare it to. > > we started experimenting in this space at work, where wifi passwords are > changed monthly (don't ask), and are quite long and painful. qr-codes > pasted on wall were the favorite. > > i am less comfortable with scanning a qr code in a coffee shop. but i > would hope that, if we started using qr codes in this space, we would > develop scanware with which we could be comfortable. > > randy > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a11403bd867baee053b85a597 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm sorry, but you guys are getting distracted by the = shiny tech. =C2=A0 A QR code is a way to _ensure_ that the rogue DHCP serve= r gets to pwn you, not a way to protect you from a rogue DHCP server. =C2= =A0 If I want to attack everyone in a Starbucks, all I have to do is set up= my rogue server and paste a nicely printed QR code over the one that's= up, while the barista is making my quad three-pump glatte.=C2=A0

On Fri, Sep 2, 2016 a= t 1:58 AM, Randy Bush <randy@psg.com> wrote:
[ in yokohama, i was asked to help with with the dhcp6 draft= .=C2=A0 i was a
=C2=A0 fool to agree.=C2=A0 will not make same mistake again. }

but this is of interest to me.=C2=A0 i think of the space as 'introduct= ion'
and it is a large and deep problem across many protocols.

> For a Starbucks environment I can see a placard at the desk that has > the fingerprint of the local DHCP server.=C2=A0 So if the software say= s "do
> you trust this?" (ala SSH) then there is some reason to believe t= hat
> users would have something to compare it to.

we started experimenting in this space at work, where wifi passwords are changed monthly (don't ask), and are quite long and painful.=C2=A0 qr-c= odes
pasted on wall were the favorite.

i am less comfortable with scanning a qr code in a coffee shop.=C2=A0 but i=
would hope that, if we started using qr codes in this space, we would
develop scanware with which we could be comfortable.

randy

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

--001a11403bd867baee053b85a597-- From nobody Fri Sep 2 05:54:26 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23712D81D for ; Fri, 2 Sep 2016 05:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7nQFCUX6Bvy for ; Fri, 2 Sep 2016 05:54:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5B9E12D834 for ; Fri, 2 Sep 2016 05:54:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1351FBE35; Fri, 2 Sep 2016 13:54:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jp0MvQ2VQan; Fri, 2 Sep 2016 13:54:17 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 03DC5BE2C; Fri, 2 Sep 2016 13:54:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472820857; bh=tJWHzpOGthm0PVUTRJIlGWliCIA/IylatvwteLIQUJE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=iTUnLWDurlwt43xcUzyzRzKxzIJA04fNfWN9ZX/Ubnu0fjbIEooJWoA2xdZj40BE+ V9hMxf28iPE1bt0/Pou3nfyx3CdpGHgA6ocH00oxwSoyg4FYMBk0HQFnBpyFmwnJ3v oYi1zz8LvcDntKjjbH/mWDwbts8l3XnqzokQ2+AI= To: Ted Lemon , Randy Bush References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5438a675-7545-0768-8a70-cedc45e30422@cs.tcd.ie> Date: Fri, 2 Sep 2016 13:54:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090308010402040603030003" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] introduction X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 12:54:25 -0000 This is a cryptographically signed message in MIME format. --------------ms090308010402040603030003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/09/16 13:40, Ted Lemon wrote: > I'm sorry, but you guys are getting distracted by the shiny tech. =20 No. The QR code thing is just an example mechanism. The interesting bit is the general problem of introduction. (And how we all constantly side-track discussion of that because there're so many dimensions to the problem;-) S. > A QR > code is a way to _ensure_ that the rogue DHCP server gets to pwn you, n= ot a > way to protect you from a rogue DHCP server. If I want to attack ever= yone > in a Starbucks, all I have to do is set up my rogue server and paste a > nicely printed QR code over the one that's up, while the barista is mak= ing > my quad three-pump glatte. >=20 > On Fri, Sep 2, 2016 at 1:58 AM, Randy Bush wrote: >=20 >> [ in yokohama, i was asked to help with with the dhcp6 draft. i was a= >> fool to agree. will not make same mistake again. } >> >> but this is of interest to me. i think of the space as 'introduction'= >> and it is a large and deep problem across many protocols. >> >>> For a Starbucks environment I can see a placard at the desk that has >>> the fingerprint of the local DHCP server. So if the software says "d= o >>> you trust this?" (ala SSH) then there is some reason to believe that >>> users would have something to compare it to. >> >> we started experimenting in this space at work, where wifi passwords a= re >> changed monthly (don't ask), and are quite long and painful. qr-codes= >> pasted on wall were the favorite. >> >> i am less comfortable with scanning a qr code in a coffee shop. but i= >> would hope that, if we started using qr codes in this space, we would >> develop scanware with which we could be comfortable. >> >> randy >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --------------ms090308010402040603030003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDIx MjU0MTZaMC8GCSqGSIb3DQEJBDEiBCDvytPDXpP6F+GAWrE+wRkIsgUgA3ZJ8kLQPGiglYpg yTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCsYhaHAZt8s6O2ZfTUV+oMruS9MRygycotwChm7uGXt3ZHIBOBmSCZ Oey00/X+7/C8jAP52FRR+ckbl4o7N3yxrf77sjjCH1gGUGOc6Q7XJBRwl6GxgZS1Qfz8Up1N KY9ZMCFkQKBKc5Gpv034iGVD1iJXu/rkzrEqf+YfNAYszLF3Zi1nbwROokt8Y6rLH5a2Inue +KHQ6a8DNB0s3XtWtCw4Qvm0uoRSZuqHIlZv0Xh4ZRBZGnLGK7Kjj8r/i9IOjFXy29AkEej4 //N6y55BjlRZRaLopiIT6jqdkud5NoCETcDXyEMQVCP3fX/c3UB3X2eBFjvemK4jQbGb68hX AAAAAAAA --------------ms090308010402040603030003-- From nobody Fri Sep 2 06:01:06 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C65112D805 for ; Fri, 2 Sep 2016 06:01:05 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMK-NWraLI66 for ; Fri, 2 Sep 2016 06:01:02 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F20D12D7F8 for ; Fri, 2 Sep 2016 06:01:01 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id p41so64610661lfi.1 for ; Fri, 02 Sep 2016 06:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H0+Mzv+vYfEGMWJG1iq122XSfMo5cF7j4Mnyzd7lTiM=; b=xbpEC3eqC+2T/K/kcPQt6/PbceJsgH2nDalJN9cwMN2B05RtxxA3bT+h9a4NVxSUNK jVa7W+IdpuHWv43bltI/yw8SDFHZE7vNL4X2LjTUnNPE66ofkyI9Y6tl5oCHcdotPldQ AIPz+qhcyoNbm3wVuCY0t02Ev7wbwXbs+icwB5HTauEvqgCUB+Zk2uZU0Owr1a/3QlTZ cE2nFYUfH2PAE6CbO86iPb5PquvrGFdlAnlu+h/3EkfKb3A3DkxoRWS2jTVYCA2NqTKR 3O8QKeuTo0rFi/Q76CM6imozwd++U8qLCxSc1eemIL4t45mBLF9juJpkbLXNxwUR//rJ CROA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H0+Mzv+vYfEGMWJG1iq122XSfMo5cF7j4Mnyzd7lTiM=; b=OabZHU1aS4A0/CZof8DmrxRrHR4xULAHQKaXXMM8zkEdZiWBigW42ICrq+AQpV/aQP YVML+9miCjPzUO1goSz6S8ocwrIInxmrlY2MOxGhjHYCLCJNm/HufZoKFkr6UjiA8W0L K0ZeHhlIGVjvAh1dinEC/OOptyi7oEDlsJvYvYQJDMu4xmDzJFfrHg1u4bU8Vq+96tYF M+Zi+zzpb51906+1sDU8RAzVx+5s+EmQe5SX7F5jRXKkzoGko0llFpQs2tYLKKUhy9Zq 4quHD5VAt46vP6sk/y0/ump6SFRPba9s0Dq+QBgZUKZcuZPv5vw0ekrGM6P6ek7a4a26 ZAeA== X-Gm-Message-State: AE9vXwOmXLCGZnAkmuEl4EETWBQuw+Rl0f1P+ykjWh4Pp+zFotzAHl388OJhWAHGL6yGP5myGMaAigmxoDghJg== X-Received: by 10.25.210.80 with SMTP id j77mr6397293lfg.139.1472821259510; Fri, 02 Sep 2016 06:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Fri, 2 Sep 2016 06:00:18 -0700 (PDT) In-Reply-To: <5438a675-7545-0768-8a70-cedc45e30422@cs.tcd.ie> References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> <5438a675-7545-0768-8a70-cedc45e30422@cs.tcd.ie> From: Ted Lemon Date: Fri, 2 Sep 2016 09:00:18 -0400 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11400ee6fdbfb1053b85eb4b Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] introduction X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:01:05 -0000 --001a11400ee6fdbfb1053b85eb4b Content-Type: text/plain; charset=UTF-8 The point is that in the case of DHCP opportunistic security, I think that the cases where you could use an introduction mechanism are cases where it would reduce, not enhance security. A way of ensuring that your rogue server wins the fight is not what we are trying to achieve here. On Fri, Sep 2, 2016 at 8:54 AM, Stephen Farrell wrote: > > > On 02/09/16 13:40, Ted Lemon wrote: > > I'm sorry, but you guys are getting distracted by the shiny tech. > > No. The QR code thing is just an example mechanism. > > The interesting bit is the general problem of introduction. > > (And how we all constantly side-track discussion of that > because there're so many dimensions to the problem;-) > > S. > > > A QR > > code is a way to _ensure_ that the rogue DHCP server gets to pwn you, > not a > > way to protect you from a rogue DHCP server. If I want to attack > everyone > > in a Starbucks, all I have to do is set up my rogue server and paste a > > nicely printed QR code over the one that's up, while the barista is > making > > my quad three-pump glatte. > > > > On Fri, Sep 2, 2016 at 1:58 AM, Randy Bush wrote: > > > >> [ in yokohama, i was asked to help with with the dhcp6 draft. i was a > >> fool to agree. will not make same mistake again. } > >> > >> but this is of interest to me. i think of the space as 'introduction' > >> and it is a large and deep problem across many protocols. > >> > >>> For a Starbucks environment I can see a placard at the desk that has > >>> the fingerprint of the local DHCP server. So if the software says "do > >>> you trust this?" (ala SSH) then there is some reason to believe that > >>> users would have something to compare it to. > >> > >> we started experimenting in this space at work, where wifi passwords are > >> changed monthly (don't ask), and are quite long and painful. qr-codes > >> pasted on wall were the favorite. > >> > >> i am less comfortable with scanning a qr code in a coffee shop. but i > >> would hope that, if we started using qr codes in this space, we would > >> develop scanware with which we could be comfortable. > >> > >> randy > >> > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > >> > > > > > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > > > --001a11400ee6fdbfb1053b85eb4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The point is that in the case of DHCP opportunistic securi= ty, I think that the cases where you could use an introduction mechanism ar= e cases where it would reduce, not enhance security. =C2=A0 A way of ensuri= ng that your rogue server wins the fight is not what we are trying to achie= ve here.

On = Fri, Sep 2, 2016 at 8:54 AM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:


On 02/09/16 13:40, Ted Lemon wrote:
> I'm sorry, but you guys are getting distracted by the shiny tech.<= br>
No. The QR code thing is just an example mechanism.

The interesting bit is the general problem of introduction.

(And how we all constantly side-track discussion of that
because there're so many dimensions to the problem;-)

S.

> A QR
> code is a way to _ensure_ that the rogue DHCP server gets to pwn you, = not a
> way to protect you from a rogue DHCP server.=C2=A0 =C2=A0If I want to = attack everyone
> in a Starbucks, all I have to do is set up my rogue server and paste a=
> nicely printed QR code over the one that's up, while the barista i= s making
> my quad three-pump glatte.
>
> On Fri, Sep 2, 2016 at 1:58 AM, Randy Bush <randy@psg.com> wrote:
>
>> [ in yokohama, i was asked to help with with the dhcp6 draft.=C2= =A0 i was a
>>=C2=A0 =C2=A0fool to agree.=C2=A0 will not make same mistake again.= }
>>
>> but this is of interest to me.=C2= =A0 i think of the space as 'introduction'
>> and it is a large and deep problem across many protocols.
>>
>>> For a Starbucks environment I= can see a placard at the desk that has
>>> the fingerprint of the local DHCP server.=C2=A0 So if the soft= ware says "do
>>> you trust this?" (ala SSH) then there is some reason to b= elieve that
>>> users would have something to compare it to.
>>
>> we started experimenting in this space at work, where wifi passwor= ds are
>> changed monthly (don't ask), and are quite long and painful.= =C2=A0 qr-codes
>> pasted on wall were the favorite.
>>
>> i am less comfortable with scanning a qr code in a coffee shop.=C2= =A0 but i
>> would hope that, if we started using qr codes in this space, we wo= uld
>> develop scanware with which we could be comfortable.
>>
>> randy
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag >


--001a11400ee6fdbfb1053b85eb4b-- From nobody Fri Sep 2 06:12:10 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43012D839 for ; Fri, 2 Sep 2016 06:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdjlkRu1N1-S for ; Fri, 2 Sep 2016 06:12:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F85C12D5DB for ; Fri, 2 Sep 2016 06:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24300BE2C; Fri, 2 Sep 2016 14:12:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV87jzjzQpwp; Fri, 2 Sep 2016 14:11:57 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E4470BDD0; Fri, 2 Sep 2016 14:11:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472821917; bh=8O3L6Ly1eG4L0QgeW6j7HYas+C3fx8/lIPuMEcyIahc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=GlLwJCvDNP3Ly/s6cjEC3OiXtIqZuWHsN/UHvNXlU9viwdaRw+DpNZvwLaqtl4grm OLru37nzb33w7LAeCT0SBP4RABbg79gh1QXLTR2YVvCWAf8O6xkuhbVT8uIGVLUfLS HFcW7ljTyo80Sipc1zfMUECV1vjmNndalFH3NhyE= To: Ted Lemon References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> <5438a675-7545-0768-8a70-cedc45e30422@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 2 Sep 2016 14:11:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030602080204040107080701" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] introduction X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:12:09 -0000 This is a cryptographically signed message in MIME format. --------------ms030602080204040107080701 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/09/16 14:00, Ted Lemon wrote: > The point is that in the case of DHCP opportunistic security, I think t= hat > the cases where you could use an introduction mechanism are cases where= it > would reduce, not enhance security. =20 I'm assuming Randy changed the subject line to change the subject though:-) While I am a fan of OS for DHCP, that's just one small part of the bigger issue. For example, introducing a new homenet router is part of the story here and may have subtly different issues compared to DHCP alone. But public key retrieval for secure interpersonal messaging (e.g. PGP/SMIME or IM) also has introduction problems. That said, I don't actually agree with you about key continuity but I'll answer that mail directly. S, > A way of ensuring that your rogue > server wins the fight is not what we are trying to achieve here. >=20 > On Fri, Sep 2, 2016 at 8:54 AM, Stephen Farrell > wrote: >=20 >> >> >> On 02/09/16 13:40, Ted Lemon wrote: >>> I'm sorry, but you guys are getting distracted by the shiny tech. >> >> No. The QR code thing is just an example mechanism. >> >> The interesting bit is the general problem of introduction. >> >> (And how we all constantly side-track discussion of that >> because there're so many dimensions to the problem;-) >> >> S. >> >>> A QR >>> code is a way to _ensure_ that the rogue DHCP server gets to pwn you,= >> not a >>> way to protect you from a rogue DHCP server. If I want to attack >> everyone >>> in a Starbucks, all I have to do is set up my rogue server and paste = a >>> nicely printed QR code over the one that's up, while the barista is >> making >>> my quad three-pump glatte. >>> >>> On Fri, Sep 2, 2016 at 1:58 AM, Randy Bush wrote: >>> >>>> [ in yokohama, i was asked to help with with the dhcp6 draft. i was= a >>>> fool to agree. will not make same mistake again. } >>>> >>>> but this is of interest to me. i think of the space as 'introductio= n' >>>> and it is a large and deep problem across many protocols. >>>> >>>>> For a Starbucks environment I can see a placard at the desk that ha= s >>>>> the fingerprint of the local DHCP server. So if the software says = "do >>>>> you trust this?" (ala SSH) then there is some reason to believe tha= t >>>>> users would have something to compare it to. >>>> >>>> we started experimenting in this space at work, where wifi passwords= are >>>> changed monthly (don't ask), and are quite long and painful. qr-cod= es >>>> pasted on wall were the favorite. >>>> >>>> i am less comfortable with scanning a qr code in a coffee shop. but= i >>>> would hope that, if we started using qr codes in this space, we woul= d >>>> develop scanware with which we could be comfortable. >>>> >>>> randy >>>> >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>>> >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>> >> >> >=20 --------------ms030602080204040107080701 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDIx MzExNTZaMC8GCSqGSIb3DQEJBDEiBCCSsRTDFrZkZiOmj8GZrjo8ja88KLaMHd4os6BbsFFf 1TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAJPsPU7K9uklZIbJSKq8G/7+E7FQ0rpTIOFlCj+BxmZHdt5uY2T8OP Xp3C0h3UDykMzYq9ezBV0jSQ0EGmFhg9NcoB/KFelwQc1LY4BnTE3ujYUpFw3AVkB1Twf7xB SueJbMziihYEwBvblFOrz/Jvabo6HrH21gtqD5PpE+cdicb6qGnEl2YOBntlG9VTGKifXjxX HwiR4mMfkjLyF7XIEG5dJt2zplLw3StJSmWPbVpwOcy4x6TIVPLd5zf2MUMeqR0YoyVueGxR nkXowwVwVwolxPHA79YglO48C1ISvxoXmIgZJRnyw0A/0o61g36T9cZPsvFiI7cJwzVDA75s AAAAAAAA --------------ms030602080204040107080701-- From nobody Fri Sep 2 06:17:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4912B028 for ; Fri, 2 Sep 2016 06:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-VQZS12nhYl for ; Fri, 2 Sep 2016 06:17:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1971412D849 for ; Fri, 2 Sep 2016 06:17:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BAD4ABE35; Fri, 2 Sep 2016 14:17:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48qunBFxwcF1; Fri, 2 Sep 2016 14:17:20 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1430ABE2C; Fri, 2 Sep 2016 14:17:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472822240; bh=KEvl8TKapIIE+6AxedHzWi2HtVXS0u29gOg/vXKe51s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=n0edSSUzSQafP84xWa9sNkXrpIgZZMZBYsk+ZaPodYvJA68PVGjw8I4OPxCeV5Kvn xI2ChC6BoIGIOvr3KFUU79EghzGH4wSlCF/6E2kfy4+f99S/xHCOhs4kjRnz6qjtuW NVqNw6SZtnG2dPtEC4yKjDVcVFTBW9wme7vannhk= To: Ted Lemon , Security Area Advisory Group References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <72fcc068-c825-e545-d5dd-475c71cacd32@isi.edu> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 2 Sep 2016 14:17:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050306080601020805060605" Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:17:25 -0000 This is a cryptographically signed message in MIME format. --------------ms050306080601020805060605 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted, On 02/09/16 13:30, Ted Lemon wrote: >> > Would TACK be a practical approach to reducing key rotation false >> > alarms? >=20 > Keys should never, ever be rotated for ToFU. Server identities are no= t > precious. If you want to rotate keys, change both the key and the > identity. I very much disagree. Having taken the LoF I do think there is benefit in allowing key continuity (maybe via something like TACK) in cases like the home router for an advanced user. While rolling to new keys in those scenarios isn't that huge a priority, we've seen with SSH that the inability to roll keys leads eventually to badness and I can't see a reason why that'd be different here. And I'm not sure what "identity" you mean in the case of a DHCP server. If the identifier is the server's IP address then that may not be easily changed. Or is there some other DHCP identifier you meant? S. >=20 >=20 --------------ms050306080601020805060605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDIx MzE3MTlaMC8GCSqGSIb3DQEJBDEiBCB7WSo/20XLRlXPuALw4R+CxWacyRXTRmQ4n5EW6gvS CjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAaev+/KSLcq67Yp7OHsLmBWJi+cQTp4nLyeIydiMfMAReCLsGsneFK AscE7HpmvyNrnRglAoaKOgtlzgiOyyxm5PSi+qnbaxOf2uH7xNC/HAZK4cgjj1kNd8VVSvMJ SDeTI0aWijBNAbawMZ5u0Z6iGJoFgOYXUANDfZlXsiY31eJvDr9mvShM9o3PbSQGN2g1Dh/+ gOLpB8v3aGC4eRG8pFL9A7Y05g8QHNVG8SnSHR9yKagB2p7uxnWL39ktxr/ohO012VRH7sXm 4Z59imkj0Lg/nwC2T7irYQGhvsGJHqeKdNRfFipIKLdbG6V21AKOUTldXfSq7YP8eQck1eet AAAAAAAA --------------ms050306080601020805060605-- From nobody Fri Sep 2 06:18:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CFA12D84E for ; Fri, 2 Sep 2016 06:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgORl9XzPOF6 for ; Fri, 2 Sep 2016 06:18:02 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 65DF612D84D for ; Fri, 2 Sep 2016 06:18:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 80D97A6F; Fri, 2 Sep 2016 13:18:01 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9T4oz0HkLYL; Fri, 2 Sep 2016 13:18:01 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 15F0D167; Fri, 2 Sep 2016 13:18:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 2 Sep 2016 09:18:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:18:04 -0000 On Sep 1, 2016, at 9:45 PM, Ted Lemon wrote: > Securing DHCP helps. But wouldn't it be nice to know that the = organization who granted you network access also granted you network = credentials? i.e. IP addresses? >=20 > There are several unwarranted assumptions in this question: > =E2=80=A2 you've been explicitly, not implicitly, granted access = to the network There are, of course, cases where network access is open and = unauthenticated. In those cases, authenticating the DHCP server doesn't = add a lot of security. > =E2=80=A2 the operator of layer 2 is also the operator of the = DHCP server I would wager that where 802.1X is deployed, 99.9% of the time, the = 802.1X and DHCP operators communicate with each other. The = *implementations* may not, but the operators do. > Yup. I think we agree that when it's possible to bootstrap both = layer 2 and layer 3 using the same keying infrastructure, that's the = right thing to do. My point is that once layer 2 is bootstrapped, we can bootstrap layer = 3 off of that. > I never use 802.1x at all in my daily life. The only time I've ever = seen it deployed is at IETF and at my company's office in Redwood City, = where, I hasten to add, it works so poorly that I sometimes use the = guest network, or the wired network, which does not use 802.1x. Get better IT people / software, then. EDUROAM uses 802.1X to authenticate millions of people, dozens of = times a day each. It's deployed world-wide. It works with all known = end-user equipment. I'm personally aware of companies who have 8K+ = switches, where all public ports (non server room) are 100% 802.1X. There is no *technical* reason why 802.1X can't work. > I think those are very much the exception in terms of real-world DHCP = usage. In order to justify the rather massive effort that would be = involved in making this work for DHCP, a) write a standard to derive a DHCP key from the 802.1X = authentication b) implement that in DHCP clients and servers. It's not conceptually complex. The code isn't even that difficult. = Maybe a few thousand lines on each of client / server. There is no = technical reason why this can't work. > the first question I would ask is, do you actually need to = authenticate the client again if you are using 802.1x? I think the = answer is a resounding no. That's not what I'm proposing. I'm proposing that the client get a secure introduction to the DHCP = server. So that it knows it's not being spoofed. > I think if the IETF developed a solution to this problem, exactly = zero people would deploy it. If you think that's not the case, do you = know of people who are clamoring for this feature? People aren't clamouring for it because either they don't know it's a = problem, or they get told it's impossible. When I explain my proposal, = most people using 802.1X go "Yeah, that would add to security. I'd use = that if it was available". Make no mistake, many large organizations have IT people who are = desperate for new features... but who aren't allowed out of their little = silos. They don't talk to vendors, and they definitely don't show up to = IETF. > Sure. Use the same cert to identify both the 802.1x server and the = DHCP server. Done. You don't need to use ToFU for this use case, and = I don't think you should. There are good reasons to *not* use the same cert for multiple = applications. Using the same CA infrastructure is a better idea. Alan DeKok. From nobody Fri Sep 2 06:26:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0912D869 for ; Fri, 2 Sep 2016 06:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ1_zqf_MePz for ; Fri, 2 Sep 2016 06:26:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E5912D853 for ; Fri, 2 Sep 2016 06:26:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8708FBE29; Fri, 2 Sep 2016 14:26:23 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7bYgZ49Md3T; Fri, 2 Sep 2016 14:26:22 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E2E2ABE32; Fri, 2 Sep 2016 14:26:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472822782; bh=seFZlr2g8RV7BLlBX1OL3Km28cAL981qGKnf8xImw6U=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=pUA3qlH43K77mpqqVKPwtgpyUjh9sSnn+erauKWjPiFkMAozFTsAor/Usbx/QmP7k F7NHovwhNRbwIo3Q7A57HEEcSLQAp28GfyxxhGdleYOsEqMPv65vfNztsyP4YWSZ4R ggKpJu/2DjeyiAXcy4XurXZeyHzUIrznyc69K864= To: Alan DeKok , Ted Lemon References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 2 Sep 2016 14:26:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030201030702000700000501" Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:26:27 -0000 This is a cryptographically signed message in MIME format. --------------ms030201030702000700000501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alan, On 02/09/16 14:18, Alan DeKok wrote: > a) write a standard to derive a DHCP key from the 802.1X authenticati= on > b) implement that in DHCP clients and servers. I think that'd also be a fine thing if someone is willing to do the work. I don't think it means that there's anything wrong with doing this work on DHCP as well. We should not get in the way of folks who want to define useful things just because we have a different (maybe better, maybe not) idea, and especially if we don't have the cycles to bring our different idea to fruition. If one were to argue that ToFU security for DHCP were a negative that's different of course. (As Randy does for example.) S. --------------ms030201030702000700000501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDIx MzI2MjFaMC8GCSqGSIb3DQEJBDEiBCAq4FOEfK8gE30cnnnCZg1beVqHdH5Yzqn/zviE7Gtc QDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBmXnl1Np7cT3Wxu9joUOKns64S5iAQ3S/HnQk7zhbDI8/pfYUeBjLc 5UzsuHzHhfs9mVCXaD5T8zuvaoM2Tr6ykb09YTutexzEz0Plv37VQ7NhomVWSCEmulMK+rG+ gCbKaZkmq1zDz+TXIYPPt0vLb25Zaxi0h7XCsB5jN8EwIZpcZD1TTc/iqNsRlHU9PCQ5qnYj c8o4mf7iYfqhtBoO/r9RvcQ/4BJhXux4grYY+R1iISzcJKjYwTCRpnBieft01eLdYeDPYa60 ff78Ou1TAmiVbxrbS3ematnOA+Wzzeeb2mH+Lt9J6VvRl41y2daFFVE4n/yEJ6m8LwUEi6d9 AAAAAAAA --------------ms030201030702000700000501-- From nobody Fri Sep 2 06:37:52 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6974A12D88C for ; Fri, 2 Sep 2016 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZYk-6DjHQnI for ; Fri, 2 Sep 2016 06:37:50 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5E10B12D852 for ; Fri, 2 Sep 2016 06:37:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 7F6511E7F; Fri, 2 Sep 2016 13:37:49 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMuM_8A0WFzF; Fri, 2 Sep 2016 13:37:49 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id E7147A6F; Fri, 2 Sep 2016 13:37:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 2 Sep 2016 09:37:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:37:51 -0000 On Sep 2, 2016, at 9:26 AM, Stephen Farrell = wrote: > On 02/09/16 14:18, Alan DeKok wrote: >> a) write a standard to derive a DHCP key from the 802.1X = authentication >> b) implement that in DHCP clients and servers. >=20 > I think that'd also be a fine thing if someone is willing to do the > work. Consider it done. Alan DeKok. From nobody Fri Sep 2 06:51:37 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC812D512 for ; Fri, 2 Sep 2016 06:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YEMBQftWnqY for ; Fri, 2 Sep 2016 06:51:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB1612D53B for ; Fri, 2 Sep 2016 06:51:35 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 84907635C6; Fri, 2 Sep 2016 13:42:37 +0000 (UTC) Received: from bofh7.nohats.ca (vpn-231-6.phx2.redhat.com [10.3.231.6]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u82DgbOd003172; Fri, 2 Sep 2016 09:42:37 -0400 To: Joe Touch , kathleen.moriarty.ietf@gmail.com, saag@ietf.org References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> From: Paul Wouters Message-ID: <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> Date: Fri, 2 Sep 2016 09:42:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 02 Sep 2016 13:42:37 +0000 (UTC) Archived-At: Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:51:36 -0000 On 08/13/2016 11:35 AM, Joe Touch wrote: > b) IMO, the Linux code is just (and yet another) bug based on an > incorrect read of RFC 5961, not worthy of even an errata There is a fine line between incorrect reading and confusing specification. I would assume the Linux code went through several reviews at least, as this is not some basement developed OS. Therefore, I would disagree with "not worthy of even an errata". Paul From nobody Fri Sep 2 06:53:20 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939E012D8AB for ; Fri, 2 Sep 2016 06:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aozCNZErL8Ik for ; Fri, 2 Sep 2016 06:53:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5DF12D53B for ; Fri, 2 Sep 2016 06:53:17 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 38E5D81243; Fri, 2 Sep 2016 13:53:17 +0000 (UTC) Received: from bofh7.nohats.ca (vpn-231-6.phx2.redhat.com [10.3.231.6]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u82DrGdu027130; Fri, 2 Sep 2016 09:53:16 -0400 To: Ted Lemon , Randy Bush References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <232bd6e5e683928b2af65be8096f8b87.squirrel@mail2.ihtfp.org> From: Paul Wouters Message-ID: <7719717d-1af2-e977-d042-389df8d78f3a@redhat.com> Date: Fri, 2 Sep 2016 09:53:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 02 Sep 2016 13:53:17 +0000 (UTC) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] introduction X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:53:18 -0000 On 09/02/2016 08:40 AM, Ted Lemon wrote: > I'm sorry, but you guys are getting distracted by the shiny tech. A QR > code is a way to _ensure_ that the rogue DHCP server gets to pwn you, not a > way to protect you from a rogue DHCP server. If I want to attack everyone > in a Starbucks, all I have to do is set up my rogue server and paste a > nicely printed QR code over the one that's up, while the barista is making > my quad three-pump glatte. The coffee shop should not require any trust. I neither trust their clientele or the actual network owners. Whether DHCP or DNS or HTTP. Coffee shop passwords are not for your security, They are to keep people on the streets from using shop resources without buying a pumpkin spice latte. Similarly, a hotspot landing page is not there to provide security or waive liability, It is there for the shop to provide you with their advertisements. Next, trust your local ISP as much as the coffee shop :) Paul From nobody Fri Sep 2 06:55:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F9112D512 for ; Fri, 2 Sep 2016 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.45 X-Spam-Level: X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIG3HXaM-phO for ; Fri, 2 Sep 2016 06:55:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438D212D1C8 for ; Fri, 2 Sep 2016 06:46:40 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 70AE4C00F0AA; Fri, 2 Sep 2016 13:38:09 +0000 (UTC) Received: from bofh7.nohats.ca (vpn-231-6.phx2.redhat.com [10.3.231.6]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u82Dc8AX016683; Fri, 2 Sep 2016 09:38:08 -0400 To: Tero Kivinen , Warren Kumari References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> From: Paul Wouters Message-ID: <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> Date: Fri, 2 Sep 2016 09:38:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: <22470.49542.85452.748009@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 02 Sep 2016 13:38:09 +0000 (UTC) Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:55:33 -0000 On 08/31/2016 07:37 AM, Tero Kivinen wrote: > Warren Kumari writes: >> Seriously, please review -- it is short, and (I believe) a really good idea. >> This gets you (unauthenticated) encryption wherever people use "open" >> Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), >> coffeeshops, airports, etc. >> Now, like much opportunistic stuff, it doesn't protect against active >> attacker - but it does force the attacker to be active (and many >> controller based wifi deployments will notice and try protect against >> "rouge APs"). So at the coffe eshop, where everybody knows (my name) the essid and the password, do I not get protection against passive attacks already? How much harder are we actually making it for the attacker to switch from attacking this WPA-PSK with known psk to OWA? Since we are not even causing the attacker to go from passive to active if I understand things correctly (which I might not, as I'm not very knowledgeable with IEEE protocols) > This protocol seems to be using IKEv2 IANA registry, but the protocol > does not look like IKEv2, so I think you should fix that by replacing > the protocol and just reuse IKEv2 in OWE, > IANA registries are cheap, there is no point of reusing registries for > something that are not releated to the original intention of the > registry. I agree with Tero that you should probably not use the IKE registry. You could make your own. If you really want IKEv2 Opportunistic IPsec, I gave a demo last week at the Linux Security Summit, using IKEv2 with anonymous clients to letsencrypt based server authentication. http://events.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf Code and install instructions while not yet merged in upstream: https://nohats.ca/LE/ Demo server available: letsencrypt.libreswan.org Next step for Opportunistic IPsec is DNSSEC based authentication. Paul From nobody Fri Sep 2 06:59:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940BF12D8AD for ; Fri, 2 Sep 2016 06:59:16 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTiCpxkfdqIm for ; Fri, 2 Sep 2016 06:59:14 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112B212D8A9 for ; Fri, 2 Sep 2016 06:59:14 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id g62so84260370lfe.3 for ; Fri, 02 Sep 2016 06:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t5daQgWc6IlZhqOixXQgmEZkxCIiF+sjzODU5TCFE2g=; b=QKqvRKJdZQfLxosVwftrd1+YlgtSFrjlIaMBShnbAW4G9fxCQ7I/YXMQ/RIteRgeOY PvM+JZKZL2+Wzozl/rjXE88xb7ZwYbh3CTPBCbqPX8cNhqorwpQ6e8hs9b54B7ab9ScE F1R17UOAjzAnTJ2N1G8CiDRkuKDcjkO2nMbxiugo1TFs9ja+LUdi5YS8b28RjW5VR2ad Ahhhpsnfk387j2XZIKE/+H2fw1a5UcIyXGRvqGxXUUxRPJQiBDfc3mezyNCsc7hhoJdL hE7ocfdTM6+8S1dtHH9nOPvrWwI+P/Mqabpnrc8aq1Kom7mxQyMSBhXQrR619pRb24nJ g1pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t5daQgWc6IlZhqOixXQgmEZkxCIiF+sjzODU5TCFE2g=; b=EdwTxExmGtkqBJCaYmHtHWRgm7AU0gDxVppfW1QT8ZljaCyKV14fhZzOqpV9ws2lCY 9TfPkalPHhJn0vqsmSKWc9frlUysaoykswjli+WrgcB+H782fU9GRzlwEM9rO1rgDPeE C/A8pC6ProVgrKYKl/y9tZHzLxWMQhpUBV6g/oAGcsIDccaeHycx5nCWB/93Xx7EFX9+ 7J3MWPTCxt66nyD1Es/ZnEkBSzuPXPJoUNYItZzgzRksJYlx2g6bredWzxvwb2MFbG5f iWXCYlsoyDCfsscy33OvSIpo+bgfvJcpbv0dB7XEfwdDUymxQ6dejkj9eTBTKeWZmPnW IIGg== X-Gm-Message-State: AE9vXwOb7GBbdzGHUs9KeuHrXSe+ylcYXFfMxSv5NCoVo2MQIrRh0qdMosoFOzCaV/oiGpuc5kI5YqcaVTFrWQ== X-Received: by 10.46.5.196 with SMTP id 187mr6732315ljf.13.1472824751833; Fri, 02 Sep 2016 06:59:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Fri, 2 Sep 2016 06:58:30 -0700 (PDT) In-Reply-To: References: <205D8AF9-5C9B-4E9A-B060-1C662C26C010@deployingradius.com> From: Ted Lemon Date: Fri, 2 Sep 2016 09:58:30 -0400 Message-ID: To: Security Area Advisory Group Content-Type: multipart/alternative; boundary=001a114a6bea265f43053b86bc9a Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 13:59:16 -0000 --001a114a6bea265f43053b86bc9a Content-Type: text/plain; charset=UTF-8 Alan, I think what's going on here is simply that the world looks very different depending on where you sit. If you think it's worth solving the 802.1x:DHCP keying problem, I'm certainly interested in helping you to make that happen. But it feels somewhat orthogonal to this effort, unless there's a way to link them using PKI. And I will point out that many have died on that hill in the past--you are not the first person to want to do this, and one of the reasons I'm skeptical is that I've seen it tried before. I recommend you talk to Alper Yegin about it. On Fri, Sep 2, 2016 at 9:37 AM, Alan DeKok wrote: > On Sep 2, 2016, at 9:26 AM, Stephen Farrell > wrote: > > On 02/09/16 14:18, Alan DeKok wrote: > >> a) write a standard to derive a DHCP key from the 802.1X authentication > >> b) implement that in DHCP clients and servers. > > > > I think that'd also be a fine thing if someone is willing to do the > > work. > > Consider it done. > > Alan DeKok. > > --001a114a6bea265f43053b86bc9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan, I think what's going on here is simply that the = world looks very different depending on where you sit. =C2=A0 If you think = it's worth solving the 802.1x:DHCP keying problem, I'm certainly in= terested in helping you to make that happen. =C2=A0 But it feels somewhat o= rthogonal to this effort, unless there's a way to link them using PKI. = =C2=A0 And I will point out that many have died on that hill in the past--y= ou are not the first person to want to do this, and one of the reasons I= 9;m skeptical is that I've seen it tried before. =C2=A0 I recommend you= talk to Alper Yegin about it.

On Fri, Sep 2, 2016 at 9:37 AM, Alan DeKok <ala= nd@deployingradius.com> wrote:
On Sep 2, 2016, at 9:26 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wr= ote:
> On 02/09/16 14:18, Alan DeKok wrote:
>>=C2=A0 a) write a standard to derive a DHCP key from the 802.1X aut= hentication
>>=C2=A0 b) implement that in DHCP clients and servers.
>
> I think that'd also be a fine thing if someone is willing to do th= e
> work.

=C2=A0 Consider it done.

=C2=A0 Alan DeKok.


--001a114a6bea265f43053b86bc9a-- From nobody Fri Sep 2 08:16:49 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD4F12D1D3 for ; Fri, 2 Sep 2016 08:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eXFyIAoedcB for ; Fri, 2 Sep 2016 08:16:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F612D1BD for ; Fri, 2 Sep 2016 08:16:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 73D06284D96; Fri, 2 Sep 2016 15:16:44 +0000 (UTC) Date: Fri, 2 Sep 2016 15:16:44 +0000 From: Viktor Dukhovni To: Security Area Advisory Group Message-ID: <20160902151644.GT4670@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 15:16:47 -0000 On Fri, Sep 02, 2016 at 08:30:59AM -0400, Ted Lemon wrote: > > What this means for TOFU with DHCP is that mere > > key pinning should not be a blanket, on by default mechanism. If > > the feature cannot be made essentially unnoticeable to users, it must > > be off by default, and enabled by knowledgeable users only in appropriate > > circumstances. > > This is not at all what we are talking about here. We are in fact > assuming that a given DHCP server identity will be protected by the same > key forever. If you want to use a new key, you should use a new identity, > to avoid key pinning. This is a key point that I missed, which may have > led us down this branch of the discussion. You do not want to ever have a > new key for the same server identity, because doing so will produce exactly > the bad outcome you are concerned about, and would add no value at all. Thing is, users have no knowledge of (or reason to know) which DHCP server is legitimate for a given network. Thus the "identity" you speak of is meaningless, the user is connecting to a given network, not to a given DHCP server, all that matters is the underlying key. It does the user no good to be able authenticate the last DHCP server they used if they start cold when they see a new one. The whole point is to not trust a new one if one has acquired and "pinned" DHCP key material for the network in question. > For ToFU, the thing that I think you took for key pinning is simply a key > caching heuristic that does not require user involvement to be useful. If > I get a DHCP message signed by a key that I previously cached, and there > were no problems with the previously-cached key, then I will prefer that > DHCP server over another DHCP server that also responded either using no > authentication, or using a key that I have not cached. So the attacker just has to block messages from the preferred DHCP server for a few seconds, and he wins. > > Would TACK be a practical approach to reducing key rotation false > > alarms? > > Keys should never, ever be rotated for ToFU. Server identities are not > precious. If you want to rotate keys, change both the key and the > identity. It seems to me that allowing transparent changes of the identity largely defeats any potential benefit of TOFU for DHCP. Given that keys don't last forever, the issue must be given some attention. On Fri, Sep 02, 2016 at 02:17:19PM +0100, Stephen Farrell wrote: > > Keys should never, ever be rotated for ToFU. Server identities are not > > precious. If you want to rotate keys, change both the key and the > > identity. > > I very much disagree. > > Having taken the LoF I do think there is benefit in allowing key > continuity (maybe via something like TACK) in cases like the home > router for an advanced user. While rolling to new keys in those > scenarios isn't that huge a priority, we've seen with SSH that the > inability to roll keys leads eventually to badness and I can't see > a reason why that'd be different here. > > And I'm not sure what "identity" you mean in the case of a DHCP > server. If the identifier is the server's IP address then that > may not be easily changed. Or is there some other DHCP identifier > you meant? Ditto, I don't see how a fluid identity avoids defeating all benefit from TOFU. -- Viktor. From nobody Fri Sep 2 08:48:49 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC89D12D4FB for ; Fri, 2 Sep 2016 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcJNWAgahdhS for ; Fri, 2 Sep 2016 08:48:47 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F0B12D155 for ; Fri, 2 Sep 2016 08:48:47 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u82FmBFw019710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 Sep 2016 08:48:12 -0700 (PDT) To: Paul Wouters , kathleen.moriarty.ietf@gmail.com, saag@ietf.org References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> From: Joe Touch Message-ID: <8dc311fa-cca3-073a-418b-2ab1d1f8563a@isi.edu> Date: Fri, 2 Sep 2016 08:48:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 15:48:49 -0000 On 9/2/2016 6:42 AM, Paul Wouters wrote: > On 08/13/2016 11:35 AM, Joe Touch wrote: > >> b) IMO, the Linux code is just (and yet another) bug based on an >> incorrect read of RFC 5961, not worthy of even an errata > There is a fine line between incorrect reading and confusing specification. I agree and I think Mirja's solution seems reasonable: >> To me this does not seem to be a case for an errata. For sure some >> clarification seems to be helpful here but that's not what erratas >> are for. >> >> Therefore, I would suggest to simply set this into "Held for Document >> Update" state such that it is noticed in case we decide to update the >> document at some point. Does that make sense? > I would assume the Linux code went through several reviews at least, as this > is not some basement developed OS. Linux is an "accept first, have many eyes check later" system - that's why it supports so many peripherals, but also why it was once released with code that failed to atomically update the file system tree (i.e., if the system went down while an update was in process, the file system was destroyed). IMO, your statement is reasonably true for FreeBSD, but Linux *is* the counterexample. I don't know where Linus whether he his code in a literal basement, but it was "after a period of self-imposed isolation and intense concentration" (http://www.linfo.org/linus.html). A good example - I have two students currently adding options (TCP EDO and UDP option space). These students - first-timers to kernel editing - BOTH found legitimate bugs in the Linux code for their transport protocols. The IETF doesn't have the time or resources to clutter the RFC series with errata to address the variety and number of ways in which Linux over-eagerly accepts community code without appropriate review. We need to decide whether these sorts of errors are driven by real errors in the doc or whether we're just over-specifying the infinite ways to go outside the documented spec. Joe From nobody Fri Sep 2 08:57:49 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ABD12D850 for ; Fri, 2 Sep 2016 08:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.447 X-Spam-Level: X-Spam-Status: No, score=-7.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da_io5dB6PlH for ; Fri, 2 Sep 2016 08:57:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DED712D4FB for ; Fri, 2 Sep 2016 08:57:46 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u82FvLIk020881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 Sep 2016 08:57:22 -0700 (PDT) To: Security Area Advisory Group References: <0999878f-fb45-7701-fd14-e5f990a42d62@isi.edu> <7223f593-1f7a-cbc8-5f4b-3a9da8f37e11@isi.edu> <72fcc068-c825-e545-d5dd-475c71cacd32@isi.edu> From: Joe Touch Message-ID: <81809e23-ac90-a03f-44c4-cd8ae71039a9@isi.edu> Date: Fri, 2 Sep 2016 08:57:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------34245465F26D27C868B3360A" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 15:57:48 -0000 This is a multi-part message in MIME format. --------------34245465F26D27C868B3360A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/1/2016 10:31 PM, Viktor Dukhovni wrote: >> On Sep 2, 2016, at 12:33 AM, Joe Touch wrote: >> > >> > I understand your position, but disagree exactly because users have many years of experience with the counterexample for matters that have much more direct consequences - namely, Internet commerce. > One might note that Web-based e-commerce is squarely in the world of mandatory, > not opportunistic, security. Again, I won't use the term "opportunistic" because it is insufficiently defined. Security is always based on a particular level of information and trust in that information, whether that information is a key, a crypto algorithm, or a protocol. E-commerce allows for clients with unsigned keys and servers with keys signed by known CAs or unknown CAs, and even servers without keys (yes, there still are such pages floating around). There's no "squarely mandatory" there. It's up to the user whether to use a page without a displayed lock and whether to accept keys whose CAs aren't known and trusted in advance. The e-commerce world does just fine with the user-in-the-loop. DHCP isn't special here. The same kind of lock (maybe server keys can be signed by the same CAs used for the web?) or at least a very similar interface is more than reasonable here, IMO. Joe --------------34245465F26D27C868B3360A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 9/1/2016 10:31 PM, Viktor Dukhovni wrote:
On Sep 2, 2016, at 12:33 AM, Joe Touch <touch@isi.edu> wrote:
> 
> I understand your position, but disagree exactly because users have many years of experience with the counterexample for matters that have much more direct consequences - namely, Internet commerce.

One might note that Web-based e-commerce is squarely in the world of mandatory,
not opportunistic, security.
Again, I won't use the term "opportunistic" because it is insufficiently defined.

Security is always based on a particular level of information and trust in that information, whether that information is a key, a crypto algorithm, or a protocol.

E-commerce allows for clients with unsigned keys and servers with keys signed by known CAs or unknown CAs, and even servers without keys (yes, there still are such pages floating around).

There's no "squarely mandatory" there. It's up to the user whether to use a page without a displayed lock and whether to accept keys whose CAs aren't known and trusted in advance. The e-commerce world does just fine with the user-in-the-loop.

DHCP isn't special here. The same kind of lock (maybe server keys can be signed by the same CAs used for the web?) or at least a very similar interface is more than reasonable here, IMO.

Joe

--------------34245465F26D27C868B3360A-- From nobody Fri Sep 2 09:05:19 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E27512D8D0 for ; Fri, 2 Sep 2016 09:05:18 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7kGtTOkh2Ec for ; Fri, 2 Sep 2016 09:05:16 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2716F12D8CF for ; Fri, 2 Sep 2016 09:05:16 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b199so87223127lfe.0 for ; Fri, 02 Sep 2016 09:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9TbxBSICvv3WTfGqp5bFs73IBLFNu+81wiMKnaqhdg8=; b=hlXq25SQfvv1hVDyzu04H9IhHNV1nnxEkl7qoJGfgrbElJCopYWsHEjWVByPLOtYqG Ltb77yfISm+RA0lHo97YYfdB7coHxzIhEdcRzLQ2aMRheK1k8ac/HAs9B6HOuCyj/PwK XlStop+S2VkQ6jaIT1yLHZuoBdmoT0P6aremhbDI41Soi3zNafrdMCdJLRD/l9+H/APG VTB6XGcqflzad7bxTajPJT1tG86WpS0AfxmpMFC9/SRZBhlg8/R7pXggz/9I1qitOp0v ysofTQj7rK8QIJk/D2FgI4bkCMrpTiRDxp2Re1wk+9ZUqswG8wD2wL6VAYNO8633BPTC QkOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9TbxBSICvv3WTfGqp5bFs73IBLFNu+81wiMKnaqhdg8=; b=PUTacbGV/zkg+G3EAMjHVMfF81oljPQIf/jILpNsjVbxezQc9N3cgeMGBBCAin0qKD CwvXwhjJPEYzhb0jtxz2uLpmMVCoIuEU8ZUYMefd1L4lp16Zf2FkOt2NTgLtrkvMZbxf /Td4NjJFwUD2EvYgOU77LfFLD1bYoZuHYpqi28GDTMTDiSWo6k7/+H5KQwPifTWijYRY KUMtTq+g7oSDRZpuQGwfUlKTzXyA2oe95sg/ugqDtFuDE/qla1F0ocdXlLxil/SqP4ts TOgUGwczDvpl8EQTmGi+P1HW62sx5a+CjZ0gDMXT/aQkf6og96vPjMwCrJNZ1CCvD2It F2uQ== X-Gm-Message-State: AE9vXwMPKMb6pU9ddTrkSFWMuidgb+hbCCya3L/EO2mk2XIAqUvr5trUPflLXRNI/CYFWIJrM5QtX0/KVjUxRw== X-Received: by 10.25.210.80 with SMTP id j77mr6648964lfg.139.1472832313967; Fri, 02 Sep 2016 09:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Fri, 2 Sep 2016 09:04:32 -0700 (PDT) In-Reply-To: <20160902151644.GT4670@mournblade.imrryr.org> References: <20160902151644.GT4670@mournblade.imrryr.org> From: Ted Lemon Date: Fri, 2 Sep 2016 12:04:32 -0400 Message-ID: To: Security Area Advisory Group Content-Type: multipart/alternative; boundary=001a11400ee6e35c96053b887e64 Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:05:18 -0000 --001a11400ee6e35c96053b887e64 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni wrote: > Thing is, users have no knowledge of (or reason to know) which DHCP > server is legitimate for a given network. True. > Thus the "identity" you > speak of is meaningless, the user is connecting to a given network, > not to a given DHCP server, all that matters is the underlying key. > Not true. The identity is the identity of a DHCP server with which the client either has or has not previously communicated. It does the user no good to be able authenticate the last DHCP > server they used if they start cold when they see a new one. The > whole point is to not trust a new one if one has acquired and > "pinned" DHCP key material for the network in question. > This is not quite the right mental model to have for how DHCP works. There is no DHCP server for a network, any more than there is an ssh server for a network. There are zero or more DHCP servers reachable on any particular network. Also, only some networks can be identified as the same network you were on before with the same identifier. E.g., trusting that "linksys" is my home network is doomed. So if you have 802.1x, then what you are saying makes sense. But very few networks have 802.1x, because the 802.1x security model only works in a very restricted set of circumstances. Someone mentioned eduroam, but this is actually a very, very special case. Imagine if every environment anyone worked in had something like eduroam. How would the IETF NOC make all of those different trust regimes work on the network at the same time? It's a cool hack, but it is not a general solution. Back to the "DHCP server for the network" question, this question only makes sense if the network can be identified. Consider how this would work on the IETF network: you'd have a DHCP server that would somehow be able to make a claim of authenticity with regard to its relationship to eduroam, and _also_ be able to claim authenticity with regard to its relationship to the IETF network. How are you going to make that work? Too many moving parts. Operationally challenging. And what do you get in return for all this work? > For ToFU, the thing that I think you took for key pinning is simply a key > caching heuristic that does not require user involvement to be useful. > If > > I get a DHCP message signed by a key that I previously cached, and there > > were no problems with the previously-cached key, then I will prefer that > > DHCP server over another DHCP server that also responded either using no > > authentication, or using a key that I have not cached. > > So the attacker just has to block messages from the preferred DHCP > server for a few seconds, and he wins. > How would an attacker do this? Can we detect whatever method the attacker would use? You are right that if the attacker can do this, the attacker can be sure of winning with respect to a particular conversation, but to do this full time would bring down the network, and would be detected. Also, attackers can already do this with unauthenticated DHCP. > > > Would TACK be a practical approach to reducing key rotation false > > > alarms? > > > > Keys should never, ever be rotated for ToFU. Server identities are not > > precious. If you want to rotate keys, change both the key and the > > identity. > > It seems to me that allowing transparent changes of the identity > largely defeats any potential benefit of TOFU for DHCP. Given that > keys don't last forever, the issue must be given some attention. > Why is a long-term identity useful? When is a long-term identity useful? > Ditto, I don't see how a fluid identity avoids defeating all benefit > from TOFU. Tofu makes it hard for a rogue DHCP server to supplant a legitimate DHCP server on a network to which you have previously connected. Unless you are rolling your keys really frequently, it substantially reduces the likelihood that a rogue DHCP server will be able to supplant the legitimate DHCP server. That is all it does in the case of ToFU. It does not assert a meaningful identity for the DHCP server, so talking about persistent identities for DHCP servers doesn't really make sense. If you want a persistent identity, you should be using PKI, and the identity is the identity claimed in the PKI cert and, likely, the cert that signed it, _not_ the server identifier. --001a11400ee6e35c96053b887e64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
Thing is, users ha= ve no knowledge of (or reason to know) which DHCP
server is legitimate for a given network.

T= rue.
=C2=A0
Thus the "id= entity" you
speak of is meaningless, the user is connecting to a given network,
not to a given DHCP server, all that matters is the underlying key.

Not true. =C2=A0 The identity is the identity = of a DHCP server with which the client either has or has not previously com= municated.

It does the user no good to be able authenticate the last DHCP
server they used if they start cold when they see a new one.=C2=A0 The
whole point is to not trust a new one if one has acquired and
"pinned" DHCP key material for the network in question.

This is not quite the right mental model to have= for how DHCP works. =C2=A0 There is no DHCP server for a network, any more= than there is an ssh server for a network. =C2=A0 There are zero or more D= HCP servers reachable on any particular network. =C2=A0 Also, only some net= works can be identified as the same network you were on before with the sam= e identifier. =C2=A0 E.g., trusting that "linksys" is my home net= work is doomed.

So if you have 802.1x, then what y= ou are saying makes sense. =C2=A0 But very few networks have 802.1x, becaus= e the 802.1x security model only works in a very restricted set of circumst= ances. =C2=A0 Someone mentioned eduroam, but this is actually a very, very = special case. =C2=A0 Imagine if every environment anyone worked in had some= thing like eduroam. =C2=A0 How would the IETF NOC make all of those differe= nt trust regimes work on the network at the same time? =C2=A0 It's a co= ol hack, but it is not a general solution.

Back to= the "DHCP server for the network" question, this question only m= akes sense if the network can be identified. =C2=A0 Consider how this would= work on the IETF network: you'd have a DHCP server that would somehow = be able to make a claim of authenticity with regard to its relationship to = eduroam, and _also_ be able to claim authenticity with regard to its relati= onship to the IETF network.

How are you going to m= ake that work? =C2=A0 Too many moving parts. =C2=A0 Operationally challengi= ng. =C2=A0 And what do you get in return for all this work?

<= /div>
> For ToFU, the t= hing that I think you took for key pinning is simply a key
> caching heuristic that does not require user involvement to be useful.= =C2=A0 =C2=A0If
> I get a DHCP message signed by a key that I previously cached, and the= re
> were no problems with the previously-cached key, then I will prefer th= at
> DHCP server over another DHCP server that also responded either using = no
> authentication, or using a key that I have not cached.

So the attacker just has to block messages from the preferred DHCP server for a few seconds, and he wins.

= How would an attacker do this? =C2=A0 Can we detect whatever method the att= acker would use? =C2=A0 You are right that if the attacker can do this, the= attacker can be sure of winning with respect to a particular conversation,= but to do this full time would bring down the network, and would be detect= ed. =C2=A0 Also, attackers can already do this with unauthenticated DHCP.
=C2=A0
> > Would TACK be a practical approach to reducing key rotation false=
> > alarms?
>
> Keys should never, ever be rotated for ToFU.=C2=A0 =C2=A0Server identi= ties are not
> precious.=C2=A0 =C2=A0If you want to rotate keys, change both the key = and the
> identity.

It seems to me that allowing transparent changes of the identity
largely defeats any potential benefit of TOFU for DHCP.=C2=A0 Given that keys don't last forever, the issue must be given some attention.

Why is a long-term identity useful? =C2=A0 Wh= en is a long-term identity useful?
=C2=A0
Ditto, I don't see how a fluid identity avoids defeating all ben= efit
from TOFU.

Tofu makes it hard for a rogue D= HCP server to supplant a legitimate DHCP server on a network to which you h= ave previously connected. =C2=A0 Unless you are rolling your keys really fr= equently, it substantially reduces the likelihood that a rogue DHCP server = will be able to supplant the legitimate DHCP server. =C2=A0 That is all it = does in the case of ToFU.

It does not assert a mea= ningful identity for the DHCP server, so talking about persistent identitie= s for DHCP servers doesn't really make sense. =C2=A0 If you want a pers= istent identity, you should be using PKI, and the identity is the identity = claimed in the PKI cert and, likely, the cert that signed it, _not_ the ser= ver identifier.
--001a11400ee6e35c96053b887e64-- From nobody Fri Sep 2 09:15:09 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B8112D53C for ; Fri, 2 Sep 2016 09:15:08 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUPpAgC31g_v for ; Fri, 2 Sep 2016 09:15:06 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ADB812D0EA for ; Fri, 2 Sep 2016 09:15:05 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id l2so124021308qkf.3 for ; Fri, 02 Sep 2016 09:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QKWaYKH27LPIPFWtthgZoWYdKgzIz652edBFgSb6f50=; b=udbYTA0W54qOeQ9jYEx4ov9Tj2ZM6h8Zj5ixFbq7O6m2pRrQsFvuvBASgfbgV/YJ0L TL/rJOK6DHfI7o3WzF1iyT1r1SnYvSIKFCVpWheRVC7/VDvufwbUHe682owRY6xeMCmb XeVFFPG/Qs0dXzt9nqjiCIsCtUOriUDEj3VQG4Z04gsKEdosrE7zPKrcAqqT+tN+ujEL D18SaF+STeWhYxycK8nLd2ksb7JqMMxXkOFXSv5YhsgHQl7baEfm0jUq6Y83PAtlchHH h354jSxLkjzRXkP46ZOpS00XTj3sB+4JasaiiFMtIw5zUpRxnVlWSCiOhdFAWsh+oP8A ZT6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QKWaYKH27LPIPFWtthgZoWYdKgzIz652edBFgSb6f50=; b=K/7IMNUbMCI99UywSRDB1OCNXE2FACvHQj0a41ObtcYA7j64095TYj/UAJ20WKifPr qKXVf4WeyxcZeJ/jnLqliJoLos8KzIqWDeFTnCZXwKDtro+rC5xX8lAzby1XoNjfQLxa ho7/Mn6HIhj9s7s5oQX0RPK0ge/RNmVNQq8qsRD61/kSsSPjSAKWJx4oXrTUDLSU8ipz KmbF+FAqtp8a1uqF84WKu5/6oIsAefJJbiwgYXVTqH1i7j50WrJ27d22bnM7NR6KOfr/ F7TsHH87fy2ny1X+R72wmZG6vI0l79sri6YXKXuprChTnleFiMba5wycobl0vxAO5iKn mvyw== X-Gm-Message-State: AE9vXwN2JVZtAmkVt7bqZ0SJOLSO7Fu5F/houX2OVGSVVy6PCgQ9Abq7t4ppaVYjW7E4VBXO+mtsXTAvvWzGO6dM X-Received: by 10.55.174.2 with SMTP id x2mr24682320qke.63.1472832904646; Fri, 02 Sep 2016 09:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.176.7 with HTTP; Fri, 2 Sep 2016 09:14:34 -0700 (PDT) In-Reply-To: <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> From: Warren Kumari Date: Fri, 2 Sep 2016 12:14:34 -0400 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=94eb2c07240618b794053b88a279 Archived-At: Cc: "saag@ietf.org" , Tero Kivinen Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:15:08 -0000 --94eb2c07240618b794053b88a279 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 2, 2016 at 9:38 AM, Paul Wouters wrote: > On 08/31/2016 07:37 AM, Tero Kivinen wrote: > > Warren Kumari writes: > >> Seriously, please review -- it is short, and (I believe) a really good > idea. > >> This gets you (unauthenticated) encryption wherever people use "open" > >> Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), > >> coffeeshops, airports, etc. > >> Now, like much opportunistic stuff, it doesn't protect against active > >> attacker - but it does force the attacker to be active (and many > >> controller based wifi deployments will notice and try protect against > >> "rouge APs"). > > So at the coffe eshop, where everybody knows (my name) the essid and the > password, > do I not get protection against passive attacks already? > =E2=80=8BActually, not really -- the WPA2-PSK four way handshake has some i= ssues - if the attacker is around when you associate (or can force you to disass=E2=80=8Bociate and reassociate), and knows the PSK, they can derive = the same key as you, and so (passively) watch all yer traffic... https://en.wikipedia.org/wiki/IEEE_802.11i-2004 Or, for the lazy, https://wiki.wireshark.org/HowToDecrypt802.11 > How much harder are we actually making it for the attacker to switch from > attacking > this WPA-PSK with known psk to OWA? My main motivation for this is not to replace / whatever WPA-PSK. I'm not sure what coffeeshops you are going to, but the ones I frequent (and my dentist, and "ietf-hotel", and "hhonors", and "DullesAirport_Free", and Schipol "Airport_Free_Wi-Fi", and ...) don't do WPA2-PSK -- this is simply designed to make "open" WiFi suck less. Sure, perhaps there shouldn't be open Wifi -- but there is, and there will continue to be for a long time. Perhaps everyone should use Hotspot, but, well they don't... OWE doesn't remove the need to end-to-end encryption, and doesn't claim to -- we should continue to work on end-to-end. But lots of users don't (and won't) run a VPN, and many protocols, including common ones like DNS (Hi, DPRIVE!) are not encrypted yet. We don't intend the user to get any sort of notification / feedback that they are getting encryption, and so they should not get any sort of false sense of security. This should all happen "under the hood" - the users should not get a "lock icon" when scanning (or when connected), and so should still feel just as unsafe as they currently do :-) > Since we are not even causing the attacker to > go from passive to active if I understand things correctly (which I might > not, as I'm > not very knowledgeable with IEEE protocols) > > > This protocol seems to be using IKEv2 IANA registry, but the protocol > > does not look like IKEv2, so I think you should fix that by replacing > > the protocol and just reuse IKEv2 in OWE, > > > IANA registries are cheap, there is no point of reusing registries for > > something that are not releated to the original intention of the > > registry. > > I agree with Tero that you should probably not use the IKE registry. You > could make your own. > =E2=80=8BOkey dokey. Asking for a registry is easy - it just seems like a w= aste if it is only going to have a value or two... > > If you really want IKEv2 Opportunistic IPsec, I gave a demo last week at > the Linux Security > Summit, using IKEv2 with anonymous clients to letsencrypt based server > authentication. > > http://events.linuxfoundation.org/sites/events/files/slides/ > LinuxSecuritySummit-2016-OE-16x9.pdf > > Code and install instructions while not yet merged in upstream: > https://nohats.ca/LE/ > > Demo server available: letsencrypt.libreswan.org > > Next step for Opportunistic IPsec is DNSSEC based authentication. > > Paul > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --94eb2c07240618b794053b88a279 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 2, 2016 at 9:38 AM, Paul Wouters <pwouters@redhat.com> wrote:
<= span class=3D"gmail-">On 08/31/2016 07:37 AM, Tero Kivinen wrote:
> Warren Kumari writes:
>> Seriously, please review -- it is short, and (I believe) a really = good idea.
>> This gets you (unauthenticated) encryption wherever people use &qu= ot;open"
>> Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID),<= br> >> coffeeshops, airports, etc.
>> Now, like much opportunistic stuff, it doesn't protect against= active
>> attacker - but it does force the attacker to be active (and many >> controller based wifi deployments will notice and try protect agai= nst
>> "rouge APs").

So at the coffe eshop, where everybody knows (my name) the essid and= the password,
do I not get protection against passive attacks already?



How much harder are we actually making it for the attacker to switch from a= ttacking
this WPA-PSK with known psk to OWA?

My main moti= vation for this is not to replace / whatever WPA-PSK.
I'm not sure what= coffeeshops you are going to, but the ones I frequent (and my dentist, and= "ietf-hotel", and "hhonors", and "DullesAirport_F= ree", and Schipol "Airport_Free_Wi-Fi", and ...) don't d= o WPA2-PSK -- this is simply designed to make "open" WiFi suck le= ss.
Sure, perhaps there shouldn't be open Wifi -- but there is, and the= re will continue to be for a long time. Perhaps everyone should use Hotspot= , but, well they don't...=C2=A0

OWE doesn't remove the nee= d to end-to-end encryption, and doesn't claim to -- we should continue = to work on end-to-end. But lots of users don't (and won't) run a VP= N, and many protocols, including common ones like DNS (Hi, DPRIVE!) are not= encrypted yet.=C2=A0

We don't intend the user to get any sort of = notification / feedback that they are getting encryption, and so they shoul= d not get any sort of false sense of security. This should all happen "= ;under the hood" - the users should not get a "lock icon" wh= en scanning (or when connected), and so should still feel just as unsafe as= they currently do :-)

=C2=A0
Since we are not even causing the attacke= r to
go from passive to active if I understand things correctly (which I might n= ot, as I'm
not very knowledgeable with IEEE protocols)

> This protocol seems to be using IKEv2 IANA registry, but the protocol<= br> > does not look like IKEv2, so I think you should fix that by replacing<= br> > the protocol and just reuse IKEv2 in OWE,

> IANA registries are cheap, there is no p= oint of reusing registries for
> something that are not releated to the original intention of the
> registry.

I agree with Tero that you should probably not use the IKE registry.= You
could make your own.

=E2=80=8BOkey dokey. As= king for a registry is easy - it just seems like a waste if it is only goin= g to have a value or two...
=C2=A0

If you really want IKEv2 Opportunistic IPsec, I gave a demo last week at th= e Linux Security
Summit, using IKEv2 with anonymous clients to letsencrypt based server auth= entication.

http= ://events.linuxfoundation.org/sites/events/files/slides/LinuxSecu= ritySummit-2016-OE-16x9.pdf

Code and install instructions while not yet merged in upstream: https://nohats.= ca/LE/

Demo server available: letsencrypt.libreswan.org

Next step for Opportunistic IPsec is DNSSEC based authentication.

Paul




--
I don't think the execution is relevan= t when it was obviously a bad idea in the first place.
This is like putt= ing rabid weasels in your pants, and later expressing regret at having chos= en those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0-= --maf
--94eb2c07240618b794053b88a279-- From nobody Fri Sep 2 09:49:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3820612D536 for ; Fri, 2 Sep 2016 09:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWvNYvQJWVJf for ; Fri, 2 Sep 2016 09:49:24 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5A412D190 for ; Fri, 2 Sep 2016 09:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id A1CD3198E; Fri, 2 Sep 2016 16:49:23 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll2BOHr-3Enk; Fri, 2 Sep 2016 16:49:23 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 36688A8; Fri, 2 Sep 2016 16:49:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 2 Sep 2016 12:49:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <56CE54E9-0612-42AB-AC8B-A532B966177D@deployingradius.com> References: <20160902151644.GT4670@mournblade.imrryr.org> To: Ted Lemon X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 16:49:26 -0000 On Sep 2, 2016, at 12:04 PM, Ted Lemon wrote: > So if you have 802.1x, then what you are saying makes sense. But = very few networks have 802.1x, because the 802.1x security model only = works in a very restricted set of circumstances. I would argue that *most* networks today have 802.1X. e.g. 3G, which = is entirely authenticated. And that most other networks (e.g. = corporate) has no technical barriers to adoption of 802.1X. The remaining networks are open WiFi networks. And with Hotspot 2.0, = are also moving to 802.1X. > Someone mentioned eduroam, but this is actually a very, very special = case. Imagine if every environment anyone worked in had something like = eduroam. How would the IETF NOC make all of those different trust = regimes work on the network at the same time? For AAA / 802.1X, there are existing standards, internet drafts, and = implementations to make all this work. There is no *technical* barrier = to adoption. > It's a cool hack, but it is not a general solution. The solution for 802.1X in the IETF network exists today. > Back to the "DHCP server for the network" question, this question only = makes sense if the network can be identified. Consider how this would = work on the IETF network: you'd have a DHCP server that would somehow be = able to make a claim of authenticity with regard to its relationship to = eduroam, and _also_ be able to claim authenticity with regard to its = relationship to the IETF network. >=20 > How are you going to make that work? The home AAA server shares the derived DHCP keys with the IETF AAA = server, which in turn shares them with the local DHCP server, which uses = them to sign packets. About 90% of this exists today. All that is needed is a standard = which describes how the keys are derived and shared over RADIUS, and = then implementations on the client / server side. > Too many moving parts. Operationally challenging. It's about 2K lines of new code, and ~100 lines of configuration file = updates for my AAA / DHCP implementation. The DHCP client side = shouldn't be that much more code. The IETF network already does = EDUROAM. i.e. pretty trivial. > And what do you get in return for all this work? Increased security. For not much more work than ToFU key management. > Tofu makes it hard for a rogue DHCP server to supplant a legitimate = DHCP server on a network to which you have previously connected. = Unless you are rolling your keys really frequently, it substantially = reduces the likelihood that a rogue DHCP server will be able to supplant = the legitimate DHCP server. That is all it does in the case of ToFU. That's all good. Alan DeKok. From nobody Fri Sep 2 10:51:23 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBC712D88F for ; Fri, 2 Sep 2016 10:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVteiKeN7YWD for ; Fri, 2 Sep 2016 10:51:21 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B8DE12D1E7 for ; Fri, 2 Sep 2016 10:51:21 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id g202so21368570pfb.0 for ; Fri, 02 Sep 2016 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X7Vv7TQ3vfvJhLWyjrrPwQeKk+TFwbaQrSZ32VdLRck=; b=dn1bHi6IvuuDy3eOKTpVMC2H/2+17MTcmja/HuVHYkx+MCh4+RSctplFv8IHBp6W9Z 3vUnJXDJH9d1hxCFAXxM8Plk9LDi6YCvPARXQBaQL15zqIscTGAmDU/2r1Hen5Y8+wxI A2Jtx+JFfmiV0QsIqyLZdQyix6wkY7a12eiUpHe1IcazmMgcpfcZ1KeE2v2upTp565Al Wn2V9aaThzNTPQcyWOp7g0oTzjUNsw4tJw0/CUCVgk2t5SkYbLGq0WzIOkWCiLc6i29m VKR6PDjp9uza4qgECyZNItsjIWFXBL0pfzD/tJP0/3lXo5GvRsgOFOnPWE+N5pqeZZos x40Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X7Vv7TQ3vfvJhLWyjrrPwQeKk+TFwbaQrSZ32VdLRck=; b=G3XwlOD7zhZfG18Bv1SSA43VDxmKggLsti4PE+ofCj33hydzPnl5U9f8cA+nO6yjGL inbTUvQuAuSa23/hEwkD0Z59C/DiAAWT3MnMKVfIzlld0O/Z39Odni3TVzW3UCCIfGmB OqpD3RbKg+t/Gr8xEqkuwMsIg2H23XBc6t/i0PBUICm1hEBWPRpohAJCFANf1k6vLxwN VGVVyaWo6PXcMCPbkeXqUskBFdngw76GXJmktgHj0sUAve1MNYowJOSN0dxYG6pPXTaH yRqeXvULwj+OmXuJTOKen86NgykCgzyXk1zadkDrivJUoOyHffbA9RAmLWfkWdwH3iG3 lJkQ== X-Gm-Message-State: AE9vXwNRDZrmKLARYEhz0tneNGAdzZIGZkycudZd7fbpoVSuSZfaVgHRvvU/mJ2cC1VzCQ== X-Received: by 10.98.67.193 with SMTP id l62mr38594440pfi.16.1472838680905; Fri, 02 Sep 2016 10:51:20 -0700 (PDT) Received: from [10.7.117.185] ([166.176.186.202]) by smtp.gmail.com with ESMTPSA id zk7sm16307984pac.41.2016.09.02.10.51.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 10:51:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13G36) In-Reply-To: <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> Date: Fri, 2 Sep 2016 10:51:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> To: Paul Wouters Archived-At: Cc: "saag@ietf.org" , Tero Kivinen Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 17:51:22 -0000 On Sep 2, 2016, at 6:38 AM, Paul Wouters wrote: > So at the coffe eshop, where everybody knows (my name) the essid and the p= assword, > do I not get protection against passive attacks already? [BA] Some coffee shops use WPA2 with a password, but most do not, so traffic= is sent in the clear. That is the scenario this proposal is addressing. > How much harder are we actually making it for the attacker to switch from a= ttacking > this WPA-PSK with known psk to OWA? [BA] I do not believe this proposal provides benefits in WPA2 or WPA2/enterp= rise scenarios, since no protection is provided for metadata exchanged prior= to WPA2/enterprise key derivation or for the 4-way handshake itself.= From nobody Fri Sep 2 10:55:01 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71A12D8D4 for ; Fri, 2 Sep 2016 10:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utfnWA2OTesd for ; Fri, 2 Sep 2016 10:54:58 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8700A12D1E7 for ; Fri, 2 Sep 2016 10:54:58 -0700 (PDT) Received: by mail-pa0-x232.google.com with SMTP id fu3so34567016pad.3 for ; Fri, 02 Sep 2016 10:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RrEbA9M4CRQdRYp5gHdwL0d2PjL9waY4tAEQJpQx+h4=; b=RMShWHdnokJIPz9nkW98680jrOVCIcvAYbMwVlW3K18nKfpRSzL87wKNHuzs2wEO0H toM5OltwUtpqYjqCG8dIADFTTjSIvrCFjPcN+en/nbC2Zhh6K6OI79MkMfeLxJB1nETy 70aAmIZqdYgJQ9Ym0YoVqkAr+izGXsHCk/BKbh/1UktufUdr+5gQEGaS+ylwWhTBMTTs 3HR6J5I9jzSDPRUifQXjddxEYtiTVHt4s2Cm/vmdOkRTtrOLrnP3I/IPY6njgUlalSR2 ploxBiC/N1/DXYy4HjIxZmAOxPZVPklWC+par67cOyB5jZnxCNyS9+0Hye8UpZ5VBGA3 JBSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RrEbA9M4CRQdRYp5gHdwL0d2PjL9waY4tAEQJpQx+h4=; b=DBO2VWAHOsVKqGlLEuEoMQM4cEm1zNIra8BYTWtwJdJVdF8bYR3LTBrcy1bN+eKX8X ZdeZFH2tjYi/HB+Im3KWPYJ31vHL8oOgoMvVpwt1KJgrXE5QFBc8nUO10mI3463fO0zK dsKJme5dhGBlN9pgMTMHVp1CD8wSR7G34OpkfnH3VKnA/wZSi/F3QGikEVh5OChzooD8 fDR+qgnBfcr3xd/m7AH+ssG77HrQsYAPq3GRFdB2/29TPpVmJjzFDrFQFtpLvxUya/+y QT4Qevxxo75QHLrz//AoDaWPz6z5TVmxTt2Xe9QomDFoDsXYmF4PiWgmbaoECk1RY2Qr eyuA== X-Gm-Message-State: AE9vXwM+AyJ5JF2Qgi3agHEWuCGWEW+IuTWoaPD7MAvLac7JVSfb29EEybQkRT9WRKwCtQ== X-Received: by 10.66.159.195 with SMTP id xe3mr38716973pab.159.1472838898121; Fri, 02 Sep 2016 10:54:58 -0700 (PDT) Received: from [10.7.117.185] ([166.176.186.202]) by smtp.gmail.com with ESMTPSA id tr1sm16374233pab.19.2016.09.02.10.54.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Sep 2016 10:54:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-04F42376-5392-49BB-9AD9-21CF308581AC Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13G36) In-Reply-To: Date: Fri, 2 Sep 2016 10:54:56 -0700 Content-Transfer-Encoding: 7bit Message-Id: <53610D2C-E7A5-463D-BA7F-F2BD2A2EF0BF@gmail.com> References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> To: Warren Kumari Archived-At: Cc: "saag@ietf.org" , Tero Kivinen Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 17:55:00 -0000 --Apple-Mail-04F42376-5392-49BB-9AD9-21CF308581AC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sep 2, 2016, at 9:14 AM, Warren Kumari wrote: >=20 > =E2=80=8BActually, not really -- the WPA2-PSK four way handshake has some i= ssues - if the attacker is around when you associate (or can force you to di= sass=E2=80=8Bociate and reassociate), and knows the PSK, they can derive the= same key as you, and so (passively) watch all yer traffic... >=20 > https://en.wikipedia.org/wiki/IEEE_802.11i-2004 > Or, for the lazy, https://wiki.wireshark.org/HowToDecrypt802.11 [BA] This attack could potentially be partially addressed by doing the DH ex= change earlier (e.g. as part of Authentication) so that the Association exch= ange and the 4-way handshake could be protected.= --Apple-Mail-04F42376-5392-49BB-9AD9-21CF308581AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sep 2, 2016, at 9:14 AM,= Warren Kumari <warren@kumari.net> wrote:


[BA] This attack could potential= ly be partially addressed by doing the DH exchange earlier (e.g. as part of A= uthentication) so that the Association exchange and the 4-way handshake coul= d be protected.
= --Apple-Mail-04F42376-5392-49BB-9AD9-21CF308581AC-- From nobody Fri Sep 2 13:27:58 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B985812B005 for ; Fri, 2 Sep 2016 13:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcAI7rRdATNZ for ; Fri, 2 Sep 2016 13:27:55 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EAF126579 for ; Fri, 2 Sep 2016 13:27:54 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u82KLdsV014528; Fri, 2 Sep 2016 13:27:49 -0700 Received: from sc-exch01.marvell.com ([199.233.58.181]) by mx0b-0016f401.pphosted.com with ESMTP id 257gc180tm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 02 Sep 2016 13:27:49 -0700 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH01.marvell.com (10.93.176.81) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Sep 2016 13:27:47 -0700 Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1104.000; Fri, 2 Sep 2016 13:27:47 -0700 From: Paul Lambert To: Stephen Farrell , Bernard Aboba , Warren Kumari Thread-Topic: [saag] opportunistic wireless encryption... Thread-Index: AQHR6FGndCGdzRAeW0KIzFPYTRc1raBi9OIAgAAJLwCAAHVJgIADbPAA Date: Fri, 2 Sep 2016 20:27:47 +0000 Message-ID: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> In-Reply-To: <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.5.160527 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.94.250.30] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0F509114724E4F4CAF0C7F2DB2368755@marvell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-02_07:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609020274 Archived-At: Cc: "Dan Romascanu \(Dan\)" , saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 20:27:57 -0000 > >On 31/08/16 03:09, Bernard Aboba wrote: >> So to make this more than just "words for the wind" it would be nice to >> have a path not just to publishing this document in the RFC series, but >> getting it implemented within IEEE 802.11 STAs and APs, which typically >> requires inclusion in the IEEE 802.11 standards (or at least work >>within >> WFA). > >I agree about implementation and deployment being the key here. > >In terms of getting IEEE's "blessing" as a part of that, we did >a chunk of that in and around the last IETF meeting, sent IEEE a >liaison [1] and Dan went to the subsequent IEEE meeting where >they agreed to allocate ANA codepoints for the OWE scheme. (Dan can >elaborate if needed and I'm sure the document will need at least >that update.) On blessings =8A I=B9ve observed that this specific OWE proposal was rejected multiple times by IEEE 802.11. The creation of an Internet Draft in this forum is a side-channel being used to side-step the IEEE process. https://mentor.ieee.org/802.11/documents?is_dcn=3DHarkins The concerns expressed in the IEEE forum included: - OWE is not a good/complete solution - it does not prevent spoofing/active attacks - adds complexity without preventing attacks - inclusion of OWE would detract from the development and fielding of a =8Cgood=B9 solution. Using the IETF as a side-channel for developing Wi-Fi specifications may actually be a good thing (IMHO). However, the successful creation of a liaison agreement should not be construed as acceptance or interest to adopt a specification by the Wi-Fi industry. The Wi-Fi industry has a long list of emerging special purpose security protocols that include: - SAE (a PAKE based on rfc7664 that may be used to strength WPA2-Personal) - Hotspot 2.0 (special X.509 certificates and infrastructure for secure enrollment and AP authentication) - Fast Initial Link Setup (FILS IEEE 802.11ai) - PKEX (PAKE-like key introduction) =20 https://mentor.ieee.org/802.11/dcn/16/11-16-1100-03-00ai-mods-to-pkex.docx - EAP-RP based fast authentication https://www.qualcomm.com/invention/research/projects/wi-fi/80211ai See figure 10 of: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/service- provider-wi-fi/white-paper-c11-731038.pdf - Wi-Fi Alliance DPP http://www.wi-fi.org/who-we-are/current-work-areas Includes: several authentication protocols (PKEX, DPP Auth, Connector Exchange) - OCF Security (IoT related, but would be used by Wi-Fi devices) https://openconnectivity.org/resources/specifications - and now OWE=20 =20 Paul > >So I think we have the formal inter-SDO bits well in hand. Any >ideas as to how to get running code would be most welcome though. > >(BTW, in terms of AD sponsoring this, IEEE's reaction to [1] is >enough to make me sanguine that we're not causing a fuss by doing >this.) > >>=20 >> Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming >>that >> this draft has been put on the agenda so that some progress can be made >>in >> that direction, and that discussions have been initiated with the IEEE >>802 >> leadership as described in RFC 7241. If not, Dan Romascanu (the IETF's >> liaison to IEEE 802) can make that happen. > >Yep, that was done, and the topic is on Dan's list of things to >monitor I think. > >Cheers, >S. > >[1] https://datatracker.ietf.org/liaison/1486/ > > > From nobody Fri Sep 2 13:40:13 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B7F12D529 for ; Fri, 2 Sep 2016 13:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nSFOftflEPg for ; Fri, 2 Sep 2016 13:40:11 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D2412D095 for ; Fri, 2 Sep 2016 13:40:11 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 93so65689801qtg.2 for ; Fri, 02 Sep 2016 13:40:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=seQz/rNcHECGkjY0tZdQ0KIGJiYWMr6C7Bt51ZZbQwA=; b=h7hFIJF4M9iMsin85LaCMJrT5sKCCXwVHduSmIJExrC5xjeSx88uWNY2dNJXNNqF2B KKG+MthRAve2oJ5Vuccrr7CEKhkA7F60+pTTMQtQn0aCReHJreHk/L5Kj4N4tXE/5ASu sbLxR1kjq2kJ4D90LY8Avi/wo56dZ45gq05CU9dvsWFibAiSTMbnSDLG3D1wq/OO4fiw 9zTy5QQyaaXE3+9EEJt1z35/u7V9GRQjRorL2hF/eesNeP2yRrpasqMc+wh6qAQA8x+r QSoDCHoc19X2bd+5c0hY8WeSprSBXHXHUJvDBIkdHUUP3S7cBEpJsV7479DDbxo0VxLH Ihkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=seQz/rNcHECGkjY0tZdQ0KIGJiYWMr6C7Bt51ZZbQwA=; b=DuRpoM8t4DxYIBAi440HU5CfgB6TzndEUgxW/5HunXD7apFKTOa/QjQJgbrXgYWKGe jOkIrqRoQQkGfNYmxOcBefP8wGu12EibsU1dzJR0w0BW1RwGCImjlzndxT3wK5eqi0TQ YIoTDhHfiZhpCDEcrFOC3i6uW4Yst+hzcA8v04EHpfznR/Yr5D9v6yut9GORtiIHm2gM ZQ2GupKFHCihX48PmXuoSJ0xYf2UAYi16kbFqUHlWiBiKjLa3nRy17Gz+Q8oIJ86zYiM OTDm9AwEbaru1K4Lwfh+jSAGPLo6jcurqz8ItHVEwDaMwaHpmN2EeKvyBiMWDCFc31hk THdA== X-Gm-Message-State: AE9vXwMV8b5ziR+63+RO3uYV/FTy3Vl7a64J4UG25MP1rlBNo8hDRVUzwoO7hhizbZ1VpVFMFnWogWcP4Hi5nw== X-Received: by 10.200.42.153 with SMTP id b25mr26402331qta.72.1472848810045; Fri, 02 Sep 2016 13:40:10 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.158.211 with HTTP; Fri, 2 Sep 2016 13:40:09 -0700 (PDT) From: Phillip Hallam-Baker Date: Fri, 2 Sep 2016 16:40:09 -0400 X-Google-Sender-Auth: B_UyxSCk_8iPOVfFZtEMnGoClsg Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a113ab7662185d3053b8c565a Archived-At: Subject: [saag] Can we publish OpenPGP fingerprints for the SECDIR? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Sep 2016 20:40:12 -0000 --001a113ab7662185d3053b8c565a Content-Type: text/plain; charset=UTF-8 All, Could I very strongly suggest that we collect and publish OpenPGP keys for the IETF SECDIR at the earliest possible convenience? For the sake of argument, assume that I have very urgent need to contact a particular WG chair to discuss a particular situation. PHB --001a113ab7662185d3053b8c565a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All= ,

Could I very strongly s= uggest that we collect and publish OpenPGP keys for the IETF SECDIR at the = earliest possible convenience?

For the sake of argument, assume that I have very urgent need to cont= act a particular WG chair to discuss a particular situation.

PHB
--001a113ab7662185d3053b8c565a-- From nobody Fri Sep 2 20:44:32 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB9412B040 for ; Fri, 2 Sep 2016 20:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpH3r4TcF6Ed for ; Fri, 2 Sep 2016 20:44:28 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9F11612B030 for ; Fri, 2 Sep 2016 20:44:28 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 210361FE034E for ; Fri, 2 Sep 2016 20:44:01 -0700 (PDT) To: saag@ietf.org References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> From: Dan Harkins Message-ID: Date: Fri, 2 Sep 2016 20:44:00 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------981359B8BA784AA75F857206" Archived-At: Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 03:44:30 -0000 This is a multi-part message in MIME format. --------------981359B8BA784AA75F857206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Bernard, On 8/30/16 7:09 PM, Bernard Aboba wrote: > > So to make this more than just "words for the wind" it would be nice > to have a path not just to publishing this document in the RFC series, > but getting it implemented within IEEE 802.11 STAs and APs, which > typically requires inclusion in the IEEE 802.11 standards (or at > least work within WFA). > This will probably appear in hostapd/wpa_supplicant a very short time after the draft is stable. That will make it naturally appear in AP and client implementations through code syncing. Once that happens there will be some additional work to enable it. For instance, some java goo will have to be added to Android so it appears in the list of APs appropriately and AP vendors will need to add a knob and/or some UI interface to turn it on an SSID. There is discussion within WFA on some "lightweight" hotspot usage and the subject of OWE has been brought up. The secretive nature of that organization makes the whole process a bit opaque but I'm hopeful OWE implementations will be able to go through the WFA certification process. > Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming > that this draft has been put on the agenda so that some progress can > be made in that direction, and that discussions have been initiated > with the IEEE 802 leadership as described in RFC 7241. If not, Dan > Romascanu (the IETF's liaison to IEEE 802) can make that happen. > There's an upcoming IETF/IEEE802 meeting next Friday I believe and this is on the agenda. regards, Dan. > On Aug 30, 2016 6:37 PM, "Warren Kumari" > wrote: > > On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell > > wrote: > > > > Hiya, > > > > We had a thread about a year ago on this topic. [1] The feedback > iirc > > was "go do it right and use D-H." The authors figure they've now > gone > > and done that [2] and have asked me to consider AD sponsoring > the work. > > > > I've told them I would so long as we don't find any gotchas and it > > doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE folks > > to check/ensure that that latter is ok via lots of lovely > liaising;-) > > > > In the meantime, comments here on the technical meat of this > would be > > appreciated if you have time to review. > > > Having heard no comments in ~1month, Dan and I are forced to assume > that the document is absolutely perfect in every way. > Now, I'm a little surprised by this - I was thinking that there would > be at least one minor typo or something, but apparently not... > > Seriously, please review -- it is short, and (I believe) a really > good idea. > This gets you (unauthenticated) encryption wherever people use "open" > Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), > coffeeshops, airports, etc. > Now, like much opportunistic stuff, it doesn't protect against active > attacker - but it does force the attacker to be active (and many > controller based wifi deployments will notice and try protect against > "rouge APs"). > > It explicitly does *NOT* solve all the worlds ills - we are not > claiming that it does; it doesn't remove the need for things like > VPNs, TLS, etc -- but it does make open wifi suck a bit less, and > that's a good incremental step. > We suggest that users not be informed that they are getting this > protection, so that they don't think that they are getting more than > they actually are... > > So, please, thoughts, feedback, etc. > > W > > > > > > > > Cheers, > > S. > > > > [1] > https://www.ietf.org/mail-archive/web/saag/current/msg06595.html > > > [2] https://tools.ietf.org/html/draft-harkins-owe > > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------981359B8BA784AA75F857206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
  Hi Bernard,

On 8/30/16 7:09 PM, Bernard Aboba wrote:

So to make this more than just "words for the wind" it would be nice to have a path not just to publishing this document in the RFC series, but getting it implemented within IEEE 802.11 STAs and APs, which typically requires  inclusion in the IEEE 802.11 standards (or at least work within WFA).


  This will probably appear in hostapd/wpa_supplicant a very short
time after the draft is stable. That will make it naturally appear
in AP and client implementations through code syncing. Once that
happens there will be some additional work to enable it. For
instance, some java goo will have to be added to Android so it
appears in the list of APs appropriately and AP vendors will need
to add a knob and/or some UI interface to turn it on an SSID.

  There is discussion within WFA on some "lightweight" hotspot
usage and the subject of OWE has been brought up. The secretive
nature of that organization makes the whole process a bit opaque
but I'm hopeful OWE implementations will be able to go through
the WFA certification process.

Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming that this draft has been put on the agenda so that some progress can be made in that direction, and that discussions have been initiated with the IEEE 802 leadership as described in RFC 7241.   If not, Dan Romascanu (the IETF's liaison to IEEE 802) can make that happen.


  There's an upcoming IETF/IEEE802 meeting next Friday I believe and
this is on the agenda.

  regards,

  Dan.
On Aug 30, 2016 6:37 PM, "Warren Kumari" <warren@kumari.net> wrote:
On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> We had a thread about a year ago on this topic. [1] The feedback iirc
> was "go do it right and use D-H." The authors figure they've now gone
> and done that [2] and have asked me to consider AD sponsoring the work.
>
> I've told them I would so long as we don't find any gotchas and it
> doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE folks
> to check/ensure that that latter is ok via lots of lovely liaising;-)
>
> In the meantime, comments here on the technical meat of this would be
> appreciated if you have time to review.


Having heard no comments in ~1month, Dan and I are forced to assume
that the document is absolutely perfect in every way.
Now, I'm a little surprised by this - I was thinking that there would
be at least one minor typo or something, but apparently not...

Seriously, please review -- it is short, and (I believe) a really good idea.
This gets you (unauthenticated) encryption wherever people use "open"
Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID),
coffeeshops, airports, etc.
Now, like much opportunistic stuff, it doesn't protect against active
attacker - but it does force the attacker to be active (and many
controller based wifi deployments will notice and try protect against
"rouge APs").

It explicitly does *NOT* solve all the worlds ills - we are not
claiming that it does; it doesn't remove the need for things like
VPNs, TLS, etc -- but it does make open wifi suck a bit less, and
that's a good incremental step.
We suggest that users not be informed that they are getting this
protection, so that they don't think that they are getting more than
they actually are...

So, please, thoughts, feedback, etc.

W




>
> Cheers,
> S.
>
> [1] https://www.ietf.org/mail-archive/web/saag/current/msg06595.html
> [2] https://tools.ietf.org/html/draft-harkins-owe
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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


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

--------------981359B8BA784AA75F857206-- From nobody Fri Sep 2 20:50:32 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1612D5D6 for ; Fri, 2 Sep 2016 20:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM8zocrQsXmB for ; Fri, 2 Sep 2016 20:50:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 01A2612B030 for ; Fri, 2 Sep 2016 20:50:30 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id D29451FE034E for ; Fri, 2 Sep 2016 20:50:29 -0700 (PDT) To: saag@ietf.org References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> From: Dan Harkins Message-ID: Date: Fri, 2 Sep 2016 20:50:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <22470.49542.85452.748009@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 03:50:31 -0000 HI Tero, On 8/31/16 4:37 AM, Tero Kivinen wrote: > Warren Kumari writes: >> Seriously, please review -- it is short, and (I believe) a really good idea. >> This gets you (unauthenticated) encryption wherever people use "open" >> Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), >> coffeeshops, airports, etc. >> Now, like much opportunistic stuff, it doesn't protect against active >> attacker - but it does force the attacker to be active (and many >> controller based wifi deployments will notice and try protect against >> "rouge APs"). > This protocol seems to be using IKEv2 IANA registry, but the protocol > does not look like IKEv2, so I think you should fix that by replacing > the protocol and just reuse IKEv2 in OWE, in similar ways than > 802.15.9 does for 802.15.4. That's waaaaay too heavyweight. And the authentication options that IKE provides-- certs, PSKs, PAKEs-- are mostly already supported in 802.11. It would be a very heavy lift to cram IKE into the 802.11 handshake. Doing a simple DH on top of existing association is a very clean and simple way of adding opportunistic encryption to 802.11. > Or the other option would be to make your own IANA registry for > this protocol, and not reuse the IKEv2 registry for some protocol that > does not have anything to do with IKEv2 or IPsec, then there would be > no need to change the protocol. IEEE 802.11 already uses the IKE DH group registry for its needs. Client and AP implementations of 802.11 already have code that maps the numbers in that registry to complete domain parameter sets and it makes sense to just continue to use what's there. > IANA registries are cheap, there is no point of reusing registries for > something that are not releated to the original intention of the > registry. Yes, unfortunately they are cheap. It would've been nicer if it was not so easy to make a second DH group registry for IKE when the first one was just fine. Now we have two for no purpose. Sigh. Dan. From nobody Fri Sep 2 20:58:19 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBA212D516 for ; Fri, 2 Sep 2016 20:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_sPOLXmTBvm for ; Fri, 2 Sep 2016 20:58:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA8E12B030 for ; Fri, 2 Sep 2016 20:58:17 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 581441FE034E for ; Fri, 2 Sep 2016 20:58:17 -0700 (PDT) To: saag@ietf.org References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> From: Dan Harkins Message-ID: <3c28a4f3-5ccd-cda1-9a0e-14c136b8a5c9@lounge.org> Date: Fri, 2 Sep 2016 20:58:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 03:58:18 -0000 Hi Paul, On 9/2/16 6:38 AM, Paul Wouters wrote: > On 08/31/2016 07:37 AM, Tero Kivinen wrote: >> Warren Kumari writes: >>> Seriously, please review -- it is short, and (I believe) a really good idea. >>> This gets you (unauthenticated) encryption wherever people use "open" >>> Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), >>> coffeeshops, airports, etc. >>> Now, like much opportunistic stuff, it doesn't protect against active >>> attacker - but it does force the attacker to be active (and many >>> controller based wifi deployments will notice and try protect against >>> "rouge APs"). > So at the coffe eshop, where everybody knows (my name) the essid and the password, > do I not get protection against passive attacks already? No you don't! If a passive adversary observes your handshake with the AP it can do an off-line dictionary attack to obtain the PSK and then decrypt your traffic (people have thrown a lot of HW at this task too and there are sites where you can pay $25 and give them a pcap file and get the PSK back, sometimes in less than an hour). If the adversary doesn't observe your handshake he can easily forge a frame to your client and cause it to reset its state machine and go do the handshake again with the AP. On top of that, many coffee shops and bars put the PSK on menus or sandwich boards so a dictionary attack is not even necessary! > How much harder are we actually making it for the attacker to switch from attacking > this WPA-PSK with known psk to OWA? Since we are not even causing the attacker to > go from passive to active if I understand things correctly (which I might not, as I'm > not very knowledgeable with IEEE protocols) We're making the attacker do an active attack which is not impossible but they are a bit easier to detect since the attacker has to spoof the AP. regards, Dan. From nobody Fri Sep 2 21:26:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A890512B04E for ; Fri, 2 Sep 2016 21:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xegJABaev1ND for ; Fri, 2 Sep 2016 21:26:39 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2A612B030 for ; Fri, 2 Sep 2016 21:26:39 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id BAF9B1FE02BC for ; Fri, 2 Sep 2016 21:26:38 -0700 (PDT) To: saag@ietf.org References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <1f8f15ce-b1b7-f73c-5ee7-a5579e1df64d@cs.tcd.ie> From: Dan Harkins Message-ID: Date: Fri, 2 Sep 2016 21:26:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 04:26:40 -0000 On 9/2/16 1:27 PM, Paul Lambert wrote: > On 31/08/16 03:09, Bernard Aboba wrote: >>> So to make this more than just "words for the wind" it would be nice to >>> have a path not just to publishing this document in the RFC series, but >>> getting it implemented within IEEE 802.11 STAs and APs, which typically >>> requires inclusion in the IEEE 802.11 standards (or at least work >>> within >>> WFA). >> I agree about implementation and deployment being the key here. >> >> In terms of getting IEEE's "blessing" as a part of that, we did >> a chunk of that in and around the last IETF meeting, sent IEEE a >> liaison [1] and Dan went to the subsequent IEEE meeting where >> they agreed to allocate ANA codepoints for the OWE scheme. (Dan can >> elaborate if needed and I'm sure the document will need at least >> that update.) > On blessings Š I¹ve observed that this specific OWE proposal was > rejected multiple times by IEEE 802.11. The creation of an > Internet Draft in this forum is a side-channel being used > to side-step the IEEE process. > https://mentor.ieee.org/802.11/documents?is_dcn=Harkins That's a strong accusation to make by just observing a document repository! > The concerns expressed in the IEEE forum included: > - OWE is not a good/complete solution > - it does not prevent spoofing/active attacks > - adds complexity without preventing attacks > - inclusion of OWE would detract from the development > and fielding of a Œgood¹ solution. To say that it does not prevent attacks is clearly false. It prevents passive attacks that are possible against WPA(2)-PSK! Not sure why you can't field a "good" solution that includes OWE. It does not preclude using other 802.11 security options nor is it a heavy or intrusive addition. Yes, OWE was presented multiple times at 802.11. It received comments each time the vote did not obtain 75% approval (the requirement for IEEE 802.11). Some of those were based on a misunderstanding of what it was trying to do ("this doesn't provide authentication!", yes I know that's the whole point), some was based on the belief that it was being a proposed replacement for the PSK mode of 802.11 (it is decidedly not, it is an alternative to Open), and finally it failed because it was deemed too late in the process of stabilizing the maintenance draft that was rolling up all the amendments since the last publication of the 802.11 standard. Each time it failed clarify text was added but the fundamental technical proposal never changed since there were never any substantive technical comments against it. > Using the IETF as a side-channel for developing Wi-Fi specifications > may actually be a good thing (IMHO). However, the successful creation > of a liaison agreement should not be construed as acceptance or > interest to adopt a specification by the Wi-Fi industry. Nor should your statements be construed as a rejection or lack of interest to adopt OWE by the Wi-Fi industry. The IEEE 802.11 Working Group, both leadership and members at large, are well aware of this effort. There is no feeling among _active_ members of the IEEE 802.11 Working Group that this is some "side step of the IEEE process." In fact, at the last meeting there was a vote among members to allocate the necessary code points from 802.11's registry for OWE and the vote was 44-0-2, if memory serves. Such an overwhelming approval certainly represents a strong rebuke to your accusation. Dan. From nobody Sat Sep 3 14:00:40 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0595C12B0AD for ; Sat, 3 Sep 2016 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwx-jCVpB1IV for ; Sat, 3 Sep 2016 14:00:37 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7402912B0EF for ; Sat, 3 Sep 2016 13:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=vC3GLlq2uNKH+ZKd/saokVtqk1gqhvJiujlGzAupuT4=; b=dpvhiruqJKpvYUyqCthnyX74Zm4JwrxqgHX4dfFDZFCcqG5c8ybekHQ1SoyV0bxD6hNYEdnnWlT08Hw8MQVKphI5WKtqPwtZ/GL+QwSn+IzKajcRfxuEyMartMfMAf8euFYgV3ux3uhVZ9On0px5vKbZ5sbJQ3eH1VusKAzIzJk=; Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from ) id 1bgHxY-0003AD-Do; Sat, 03 Sep 2016 20:54:40 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id 55C9F820876; Sat, 3 Sep 2016 16:54:39 -0400 (EDT) Date: Sat, 3 Sep 2016 16:54:39 -0400 From: Theodore Ts'o To: Joe Touch Message-ID: <20160903205439.clh24fc3dewtuxtl@thunk.org> References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> <8dc311fa-cca3-073a-418b-2ab1d1f8563a@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8dc311fa-cca3-073a-418b-2ab1d1f8563a@isi.edu> User-Agent: Mutt/1.6.2-neo (2016-07-23) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 21:00:38 -0000 On Fri, Sep 02, 2016 at 08:48:10AM -0700, Joe Touch wrote: > > > I would assume the Linux code went through several reviews at least, as this > > is not some basement developed OS. > > Linux is an "accept first, have many eyes check later" system - that's > why it supports so many peripherals, but also why it was once released > with code that failed to atomically update the file system tree (i.e., > if the system went down while an update was in process, the file system > was destroyed). IMO, your statement is reasonably true for FreeBSD, but > Linux *is* the counterexample. That's quite a hyperbolic description of Linux's development procedures. In general patches do get multiple reviews on various mailing lists before they go in, and there is a very much a strong test-driven culture. For example: http://thunk.org/gce-xfstests The example you gave is one that BSD partisans loved to talk about two decades ago, but it wasn't true even then. I'm not aware of *any* example of where the file system was destroyed if the system crashed while writes were happening to ext2. (The assertion was made because ext2 didn't carefully stage writes in a specific order, but given that hard drives post the BSD 4.3 era do writeback caching, trying to stage writes in a specific order is pointless; instead ext2 added a lot more sophistication to its file system consistency checker to recover from crashes. This was good enough that Google for a long time was using ext2 instead of ext3 because journalling gave back performance they didn't want, and the file system consistency checker was quite capable of fixing file systems after crashes.) Indeed, if we're going to play the OS trash talking game, I could point out that ext2/ext3/ext4 is the only file system consistency checker I know of that has a comprehensive regression test suite. Certainly BSD FFS's fsck.ufs does not. Does that mean that all of BSD is crap? Of course not!! In any case, instead of using "ad hominem" attacks, I'd suggest looking at whether it's reasonable that someone other imeplemtnor reading the RFC could make the same mistake. - Ted From nobody Sat Sep 3 14:23:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A03112B10C for ; Sat, 3 Sep 2016 14:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfJqfSgb-Ied for ; Sat, 3 Sep 2016 14:23:25 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED9D12B0FB for ; Sat, 3 Sep 2016 14:23:25 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u83LNA3e014237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 Sep 2016 14:23:11 -0700 (PDT) To: "Theodore Ts'o" References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> <8dc311fa-cca3-073a-418b-2ab1d1f8563a@isi.edu> <20160903205439.clh24fc3dewtuxtl@thunk.org> From: Joe Touch Message-ID: <28fe8525-bbdc-c3bf-a852-193be9de577e@isi.edu> Date: Sat, 3 Sep 2016 14:23:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160903205439.clh24fc3dewtuxtl@thunk.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: saag@ietf.org Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Sep 2016 21:23:27 -0000 On 9/3/2016 1:54 PM, Theodore Ts'o wrote: > On Fri, Sep 02, 2016 at 08:48:10AM -0700, Joe Touch wrote: >>> I would assume the Linux code went through several reviews at least, as this >>> is not some basement developed OS. >> Linux is an "accept first, have many eyes check later" system - that's >> why it supports so many peripherals, but also why it was once released >> with code that failed to atomically update the file system tree (i.e., >> if the system went down while an update was in process, the file system >> was destroyed). IMO, your statement is reasonably true for FreeBSD, but >> Linux *is* the counterexample. > That's quite a hyperbolic description of Linux's development > procedures. In general patches do get multiple reviews on various > mailing lists before they go in, and there is a very much a strong > test-driven culture. For example: > > http://thunk.org/gce-xfstests > > The example you gave is one that BSD partisans loved to talk about two > decades ago, but it wasn't true even then. I'm not aware of *any* > example of where the file system was destroyed if the system crashed > while writes were happening to ext2. We had multiple machines in our lab experience this failure mode. > ... > In any case, instead of using "ad hominem" attacks, It's difficult to perform such an attack on an inanimate object, but I described a specific flaw - one of many that have eluded the Linux review process. It's a simple tradeoff - by accepting more code, Linux supports more devices and becomes more widely accepted. That same priority also makes it more likely to accept incorrect code - whether written incorrectly or deployed prematurely. > I'd suggest > looking at whether it's reasonable that someone other imeplemtnor > reading the RFC could make the same mistake. I have repeatedly done so, but the contrary claim is (IMO) "well, if Linux messed up, *anyone* could". I disagree that logic. Joe From nobody Sun Sep 4 05:41:49 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3212B042 for ; Sun, 4 Sep 2016 05:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41EkSuEljrFW for ; Sun, 4 Sep 2016 05:41:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0434312B01A for ; Sun, 4 Sep 2016 05:41:46 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1886F43341D; Sun, 4 Sep 2016 12:41:45 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 02039433404; Sun, 4 Sep 2016 12:41:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472992905; bh=cRlDiqguiY+wDQNJL0Ot/YoEVNh6Rn4ew6kyw7tNWfI=; l=347; h=From:To:CC:Date:References:In-Reply-To:From; b=YjsFXgwLdRqphuFZge2xGnEHxjXKrlxOUMeA64WnJi+nGBNDw2YHnP4PEF1B9mLl2 ULpmKWT5DHqlyuFGiMBDVY2cl6gKwWmiKz6k9R9T2JAEnt/szDEnK3upngpY8rRkky SrFH5Jp+wt5V/6+3WH4iR4IqEpwC5DpcBo/WfwC4= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F28C21FC90; Sun, 4 Sep 2016 12:41:44 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 4 Sep 2016 05:41:44 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Sun, 4 Sep 2016 08:41:44 -0400 From: "Salz, Rich" To: Theodore Ts'o , Joe Touch Thread-Topic: [saag] Linux flaw from RFC5961 implementation Thread-Index: AQHSBSEiyLuOnRiTV0+dh3VOIKSkNaBmm5sAgAHn9oD//9JREA== Date: Sun, 4 Sep 2016 12:41:44 +0000 Message-ID: <1a9fbc51bac34d5487264bbdf7ce2c2c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> <8dc311fa-cca3-073a-418b-2ab1d1f8563a@isi.edu> <20160903205439.clh24fc3dewtuxtl@thunk.org> In-Reply-To: <20160903205439.clh24fc3dewtuxtl@thunk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 12:41:48 -0000 So let me understand. The linux community got something wrong and Joe has i= mplemented it multiple times and not gotten it wrong, is that right? If a major implementation got something wrong, why the heck would we *not* = put out a clarification? =20 -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Sun Sep 4 08:06:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F9812B249 for ; Sun, 4 Sep 2016 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R5IHXswL_u3 for ; Sun, 4 Sep 2016 08:06:40 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C121212B248 for ; Sun, 4 Sep 2016 08:06:39 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id 38so43406266qte.1 for ; Sun, 04 Sep 2016 08:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vv7RmNbnH2BBNeegCv2sz62S1UNPDGq6TZhP0I8Thoo=; b=viywJbHy/XMiz9Xkd6iz8KhSEkTCZrS2fsN59p9rEEwL2Z/dBdDfJXt2Wv65p1Aohm EkTmqjl1xOCf92Ex0S/1J9Pb4pYyJNLOeXJ6yktAk0PcSMY9oIoTFKQEYVy5Oxq23n/O wJcA24pAgy5T3V5owQBnRSYBqXsxTzalMRKT+B+y5Te5JLqVWwKVKcOwXkycAc+5k2dQ NLke/4Eu9r5o6TBLPooPqZTTEDtm/97Wh1JYvDySpSJFHJIKGL4rb2GjHAHb+v0nuN2O zsNvahrhvsiCAS9614RPnd1rUPEyqy5phV+vZWs/QqSZ/uMOpbPXESJZFyyvS32CS7sC GBYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vv7RmNbnH2BBNeegCv2sz62S1UNPDGq6TZhP0I8Thoo=; b=JRRkG0ndCskwW22l3KubjiLMyOGVdqmW51del2T/xemo26x1nPvtF3IpYjktBanF4n kkoyWQ63TRy1bJsyuO1Zb8/8yPfrTpkUjQvndkY7pb1JS9SpTYE6rfDPqLCiVbfARrZb q1GHwb6yxxNtG7Xy3N7a4uBc+nhBuEHWRKE3zM+9/Bfi+yt991JphMLcuWWaRx0/3FeZ /0GqnhxF6fgbiBSvhSP3jk+kS3l3B7DUl2JCCboFz4HUJkXv7RLNhruwdvf19OzsXpWu lpkTKG2kyZJiv3oaYEDvnQwAlnb5SvKu0xCWewgkcpxnOSYDeFF84H2gm2LUzbxas/sl 5fwg== X-Gm-Message-State: AE9vXwN8GH99HJqHStBMstIbQiNEMb/QlFDYplWT3a8rkZCtkK2+pyokgTcSw5MpkjmUfw== X-Received: by 10.237.59.51 with SMTP id p48mr34375256qte.95.1473001598652; Sun, 04 Sep 2016 08:06:38 -0700 (PDT) Received: from [10.61.39.75] (mobile-107-107-61-135.mycingular.net. [107.107.61.135]) by smtp.gmail.com with ESMTPSA id q68sm12120693qka.1.2016.09.04.08.06.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 04 Sep 2016 08:06:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (13G35) In-Reply-To: <1a9fbc51bac34d5487264bbdf7ce2c2c@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Sun, 4 Sep 2016 11:06:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38890BAC-1861-4727-A508-C33AFF846ECD@gmail.com> References: <6E459CA7-767F-43DE-A128-C50E50025B99@gmail.com> <1df327d2-adbe-b860-c095-b70fd0c14613@redhat.com> <8dc311fa-cca3-073a-418b-2ab1d1f8563a@isi.edu> <20160903205439.clh24fc3dewtuxtl@thunk.org> <1a9fbc51bac34d5487264bbdf7ce2c2c@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] Linux flaw from RFC5961 implementation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 15:06:41 -0000 Sent from my iPhone > On Sep 4, 2016, at 8:41 AM, Salz, Rich wrote: >=20 > So let me understand. The linux community got something wrong and Joe has i= mplemented it multiple times and not gotten it wrong, is that right? >=20 > If a major implementation got something wrong, why the heck would we *not*= put out a clarification? =20 Agreed. I don't agree with the argument given to not file an errata. Kathleen=20 > -- =20 > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sun Sep 4 09:28:50 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6549C12B26D for ; Sun, 4 Sep 2016 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olabGKHpQM3H for ; Sun, 4 Sep 2016 09:28:45 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B668112B266 for ; Sun, 4 Sep 2016 09:28:44 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id i32so215160218uai.2 for ; Sun, 04 Sep 2016 09:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oNcXfC5wwtFnn0CJ3sCy2fY6+Q6tpp79LV/e2Jgod/E=; b=O/+mDBafw11/8EYi4S28TgxnL7nmJ3m+Jjx1MSUXQDaD32LcsWYqsjSX9xHI1QcaoO IQnJUGb6juR6jxosN5d8wLhpoSrEQYsp4wUCFQdwsO6MOeYoxMD+2MUYh0GPSc5+rvu+ 1+/x7NlYLXsDE8R5hgk56yVlmGXuzCAZ1noMq1dJekKDvrvCSvhAgy7gqU5Q/3/9os8k 8Kl0R5WRlkh9viA/Az3qAqycxMXXbhIfAiL6HgAc+eJbnF12+WtE8waDJk/3nR+CJrWK cHzhgPc6+pORBrVAMJIU+6OOJLUg5Bl3dPE9eIXIucJ+XTxrUJhSCZFVEIHLO0Ko0RD2 a8kQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oNcXfC5wwtFnn0CJ3sCy2fY6+Q6tpp79LV/e2Jgod/E=; b=Iq6sC7W0CQ8K6yfeer9heLcKY2rNEocce4WSLld3Z8GRjvMtEPa+lFCxLh5aA5pcy/ Ylt13aBp7PF7zmlX1LyTpcdQghQgQPINWBZokK4l7uARX+snxBxbvvhF1WTM+IbySWLV CKHG3hkb2Tq2Vyuxj3jdZYSaAhA6sJx+3TLU61341uqzFVpJueQKRUh+2txMbfAu3oLh aqB3CPdmGtai6nUWTFjrEI2CompJTTIhp0QXFlxBtj+g0N6DaoN6tcyv1GfVCevDdr+Z 5O97uQssUN0lzoCB7/NuTrAhK+vni5vWm6uu1+NnPP8SDDLBRY60ErakUbUmDSRQRs8i 7lLw== X-Gm-Message-State: AE9vXwOSS8E3Gsp/PD0oyLS9CWF9e3E24F/mxP3UiabGgoY4BRAwVVRPxURlA60J8SNUPc79t3UKoH+pTUBuhw== X-Received: by 10.159.40.69 with SMTP id c63mr11722353uac.36.1473006523662; Sun, 04 Sep 2016 09:28:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.105 with HTTP; Sun, 4 Sep 2016 09:28:22 -0700 (PDT) In-Reply-To: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> From: Bernard Aboba Date: Sun, 4 Sep 2016 09:28:22 -0700 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=94eb2c048abc984752053bb10e96 Archived-At: Cc: saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Sep 2016 16:28:48 -0000 --94eb2c048abc984752053bb10e96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dan said: " This will probably appear in hostapd/wpa_supplicant a very short time after the draft is stable." [BA] Is any change required in drivers or can the proposal be deployed just with modified APs and supplicants? Paul Lambert said: "I=C2=B9ve observed that this specific OWE proposal was rejected multiple t= imes by IEEE 802.11. The creation of an Internet Draft in this forum is a side-channel being used to side-step the IEEE process. https://mentor.ieee.org/802.11/documents?is_dcn=3DHarkins" [BA] Given that Dan first proposed something along these lines 10+ years ago, if this is an end-run it is an *extremely* slow one. Over those 10 years, attacks which were originally not regarded as feasible (brute force password recovery from a 4-way handshake), were ignored in the original IEEE 802.11i design (DoS attacks) or were not regarded as important (meta-data recovery from a WPA2/enterprise exchange) now have become recognized as more serious threats. Given all the difficulties that have been encountered in getting new IEEE 802.11 security technology widely deployed since WPA/WPA2, it therefore seems reasonable to consider proposals with a potential path to implementation via open-source, as long as they don't create new vulnerabilities or don't preclude alternative approaches under development in IEEE 802.11. Paul Lambert also said: "The concerns expressed in the IEEE forum included: - OWE is not a good/complete solution [BA] It would appear to me that there has been some evolution between Dan's original proposals (which ran pre-association) and the IETF draft (which runs after Association). While neither attempt to be a "complete solution", the pre-association proposals do appear to potentially address a range of passive attacks. The IETF draft is more targeted, but appears to focus purely on the coffee shop scenario. I'd be interested to hear from Dan on the evolution of his thinking over time. - it does not prevent spoofing/active attacks [BA] While Dan's proposals do not prevent spoofing/active attacks, they do make them more expensive. And they do address passive attacks. - adds complexity without preventing attacks [BA] There is some addition in complexity, but apparently not enough to preclude open source implementation within existing APs/STAs. And passive attacks are prevented. - inclusion of OWE would detract from the development and fielding of a "good=C2=B9 solution." [BA] It has been 10+ years since the widespread deployment of WPA/WPA2. In that time, how much additional IEEE 802.11 security technology (e.g. 11r, 11w, etc.) has been widely deployed? Given that record, is OWE really likely to detract further? Dan Harkins said: " Nor should your statements be construed as a rejection or lack of interes= t to adopt OWE by the Wi-Fi industry." [BA] The state of security within much of "the WiFi industry" not very good, to put it mildly. Between consumer APs containing serious security vulnerabilities (many no longer maintained by their manufacturers), the widespread use of "Open" hotspots, and the advance of attacking technology, "the WiFi industry" would appear to need all the security help it can get. Therefore proposals that "do no harm" and have a potentially credible path to deployment seem worthy of consideration. On Fri, Sep 2, 2016 at 8:44 PM, Dan Harkins wrote: > > Hi Bernard, > > On 8/30/16 7:09 PM, Bernard Aboba wrote: > > So to make this more than just "words for the wind" it would be nice to > have a path not just to publishing this document in the RFC series, but > getting it implemented within IEEE 802.11 STAs and APs, which typically > requires inclusion in the IEEE 802.11 standards (or at least work within > WFA). > > > This will probably appear in hostapd/wpa_supplicant a very short > time after the draft is stable. That will make it naturally appear > in AP and client implementations through code syncing. Once that > happens there will be some additional work to enable it. For > instance, some java goo will have to be added to Android so it > appears in the list of APs appropriately and AP vendors will need > to add a knob and/or some UI interface to turn it on an SSID. > > There is discussion within WFA on some "lightweight" hotspot > usage and the subject of OWE has been brought up. The secretive > nature of that organization makes the whole process a bit opaque > but I'm hopeful OWE implementations will be able to go through > the WFA certification process. > > Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming tha= t > this draft has been put on the agenda so that some progress can be made i= n > that direction, and that discussions have been initiated with the IEEE 80= 2 > leadership as described in RFC 7241. If not, Dan Romascanu (the IETF's > liaison to IEEE 802) can make that happen. > > > There's an upcoming IETF/IEEE802 meeting next Friday I believe and > this is on the agenda. > > regards, > > Dan. > > On Aug 30, 2016 6:37 PM, "Warren Kumari" wrote: > >> On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell >> wrote: >> > >> > Hiya, >> > >> > We had a thread about a year ago on this topic. [1] The feedback iirc >> > was "go do it right and use D-H." The authors figure they've now gone >> > and done that [2] and have asked me to consider AD sponsoring the work= . >> > >> > I've told them I would so long as we don't find any gotchas and it >> > doesn't cause an IETF/IEEE kerfuffle. We're working with IEEE folks >> > to check/ensure that that latter is ok via lots of lovely liaising;-) >> > >> > In the meantime, comments here on the technical meat of this would be >> > appreciated if you have time to review. >> >> >> Having heard no comments in ~1month, Dan and I are forced to assume >> that the document is absolutely perfect in every way. >> Now, I'm a little surprised by this - I was thinking that there would >> be at least one minor typo or something, but apparently not... >> >> Seriously, please review -- it is short, and (I believe) a really good >> idea. >> This gets you (unauthenticated) encryption wherever people use "open" >> Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID), >> coffeeshops, airports, etc. >> Now, like much opportunistic stuff, it doesn't protect against active >> attacker - but it does force the attacker to be active (and many >> controller based wifi deployments will notice and try protect against >> "rouge APs"). >> >> It explicitly does *NOT* solve all the worlds ills - we are not >> claiming that it does; it doesn't remove the need for things like >> VPNs, TLS, etc -- but it does make open wifi suck a bit less, and >> that's a good incremental step. >> We suggest that users not be informed that they are getting this >> protection, so that they don't think that they are getting more than >> they actually are... >> >> So, please, thoughts, feedback, etc. >> >> W >> >> >> >> >> > >> > Cheers, >> > S. >> > >> > [1] https://www.ietf.org/mail-archive/web/saag/current/msg06595.html >> > [2] https://tools.ietf.org/html/draft-harkins-owe >> > >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > _______________________________________________ > saag mailing listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --94eb2c048abc984752053bb10e96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dan said:=C2=A0

"=C2=A0=C2=A0This will probably appear in hostapd= /wpa_supplicant a very short=C2=A0time after the draft is stable."= ;

[BA] Is any change required in drivers or can th= e proposal be deployed just with modified APs and supplicants?
Paul Lambert said:=C2=A0

"I=C2=B9ve observed that this specific OWE pro= posal was=C2=A0r= ejected multiple times by IEEE 802.11. The creation of an
Internet Draft in this forum is a side-channel being used=
to side-step the IEEE process.
=C2=A0 =C2=A0 =C2=A0 =C2=A0https://mentor.ieee.org/802.1= 1/documents?is_dcn=3DHarkins"

[BA] Gi= ven that Dan first proposed something along these lines 10+ years ago, if t= his is an end-run it is an *extremely* slow one.=C2=A0

=
Over those 10 years, attacks which were originally not regarded as fea= sible (brute force password recovery from a 4-way handshake), were ignored = in the original IEEE 802.11i design (DoS attacks) or were not regarded as i= mportant (meta-data recovery from a WPA2/enterprise exchange) now have beco= me recognized as more serious threats.

Given all t= he difficulties that have been encountered in getting new IEEE 802.11 secur= ity technology widely deployed since WPA/WPA2, it therefore seems reasonabl= e to consider proposals with a potential path to implementation via open-so= urce, as long as they don't create new vulnerabilities or don't pre= clude alternative approaches under development in IEEE 802.11.=C2=A0
<= div>
Paul Lambert also said:=C2=A0

&= quot;The concerns expre= ssed in the IEEE forum included:
=C2=A0 - OWE is not a good/complete solution
[BA] It would appear to me that there has been some evolu= tion between Dan's original proposals (which ran pre-association) and t= he IETF draft (which runs after Association).=C2=A0 While neither attempt t= o be a "complete solution", the pre-association proposals do appe= ar to potentially address a range of passive attacks.=C2=A0 The IETF draft = is more targeted, but appears to focus purely on the coffee shop scenario.= =C2=A0 I'd be interested to hear from Dan on the evolution of his think= ing over time.=C2=A0

=C2=A0 =C2=A0 - i= t does not prevent spoofing/active attacks

[BA] While Dan's proposals do not p= revent spoofing/active attacks, they do make them more expensive.=C2=A0 And= they do address passive attacks.

=C2=A0 - adds complexity without preventing atta= cks

[BA] There is s= ome addition in complexity, but apparently not enough to preclude open sour= ce implementation within existing APs/STAs.=C2=A0 And passive attacks are p= revented.=C2=A0

=C2=A0 - inclusion of OWE would detract from the development=C2=A0= and fielding of = a "good=C2=B9 solution."

[BA] It = has been 10+ years since the widespread deployment of WPA/WPA2.=C2=A0 In th= at time, how much additional IEEE 802.11 security technology (e.g. 11r, 11w= , etc.) has been widely deployed?=C2=A0 Given that record, is OWE really li= kely to detract further?

Dan Harkins said:=C2=A0

"=C2=A0Nor sh= ould your statements be construed as a rejection or lack of=C2=A0interest to adopt OWE by the Wi-Fi industry.<= /span>"

[BA] The state of security within muc= h of =C2=A0"the WiFi industry" not very good, to put it mildly.= =C2=A0 Between consumer APs containing serious security vulnerabilities (ma= ny no longer maintained by their manufacturers), the widespread use of &quo= t;Open" hotspots, and the advance of attacking technology, "the W= iFi industry" would appear to need all the security help it can get. T= herefore proposals that "do no harm" and have a potentially credi= ble path to deployment seem worthy of consideration.







On Fri, Sep 2, 2016 at 8:44 PM, Dan Harkins <dharkins@l= ounge.org> wrote:
=20 =20 =20

=C2=A0 Hi Bernard,

On 8/30/16 7:09 PM, Bernard Aboba wrote:

So to make this more than just "words for the win= d" it would be nice to have a path not just to publishing this document in the RFC series, but getting it implemented within IEEE 802.11 STAs and APs, which typically requires=C2=A0 inclusion = in the IEEE 802.11 standards (or at least work within WFA).


=C2=A0 This will probably appear in hostapd/wpa_supplicant a very short
time after the draft is stable. That will make it naturally appear in AP and client implementations through code syncing. Once that
happens there will be some additional work to enable it. For
instance, some java goo will have to be added to Android so it
appears in the list of APs appropriately and AP vendors will need
to add a knob and/or some UI interface to turn it on an SSID.

=C2=A0 There is discussion within WFA on some "lightweight"= hotspot
usage and the subject of OWE has been brought up. The secretive
nature of that organization makes the whole process a bit opaque
but I'm hopeful OWE implementations will be able to go through the WFA certification process.

Given the upcoming IETF/IEEE 802.11 cooperation meeting, I'm assuming that this draft has been put on the agend= a so that some progress can be made in that direction, and that discussions have been initiated with the IEEE 802 leadership as described in RFC 7241.=C2=A0=C2=A0 If not, Dan Romascanu (the IETF&= #39;s liaison to IEEE 802) can make that happen.


=C2=A0 There's an upcoming IETF/IEEE802 meeting next Fri= day I believe and
this is on the agenda.

=C2=A0 regards,

=C2=A0 Dan.

On Aug 30, 2016 6:37 PM, "Warren Kumari" <warren@kumari.net> wrote:
On Wed, Jul 27, 2016 at 5:55 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> We had a thread about a year ago on this topic. [1] The feedback iirc
> was "go do it right and use D-H." The authors fi= gure they've now gone
> and done that [2] and have asked me to consider AD sponsoring the work.
>
> I've told them I would so long as we don't find an= y gotchas and it
> doesn't cause an IETF/IEEE kerfuffle. We're workin= g with IEEE folks
> to check/ensure that that latter is ok via lots of lovely liaising;-)
>
> In the meantime, comments here on the technical meat of this would be
> appreciated if you have time to review.


Having heard no comments in ~1month, Dan and I are forced to assume
that the document is absolutely perfect in every way.
Now, I'm a little surprised by this - I was thinking that there would
be at least one minor typo or something, but apparently not...

Seriously, please review -- it is short, and (I believe) a really good idea.
This gets you (unauthenticated) encryption wherever people use "open"
Wifi, like, well, basically all hotels (e.g the ietf-hotel SSID),
coffeeshops, airports, etc.
Now, like much opportunistic stuff, it doesn't protect against active
attacker - but it does force the attacker to be active (and many
controller based wifi deployments will notice and try protect against
"rouge APs").

It explicitly does *NOT* solve all the worlds ills - we are not
claiming that it does; it doesn't remove the need for thing= s like
VPNs, TLS, etc -- but it does make open wifi suck a bit less, and
that's a good incremental step.
We suggest that users not be informed that they are getting this
protection, so that they don't think that they are getting more than
they actually are...

So, please, thoughts, feedback, etc.

W




>
> Cheers,
> S.
>
> [1] https://www.iet= f.org/mail-archive/web/saag/current/msg06595.html
> [2] https://tools.ietf.org/html/draft-harkins-owe
>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
saag mailing list
saag@ietf.or= g
https://www.ietf.org/mailman/listinfo/saa= g


_______________________________________________
saag mailing list
saag@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/saag


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


--94eb2c048abc984752053bb10e96-- From nobody Mon Sep 5 06:46:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC6112B214 for ; Mon, 5 Sep 2016 06:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSsxU7TkdDHV for ; Mon, 5 Sep 2016 06:46:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0034B12B024 for ; Mon, 5 Sep 2016 06:46:12 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u85Dk90C018274 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Sep 2016 16:46:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u85Dk7Yl029802; Mon, 5 Sep 2016 16:46:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22477.30495.415580.523039@fireball.acr.fi> Date: Mon, 5 Sep 2016 16:46:07 +0300 From: Tero Kivinen To: Warren Kumari In-Reply-To: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> <18fc9058-26fc-65e8-a1ef-e3755880b6d8@redhat.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 13:46:19 -0000 Warren Kumari writes: > > IANA registries are cheap, there is no point of reusing registr= ies for > > something that are not releated to the original intention of th= e > > registry. > =20 > I agree with Tero that you should probably not use the IKE regist= ry. You > could make your own. >=20 > =E2=80=8BOkey dokey. Asking for a registry is easy - it just seems li= ke a waste if it > is only going to have a value or two... If you reuse existing registry, then you should accept the fact, that you have no control on the registry. I.e., if at one point IPsec people would decide to obsolete all MODP and ECP based groups, and only leave Curve25519 and Curve448 there, there is nothing you can do... Or if you want to add new group there, and IPsec people consider that we already too many groups, and do not want to add more stuff there. We already had this problem earlier, when IEEE specifications reused the IANA registry for the obsoleted protocol (IKEv1), and they wanted to add new numbers there and IPsec people did not want to modify registers for protocols which are already obsoleted. If you only have few numbers, and if you do not expect there to be any new ones, just list the numbers in the document, but then you better be sure no new ones are going to be added. I think making new IANA registry is better option. --=20 kivinen@iki.fi From nobody Mon Sep 5 07:10:44 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7622112B20B for ; Mon, 5 Sep 2016 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qLn8ce6nfXX for ; Mon, 5 Sep 2016 07:10:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D700712B211 for ; Mon, 5 Sep 2016 07:01:52 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u85E1eCL002636 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Sep 2016 17:01:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u85E1Z5v011377; Mon, 5 Sep 2016 17:01:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22477.31423.76531.845225@fireball.acr.fi> Date: Mon, 5 Sep 2016 17:01:35 +0300 From: Tero Kivinen To: Dan Harkins In-Reply-To: References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> <22470.49542.85452.748009@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 11 min Archived-At: Cc: saag@ietf.org Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 14:10:42 -0000 Dan Harkins writes: > IEEE 802.11 already uses the IKE DH group registry for its needs. Does it use the IKEv2 DH registry, or only the no more allocations allowed DH registry for obsoleted IKEv1? Last time I checked it only used IKEv1 registry. This would be the first one trying to reuse IKEv2 registry. > Client and AP implementations of 802.11 already have code that maps > the numbers in that registry to complete domain parameter sets and > it makes sense to just continue to use what's there. > > IANA registries are cheap, there is no point of reusing registries for > > something that are not releated to the original intention of the > > registry. > Yes, unfortunately they are cheap. It would've been nicer if it was not > so easy to make a second DH group registry for IKE when the first one was > just fine. Now we have two for no purpose. Sigh. The other no more allocations allowed, and only there as there is still need to support IKEv1 in implementaions even when it was obsoleted in 2005. The registry does not only map the number to group, it also maps the number to the specification, and the checks that needs to be done for the group and so on. And I think we have more than two, I think we have about 7 or so (eap-pax, eap-eke, ikev1, ikev2, tls, ssh, dnskey) registries having Diffie-Hellman groups to some number or name. Having one per protocol is good thing, as each protocol do have different needs for registry, and also might have different policies to add things to registry. -- kivinen@iki.fi From nobody Mon Sep 5 11:22:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3560E12B27A for ; Mon, 5 Sep 2016 11:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IomXtVEn_O3s for ; Mon, 5 Sep 2016 11:22:52 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1852A12B05D for ; Mon, 5 Sep 2016 11:22:52 -0700 (PDT) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 47FC01022C012; Mon, 5 Sep 2016 11:22:51 -0700 (PDT) To: Bernard Aboba References: <01371e03-1a10-a464-3f15-4adecea7a0be@cs.tcd.ie> From: Dan Harkins Message-ID: Date: Mon, 5 Sep 2016 11:22:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------82C5DCF0D0FEC7BD3577EEE3" Archived-At: Cc: saag Subject: Re: [saag] opportunistic wireless encryption... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2016 18:22:54 -0000 This is a multi-part message in MIME format. --------------82C5DCF0D0FEC7BD3577EEE3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Bernard, On 9/4/16 9:28 AM, Bernard Aboba wrote: > Dan said: > > "This will probably appear in hostapd/wpa_supplicant a very short time > after the draft is stable." > > [BA] Is any change required in drivers or can the proposal be deployed > just with modified APs and supplicants? Quite often 802.11 authentication and 802.11 association frames are done in a driver. Many drivers provide partial programmatic ("application"/user space/supplicant) access to to association frames where APIs exist to add custom TLVs ("elements" in 802.11 parlance) to the frame and also get the driver to deliver a copy of received frames up to the application for processing. OWE adds TLVs to association frames. So if one has written the driver it's a simple mod. If one uses a reference design or just takes a pre-built driver to slap onto some hardware there should be an API to add the DH TLVs. I think because OWE uses association frames instead of authentication frames it will be easier to be added to existing products, many of which use a driver the vendor does not write. > Paul Lambert said: > > "I¹ve observed that this specific OWE proposal was rejected multiple > times by IEEE 802.11. The creation of an > Internet Draft in this forum is a side-channel being used > to side-step the IEEE process. > https://mentor.ieee.org/802.11/documents?is_dcn=Harkins > " > > [BA] Given that Dan first proposed something along these lines 10+ > years ago, if this is an end-run it is an *extremely* slow one. > > Over those 10 years, attacks which were originally not regarded as > feasible (brute force password recovery from a 4-way handshake), were > ignored in the original IEEE 802.11i design (DoS attacks) or were not > regarded as important (meta-data recovery from a WPA2/enterprise > exchange) now have become recognized as more serious threats. > > Given all the difficulties that have been encountered in getting new > IEEE 802.11 security technology widely deployed since WPA/WPA2, it > therefore seems reasonable to consider proposals with a potential path > to implementation via open-source, as long as they don't create new > vulnerabilities or don't preclude alternative approaches under > development in IEEE 802.11. > > Paul Lambert also said: > > "The concerns expressed in the IEEE forum included: > - OWE is not a good/complete solution > > [BA] It would appear to me that there has been some evolution between > Dan's original proposals (which ran pre-association) and the IETF > draft (which runs after Association). While neither attempt to be a > "complete solution", the pre-association proposals do appear to > potentially address a range of passive attacks. The IETF draft is > more targeted, but appears to focus purely on the coffee shop > scenario. I'd be interested to hear from Dan on the evolution of his > thinking over time. > Well my other (pre-association) idea evolved into SAE. That is a PAKE that is supposed to be a drop-in replacement for WPA2-PSK. Sadly that has not taken off in the way I had hoped. I believe this is due to it using 802.11 authentication frames and, as I note above, many vendors don't have a way to customize the contents of those frames or get the driver to pass them up to "user space" for processing. > - it does not prevent spoofing/active attacks > > [BA] While Dan's proposals do not prevent spoofing/active attacks, > they do make them more expensive. And they do address passive attacks. Very true. > - adds complexity without preventing attacks > > [BA] There is some addition in complexity, but apparently not enough > to preclude open source implementation within existing APs/STAs. And > passive attacks are prevented. > > - inclusion of OWE would detract from the development and fielding > of a "good¹ solution." > > [BA] It has been 10+ years since the widespread deployment of > WPA/WPA2. In that time, how much additional IEEE 802.11 security > technology (e.g. 11r, 11w, etc.) has been widely deployed? Given that > record, is OWE really likely to detract further? I'm glad you mentioned 11r. That has not had a very big uptick either, just like SAE. And like SAE that is due, IMHO, to its reliance on 802.11 authentication frames. Too many wireless product vendors do not have programmatic access to those frames and chipset vendors aren't providing APIs in their (reference) drivers. Perhaps Paul can comment on why that is. > Dan Harkins said: > > " Nor should your statements be construed as a rejection or lack of > interest to adopt OWE by the Wi-Fi industry." > > [BA] The state of security within much of "the WiFi industry" not > very good, to put it mildly. Between consumer APs containing serious > security vulnerabilities (many no longer maintained by their > manufacturers), the widespread use of "Open" hotspots, and the advance > of attacking technology, "the WiFi industry" would appear to need all > the security help it can get. Therefore proposals that "do no harm" > and have a potentially credible path to deployment seem worthy of > consideration. Open hotspots are a huge problem. Even when they have an https captive portal behind them, when the captive portal OKs the client (through entry of some code or password or clicking terms-and-conditions) any keys generated from the https connection are thrown away and the client continues with an open connection. OWE fixes this. The air is always encrypted and passive attacks are not possible. There is a huge upside to OWE and I don't see any downside. It was consciously chosen to use an 802.11 frame that experience shows should make it more easy to deploy. regards, Dan. --------------82C5DCF0D0FEC7BD3577EEE3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
  Hi Bernard,

On 9/4/16 9:28 AM, Bernard Aboba wrote:
Dan said: 

"  This will probably appear in hostapd/wpa_supplicant a very short time after the draft is stable."

[BA] Is any change required in drivers or can the proposal be deployed just with modified APs and supplicants?

  Quite often 802.11 authentication and 802.11 association frames
are done in a driver. Many drivers provide partial programmatic
("application"/user space/supplicant) access to to association frames
where APIs exist to add custom TLVs ("elements" in 802.11 parlance)
to the frame and also get the driver to deliver a copy of received
frames up to the application for processing.

  OWE adds TLVs to association frames. So if one has written the
driver it's a simple mod. If one uses a reference design or just takes
a pre-built driver to slap onto some hardware there should be an API to
add the DH TLVs.

  I think because OWE uses association frames instead of authentication
frames it will be easier to be added to existing products, many of which
use a driver the vendor does not write. 

Paul Lambert said: 

"I¹ve observed that this specific OWE proposal was rejected multiple times by IEEE 802.11. The creation of an
Internet Draft in this forum is a side-channel being used
to side-step the IEEE process.
       https://mentor.ieee.org/802.11/documents?is_dcn=Harkins"

[BA] Given that Dan first proposed something along these lines 10+ years ago, if this is an end-run it is an *extremely* slow one. 

Over those 10 years, attacks which were originally not regarded as feasible (brute force password recovery from a 4-way handshake), were ignored in the original IEEE 802.11i design (DoS attacks) or were not regarded as important (meta-data recovery from a WPA2/enterprise exchange) now have become recognized as more serious threats.

Given all the difficulties that have been encountered in getting new IEEE 802.11 security technology widely deployed since WPA/WPA2, it therefore seems reasonable to consider proposals with a potential path to implementation via open-source, as long as they don't create new vulnerabilities or don't preclude alternative approaches under development in IEEE 802.11. 

Paul Lambert also said: 

"The concerns expressed in the IEEE forum included:
  - OWE is not a good/complete solution

[BA] It would appear to me that there has been some evolution between Dan's original proposals (which ran pre-association) and the IETF draft (which runs after Association).  While neither attempt to be a "complete solution", the pre-association proposals do appear to potentially address a range of passive attacks.  The IETF draft is more targeted, but appears to focus purely on the coffee shop scenario.  I'd be interested to hear from Dan on the evolution of his thinking over time. 


  Well my other (pre-association) idea evolved into SAE. That is a PAKE that
is supposed to be a drop-in replacement for WPA2-PSK. Sadly that has not taken
off in the way I had hoped. I believe this is due to it using 802.11 authentication
frames and, as I note above, many vendors don't have a way to customize the
contents of those frames or get the driver to pass them up to "user space" for
processing.
    - it does not prevent spoofing/active attacks

[BA] While Dan's proposals do not prevent spoofing/active attacks, they do make them more expensive.  And they do address passive attacks.

  Very true.

  - adds complexity without preventing attacks

[BA] There is some addition in complexity, but apparently not enough to preclude open source implementation within existing APs/STAs.  And passive attacks are prevented. 

  - inclusion of OWE would detract from the development and fielding of a "good¹ solution."

[BA] It has been 10+ years since the widespread deployment of WPA/WPA2.  In that time, how much additional IEEE 802.11 security technology (e.g. 11r, 11w, etc.) has been widely deployed?  Given that record, is OWE really likely to detract further?

  I'm glad you mentioned 11r. That has not had a very big uptick either, just like
SAE. And like SAE that is due, IMHO, to its reliance on 802.11 authentication
frames. Too many wireless product vendors do not have programmatic access to those
frames and chipset vendors aren't providing APIs in their (reference) drivers.
Perhaps Paul can comment on why that is.

Dan Harkins said: 

" Nor should your statements be construed as a rejection or lack of interest to adopt OWE by the Wi-Fi industry."

[BA] The state of security within much of  "the WiFi industry" not very good, to put it mildly.  Between consumer APs containing serious security vulnerabilities (many no longer maintained by their manufacturers), the widespread use of "Open" hotspots, and the advance of attacking technology, "the WiFi industry" would appear to need all the security help it can get. Therefore proposals that "do no harm" and have a potentially credible path to deployment seem worthy of consideration.

  Open hotspots are a huge problem. Even when they have an https captive portal
behind them, when the captive portal OKs the client (through entry of some
code or password or clicking terms-and-conditions) any keys generated from the
https connection are thrown away and the client continues with an open connection.
OWE fixes this. The air is always encrypted and passive attacks are not possible.

  There is a huge upside to OWE and I don't see any downside. It was consciously
chosen to use an 802.11 frame that experience shows should make it more easy to
deploy.

  regards,

  Dan.

--------------82C5DCF0D0FEC7BD3577EEE3-- From nobody Tue Sep 6 07:50:16 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA112B20A for ; Tue, 6 Sep 2016 07:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.41 X-Spam-Level: X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVcX2deOxV7E for ; Tue, 6 Sep 2016 07:50:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A8A12B207 for ; Tue, 6 Sep 2016 07:50:14 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3996685547 for ; Tue, 6 Sep 2016 14:50:14 +0000 (UTC) Received: from thinkpad.nohats.ca (vpn-231-81.phx2.redhat.com [10.3.231.81]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u86EoBZT024334 for ; Tue, 6 Sep 2016 10:50:13 -0400 To: saag@ietf.org References: <20160902151644.GT4670@mournblade.imrryr.org> From: Paul Wouters Message-ID: <033818f1-cc8a-12e6-a585-fdca899256e6@redhat.com> Date: Tue, 6 Sep 2016 10:50:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160902151644.GT4670@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 06 Sep 2016 14:50:14 +0000 (UTC) Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 14:50:16 -0000 On 09/02/2016 11:16 AM, Viktor Dukhovni wrote: > Thing is, users have no knowledge of (or reason to know) which DHCP > server is legitimate for a given network. Thus the "identity" you > speak of is meaningless, the user is connecting to a given network, > not to a given DHCP server, all that matters is the underlying key. > > It does the user no good to be able authenticate the last DHCP > server they used if they start cold when they see a new one. The > whole point is to not trust a new one if one has acquired and > "pinned" DHCP key material for the network in question. And wit the zillions of "starbucks" and "linksys" networks out there, I wouldn't know a rogue one even if it hit me. Even pinning in to GPS coordinates would probably throw me deep into False Positive Land. Paul From nobody Tue Sep 6 07:56:31 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824A012B21B for ; Tue, 6 Sep 2016 07:56:29 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU6lf39VNQrJ for ; Tue, 6 Sep 2016 07:56:27 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E3412B20B for ; Tue, 6 Sep 2016 07:56:27 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id l131so54608661lfl.2 for ; Tue, 06 Sep 2016 07:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=543KSNznNzERy+v9k0VphCWddhVt4iUI4eonQcishg4=; b=qv2o0Wi0LxqfW2li3W+pcQHg4Wn0gYJG+DD1MxFB18T4hBLWjXyeaIUz0HbO7J9fDy G2TfdPORWUjpA2rYuQ47Xi8PcYrhjjEfvr/rPX3fzrxWWIYddmb5fFBrD4pnDfgpVJTr /urmkUnc3Rq5kiMR6RsdVBgPM7Hzpmzlp+KT85k1dzGIjdIZsFT/+nUAzTlozIdGo5Nd 5z572Z4jG3ihzpC0CSibB+9hETpYWA30Z6JtK8ubaYiWSfCV19tzaNDkRpkuXOyTR3rN JYuSx2QTObA+CIA3HS+ibYhR7eFtJr3VT6WM4vdCdJkiTKECQn/gZ7QLyzYlGfKWYnWk arBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=543KSNznNzERy+v9k0VphCWddhVt4iUI4eonQcishg4=; b=PeWG8OOCxXtGpmrQpVNj9c19gkAH0L+sii+RX/fxpoK0BcXUPuR1DTK+UxAkNAJ3KR s/lsXn+ofYRyVfCMN08ZryI9IAasGUI2QC26b7audmnrW86qhbzEi25aTNhNLWGW1ZnH o+kNu7esrbZ+x0Jpi/yty8ksKULSM2GyOXadZxisXaMFKDisVRCeVuwqXRIU/UKxzI19 U53Y7auI5cjTM+l1TGxKEQk2WH5J1TQkw5XHTE5h/YDWBoDffLme02AyqJmd1WYwKKAU JP/vOEubbnp7GAf5PneUQ3vx5PM47N0RuBwrlqEb3pwEivrJTXs0oR12MEjTjaOmXC4g nPJQ== X-Gm-Message-State: AE9vXwNf0jmehNmHXBOcQIvw5Gy4WrXq3wFK5I3CcplIvmqdzSBaHzuCn4m31OnuFvzHFD+6iedjL/8lKy6n6g== X-Received: by 10.46.69.9 with SMTP id s9mr8149681lja.7.1473173785345; Tue, 06 Sep 2016 07:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Tue, 6 Sep 2016 07:55:44 -0700 (PDT) In-Reply-To: <033818f1-cc8a-12e6-a585-fdca899256e6@redhat.com> References: <20160902151644.GT4670@mournblade.imrryr.org> <033818f1-cc8a-12e6-a585-fdca899256e6@redhat.com> From: Ted Lemon Date: Tue, 6 Sep 2016 10:55:44 -0400 Message-ID: To: Paul Wouters Content-Type: multipart/alternative; boundary=001a114b05f02b1616053bd8001e Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 14:56:29 -0000 --001a114b05f02b1616053bd8001e Content-Type: text/plain; charset=UTF-8 Sure, but if you go to the same Starbucks, wouldn't you want to be able to have a heuristic for distinguishing between a server that worked before and one that is competing with it? On Tue, Sep 6, 2016 at 10:50 AM, Paul Wouters wrote: > On 09/02/2016 11:16 AM, Viktor Dukhovni wrote: > > > Thing is, users have no knowledge of (or reason to know) which DHCP > > server is legitimate for a given network. Thus the "identity" you > > speak of is meaningless, the user is connecting to a given network, > > not to a given DHCP server, all that matters is the underlying key. > > > > It does the user no good to be able authenticate the last DHCP > > server they used if they start cold when they see a new one. The > > whole point is to not trust a new one if one has acquired and > > "pinned" DHCP key material for the network in question. > > And wit the zillions of "starbucks" and "linksys" networks out there, I > wouldn't know a rogue one even if it hit me. Even pinning in to GPS > coordinates would probably throw me deep into False Positive Land. > > Paul > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --001a114b05f02b1616053bd8001e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, but if you go to the same Starbucks, wouldn't yo= u want to be able to have a heuristic for distinguishing between a server t= hat worked before and one that is competing with it?

On Tue, Sep 6, 2016 at 10:50 AM, P= aul Wouters <pwouters@redhat.com> wrote:
On 09/02/2016 11:16 AM, Viktor Dukhovni w= rote:

> Thing is, users have no knowledge of (or reason to know) which DHCP > server is legitimate for a given network.=C2=A0 Thus the "identit= y" you
> speak of is meaningless, the user is connecting to a given network, > not to a given DHCP server, all that matters is the underlying key. >
> It does the user no good to be able authenticate the last DHCP
> server they used if they start cold when they see a new one.=C2=A0 The=
> whole point is to not trust a new one if one has acquired and
> "pinned" DHCP key material for the network in question.

And wit the zillions of "starbucks" and "linksys"= ; networks out there, I
wouldn't know a rogue one even if it hit me. Even pinning in to GPS
coordinates would probably throw me deep into False Positive Land.

Paul

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

--001a114b05f02b1616053bd8001e-- From nobody Tue Sep 6 07:58:06 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1069612B20B for ; Tue, 6 Sep 2016 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.41 X-Spam-Level: X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z73oh5LduIP for ; Tue, 6 Sep 2016 07:58:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE0C12B200 for ; Tue, 6 Sep 2016 07:58:04 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 374EF3B709; Tue, 6 Sep 2016 14:50:25 +0000 (UTC) Received: from thinkpad.nohats.ca (vpn-231-81.phx2.redhat.com [10.3.231.81]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u86EoOtZ005483; Tue, 6 Sep 2016 10:50:24 -0400 To: Phillip Hallam-Baker , "saag@ietf.org" References: From: Paul Wouters Message-ID: Date: Tue, 6 Sep 2016 10:50:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 06 Sep 2016 14:50:25 +0000 (UTC) Archived-At: Subject: Re: [saag] Can we publish OpenPGP fingerprints for the SECDIR? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 14:58:05 -0000 On 09/02/2016 04:40 PM, Phillip Hallam-Baker wrote: > All, > > Could I very strongly suggest that we collect and publish OpenPGP keys for > the IETF SECDIR at the earliest possible convenience? > > For the sake of argument, assume that I have very urgent need to contact a > particular WG chair to discuss a particular situation. Why not publish them using RFC-7929 :) Everything you want has an @ietf.org alias after all and ietf.org is signed. I think it would be great if we added such an option to upload the openpgp fingerprints and cause them to be republished as OPENPGPKEY records. Paul From nobody Thu Sep 8 17:19:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD48712B285 for ; Thu, 8 Sep 2016 17:19: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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey5vIrD7jchU for ; Thu, 8 Sep 2016 17:19:08 -0700 (PDT) Received: from xsmtp11.mail2web.com (xsmtp31.mail2web.com [168.144.250.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B711312B227 for ; Thu, 8 Sep 2016 17:19:08 -0700 (PDT) Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bi9X8-0007GI-QZ for saag@ietf.org; Thu, 08 Sep 2016 20:19:07 -0400 Received: (qmail 13161 invoked from network); 9 Sep 2016 00:19:06 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Sep 2016 00:19:05 -0000 From: "Christian Huitema" To: "'Ted Lemon'" , "'Security Area Advisory Group'" References: <20160902151644.GT4670@mournblade.imrryr.org> In-Reply-To: Date: Thu, 8 Sep 2016 17:19:04 -0700 Message-ID: <087401d20a2f$c6cd2700$54677500$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDl7J4vLRFZBEKJODLUurxxzkfsDgFxeZPQAyfGhwoCNqIpvqISA2Og Content-Language: en-us Archived-At: Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 00:19:11 -0000 On Friday, September 2, 2016 9:05 AM, Ted Lemon wrote: > On Fri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni = wrote: >> Thing is, users have no knowledge of (or reason to know) which DHCP >> server is legitimate for a given network. > > True. > >> Thus the "identity" you >> speak of is meaningless, the user is connecting to a given network, >> not to a given DHCP server, all that matters is the underlying key. >=20 > Not true. The identity is the identity of a DHCP server with which = the client either has or=20 > has not previously communicated. I am reading that whole thread again, and I think the quoted exchange = captures the nature of the=20 problem. We are worried about two kinds of attacks: spoofing the DHCP = server, and snooping on=20 DHCP traffic. Encryption, including opportunistic encryption, removes = the "passive snooping" attack, and forces the attacker to mount an active spoofing attack. That = seems useful, but in practice active spoofing is quite common, and snooping is only a = moderate concern -- it can also be addressed by information reduction, e.g., the DHCP anonymity = profile. But then, there is no way to address the spoofing issue without also addressing = the identity issue. The identity cannot be just the identity of the server. Suppose that I = have somehow trusted=20 the server that I used in the nice coffee shop yesterday. If I see the = same server available on my office network, should I trust it? Of course not! So the "identity" = question must include first the identity of the network. It is something like "should I trust = this DHCP server on that network?"=20 Once the network is identified, we may debate if TOFU is good enough to = validate the=20 Identity of the DHCP server. But if we don't somehow identify the = network, this whole debate Is meaningless! -- Christian Huitema From nobody Thu Sep 8 17:41:52 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDF12B1BC for ; Thu, 8 Sep 2016 17:41:50 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PCA2xWxjBdW for ; Thu, 8 Sep 2016 17:41:49 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DDF120727 for ; Thu, 8 Sep 2016 17:41:47 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id k12so1947586lfb.1 for ; Thu, 08 Sep 2016 17:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B5uk/Y7C/58vxnr1AHs06ZaiwDHU7ehSpgQL+JoEIxM=; b=aIBqzPQ5jYoaeEm/eR1pWm1KjytmXbJonJw0i8eGT4SgaduWRxgOJPci5w4fUGr1Ih wUOi5i+52cVzcYai7gf8faKUWddudH6UDP56y6WaNm+YiF3gr2h8vdM9rQ10ymAtbwzp emggNn0ongYdchEnpYHVuCz78fLIHUnkzVe59S7qsXLilJUJhFRytDV+qu98DpvxV4M2 IL0vki5jmMfiL5xDxbLgEnMZdnqM2Ug8mPxbp5G9RLB47E2uoryB7/HlqXRti+ocYz1l +HNdA6rTzX6fT+kQ7Eo1915QxoRKJui/NuKZRcSWOFZOHS4POS5zpBy9HQb3yQ33O7qx cuPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B5uk/Y7C/58vxnr1AHs06ZaiwDHU7ehSpgQL+JoEIxM=; b=D5MtEaJYPBEA+Ar/dbN8yjEzAdhs8AA/49oEYueE+O0tOPDBLhDFWtHtoeSH1RgjNH LV4yxUjr15wW5yOyFSHX08SqC+ww85faHwEoXPHz7eYosOUmCt5TMyNJPUTUvYgCy9zY B7ylGbnFVqJgLmJ11SUwLyEsIM9fd5VOJ1mzGq8vdwcrjpJnJp1uLhU56is/0htcOk0E irCJ5IagO5XvoZe9TXp6Ty1XOXwECynzoMLQYYK4bHoLSVlcQNoWvgp5OjosN0q08cV7 xOUxJYByYM9L7kPQl5HU6rmn12htrkbKQBNUzbMniU1HiaNBmNYBzS2YRvAWqC055+Gn xgpQ== X-Gm-Message-State: AE9vXwPhDAKsets/NwfYdd9ADqW6TDloVPr8kb5knFs+viOwgH99xDiiuRg+7D9jKp637nOkLFb7CRI0fhO1qw== X-Received: by 10.46.33.8 with SMTP id h8mr215757ljh.36.1473381705752; Thu, 08 Sep 2016 17:41:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 8 Sep 2016 17:41:04 -0700 (PDT) In-Reply-To: <087401d20a2f$c6cd2700$54677500$@huitema.net> References: <20160902151644.GT4670@mournblade.imrryr.org> <087401d20a2f$c6cd2700$54677500$@huitema.net> From: Ted Lemon Date: Thu, 8 Sep 2016 20:41:04 -0400 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1142bcd230b4fe053c086936 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 00:41:50 -0000 --001a1142bcd230b4fe053c086936 Content-Type: text/plain; charset=UTF-8 Is there no DHCP server on your network at work? Presumably at work you use proper authentication, not ToFU, and so this problem goes away. On Thu, Sep 8, 2016 at 8:19 PM, Christian Huitema wrote: > On Friday, September 2, 2016 9:05 AM, Ted Lemon wrote: > > > On Fri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni ietf-dane@dukhovni.org> wrote: > >> Thing is, users have no knowledge of (or reason to know) which DHCP > >> server is legitimate for a given network. > > > > True. > > > >> Thus the "identity" you > >> speak of is meaningless, the user is connecting to a given network, > >> not to a given DHCP server, all that matters is the underlying key. > > > > Not true. The identity is the identity of a DHCP server with which the > client either has or > > has not previously communicated. > > I am reading that whole thread again, and I think the quoted exchange > captures the nature of the > problem. We are worried about two kinds of attacks: spoofing the DHCP > server, and snooping on > DHCP traffic. Encryption, including opportunistic encryption, removes the > "passive snooping" > attack, and forces the attacker to mount an active spoofing attack. That > seems useful, but > in practice active spoofing is quite common, and snooping is only a > moderate concern -- it > can also be addressed by information reduction, e.g., the DHCP anonymity > profile. But then, > there is no way to address the spoofing issue without also addressing the > identity issue. > > The identity cannot be just the identity of the server. Suppose that I > have somehow trusted > the server that I used in the nice coffee shop yesterday. If I see the > same server available on > my office network, should I trust it? Of course not! So the "identity" > question must include > first the identity of the network. It is something like "should I trust > this DHCP server on that > network?" > > Once the network is identified, we may debate if TOFU is good enough to > validate the > Identity of the DHCP server. But if we don't somehow identify the network, > this whole debate > Is meaningless! > > -- Christian Huitema > > > > --001a1142bcd230b4fe053c086936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is there no DHCP server on your network at work? =C2=A0 Pr= esumably at work you use proper authentication, not ToFU, and so this probl= em goes away.

On Thu, Sep 8, 2016 at 8:19 PM, Christian Huitema <<= a href=3D"mailto:huitema@huitema.net" target=3D"_blank">huitema@huitema.net= > wrote:
On Friday, Septemb= er 2, 2016 9:05 AM, Ted Lemon wrote:

> On Fri, Sep 2, 2016 at 11:16 AM, Viktor Dukhovni <mailto:ietf-dane@dukhovni.org> wrote:<= br> >> Thing is, users have no knowledge of (or reason to know) which DHC= P
>> server is legitimate for a given network.
>
> True.
>
>> Thus the "identity" you
>> speak of is meaningless, the user is connecting to a given network= ,
>> not to a given DHCP server, all that matters is the underlying key= .
>
> Not true.=C2=A0 =C2=A0The identity is the identity of a DHCP server wi= th which the client either has or
> has not previously communicated.

I am reading that whole thread again, and I think the quoted exchang= e captures the nature of the
problem. We are worried about two kinds of attacks: spoofing the DHCP serve= r, and snooping on
DHCP traffic. Encryption, including opportunistic encryption, removes the &= quot;passive snooping"
attack, and forces the attacker to mount an active spoofing attack. That se= ems useful, but
in practice active spoofing is quite common, and snooping is only a moderat= e concern -- it
can also be addressed by information reduction, e.g., the DHCP anonymity pr= ofile. But then,
there is no way to address the spoofing issue without also addressing the i= dentity issue.

The identity cannot be just the identity of the server. Suppose that I have= somehow trusted
the server that I used in the nice coffee shop yesterday. If I see the same= server available on
my office network, should I trust it? Of course not! So the "identity&= quot; question must include
first the identity of the network. It is something like "should I trus= t this DHCP server on that
network?"

Once the network is identified, we may debate if TOFU is good enough to val= idate the
Identity of the DHCP server. But if we don't somehow identify the netwo= rk, this whole debate
Is meaningless!

-- Christian Huitema




--001a1142bcd230b4fe053c086936-- From nobody Fri Sep 9 05:16:45 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E6612B0B3 for ; Fri, 9 Sep 2016 05:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-mkGx_SRnvT for ; Fri, 9 Sep 2016 05:16:37 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B912B0A8 for ; Fri, 9 Sep 2016 05:16:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 56A921DDB; Fri, 9 Sep 2016 12:16:35 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qGQHxG0cXQ7; Fri, 9 Sep 2016 12:16:35 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id B6508C37; Fri, 9 Sep 2016 12:16:34 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <087401d20a2f$c6cd2700$54677500$@huitema.net> Date: Fri, 9 Sep 2016 08:16:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160902151644.GT4670@mournblade.imrryr.org> <087401d20a2f$c6cd2700$54677500$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] A little more detail on ToFU for DHCPv6 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 12:16:44 -0000 On Sep 8, 2016, at 8:19 PM, Christian Huitema = wrote: > The identity cannot be just the identity of the server. Suppose that I = have somehow trusted=20 > the server that I used in the nice coffee shop yesterday. If I see the = same server available on > my office network, should I trust it? Of course not! Similar things apply in 802.1X. Let's say you connect to a network = which has a certificate signed by a known CA. Should you send that = network your user credentials? Of course not. The CA signs hundreds of thousands of certificates a year. That = network could be anyone. So you shouldn't trust the network. The solution in 802.1X land is to tie SSID to a self-signed ca. My = network uses my CA, and no one else can spoof it. That CA is = provisioned to the end-user machines via some out of band method. e.g. = a wired network in a physically trusted environment. It's annoying to manage, but it's the only way to be sure you trust = the known network, and *don't* trust other networks.=20 > So the "identity" question must include > first the identity of the network. It is something like "should I = trust this DHCP server on that > network?"=20 How do you identify the network? Pretty much any publicly available = information can be spoofed. You're left using a possibly spoofed MAC address / SSID to index a = table of previously-discovered DHCP server certs. It's better than = nothing, I suppose. > Once the network is identified, we may debate if TOFU is good enough = to validate the=20 > Identity of the DHCP server. But if we don't somehow identify the = network, this whole debate > Is meaningless! I'm in favour of moving DHCP security forward. I'm also in favour of = tying security together through multiple protocols. Alan DeKok. From nobody Fri Sep 9 09:55:08 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413912B0D0 for ; Fri, 9 Sep 2016 09:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.409 X-Spam-Level: X-Spam-Status: No, score=-8.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-4w5RgMN_5U for ; Fri, 9 Sep 2016 09:55:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C635C12B1BE for ; Fri, 9 Sep 2016 09:55:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1biP4z-0007HF-43 for saag@ietf.org; Fri, 09 Sep 2016 16:55:05 +0000 Date: Fri, 09 Sep 2016 09:56:06 -0700 Message-ID: From: Randy Bush To: Security Area Advisory Group References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: message/rfc822 Archived-At: Subject: [saag] Fwd: Re: [MacOSX] Pineapple WiFi hacking anyone? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 16:55:08 -0000 Message-ID: From: Randy Bush To: Helge Skrivervik Cc: macosx@lists.frobbit.se Subject: Re: [MacOSX] Pineapple WiFi hacking anyone? > A friend recently tested the WiFi Pineapple in SF - > https://hakshop.myshopify.com/collections/wifi-pineapple-kits > > became Man In the Middle for about 40 clients outside a Starbucks in a > matter of minutes. The surprise (to me at least) is that most clients > still broadcast the name of a preferred SSID to the world. > > Is this as bad as it looks? Opinions? yes. even worse, with saag and dhc wgs playing ostrich. randy From nobody Fri Sep 9 10:25:04 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C713C12B10A for ; Fri, 9 Sep 2016 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4AISFDuzT2D for ; Fri, 9 Sep 2016 10:25:01 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25FA12B014 for ; Fri, 9 Sep 2016 10:25:00 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 31so73742485uao.0 for ; Fri, 09 Sep 2016 10:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=903mrYpeeL2vozGfjaauM02feDs0HjPuhMrSR+mYXcA=; b=MDiWs20RnDL7cJNhMRXujkKtRFI8hGXw8C8AVVnO3dJeUht7CB3vliHrUPyy/EAHZl SSqe19F2csvGonPCRgYT7qD/CO3s66jQerF0fu3OQn1sF1MQmBRzLdp/YJzJ4WNjfbM0 5fDDLEyB4j8HqRczpskktXnLtCSgFnU5GwZ9KloC1nFxfttfY7PaGrq3cZzgvmkScBRq aQVtpYduJZpmz6W3jOWw3mFcLD3rcuYnexGShyWAoATgaJKQNo0uVWi43Luf8uaAgMjx PBcHmrTn7fQoYzqOpg400Kh/i5SJQTMLMPQGlk6pJnCEtjph4DoanjrTwaMsNjQRx6w7 TEYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=903mrYpeeL2vozGfjaauM02feDs0HjPuhMrSR+mYXcA=; b=RbVrdUnca1X9JqRtul4M+7q+Rf225SejxEjyO3L4k40hGnQZIIgsAgPKYWCRKXvlzS +bF7k722hyf0LNCvRllmwS3C/YEsR7yiCvV/a0swTnMZOQfurXGdriPJ4nnGMX7Elp1g s+ej/CXeoUhhDKFoD6Sa33xrUtMMscCJdH1d92kGcS7dTbsaZdZYepLZVe8pQqt81jNu jYFnop92XIFB6fMaarIyxjTfMU3GnaEbmRdeAErP+8QLhsx6ifl1rF/lv4ai7KDj7zDT ivE7px2yG2RoqfFdzPKDKsGL0GvCt+YivXlKP+G/8vf2mj5CB3pOhif5KZ+wIlwWfO2U +vLg== X-Gm-Message-State: AE9vXwPKDz8Mx1UKrxl/eDur1lRFVFyCSU5K2cRQ1WYFu7i3vFahF9f7FjX/1gwNyWbI00FVQZDCuBQ/NE1rGg== X-Received: by 10.176.82.112 with SMTP id j45mr2758711uaa.56.1473441899255; Fri, 09 Sep 2016 10:24:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Fri, 9 Sep 2016 10:24:57 -0700 (PDT) Received: by 10.176.4.102 with HTTP; Fri, 9 Sep 2016 10:24:57 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Fri, 9 Sep 2016 10:24:57 -0700 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=94eb2c191446090ccb053c166df5 Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Fwd: Re: [MacOSX] Pineapple WiFi hacking anyone? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2016 17:25:03 -0000 --94eb2c191446090ccb053c166df5 Content-Type: text/plain; charset=UTF-8 On Sep 9, 2016 9:55 AM, "Randy Bush" wrote: > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > ---------- Forwarded message ---------- > From: Randy Bush > To: Helge Skrivervik > Cc: macosx@lists.frobbit.se > Date: > Subject: Re: [MacOSX] Pineapple WiFi hacking anyone? > > A friend recently tested the WiFi Pineapple in SF - > > https://hakshop.myshopify.com/collections/wifi-pineapple-kits > > > > became Man In the Middle for about 40 clients outside a Starbucks in a > > matter of minutes. The surprise (to me at least) is that most clients > > still broadcast the name of a preferred SSID to the world. > > > > Is this as bad as it looks? Opinions? > > yes. even worse, with saag and dhc wgs playing ostrich. Let's be real clear: the network is untrusted. If you can't browse the web over an untrusted WiFi network you are already owned, you just don't know it yet. > > randy > > --94eb2c191446090ccb053c166df5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sep 9, 2016 9:55 AM, "Randy Bush" <randy@psg.com> wrote:
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag
>
>
> ---------- Forwarded message ----------
> From:=C2=A0Randy Bush <randy@psg.c= om>
> To:=C2=A0Helge Skrivervik <helge.skrivervik@gmail.com>
> Cc:=C2=A0macosx@lists.frobb= it.se
> Date:=C2=A0
> Subject:=C2=A0Re: [MacOSX] Pineapple WiFi hacking anyone?
> > A friend recently tested the WiFi Pineapple in SF -
> > https://hakshop.myshopify.com/collections/wifi-pineapple-kits<= br> > >
> > became Man In the Middle for about 40 clients outside a Starbucks= in a
> > matter of minutes. The surprise (to me at least) is that most cli= ents
> > still broadcast the name of a preferred SSID to the world.
> >
> > Is this as bad as it looks? Opinions?
>
> yes.=C2=A0 even worse, with saag and dhc wgs playing ostrich.

Let's be real clear: the network is untrusted. If you ca= n't browse the web over an untrusted WiFi network you are already owned= , you just don't know it yet.

>
> randy
>
>

--94eb2c191446090ccb053c166df5-- From nobody Mon Sep 12 19:06:17 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC57712B195 for ; Mon, 12 Sep 2016 19:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNDvMywAPZoQ for ; Mon, 12 Sep 2016 19:06:11 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5DE12B18E for ; Mon, 12 Sep 2016 19:06:10 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id m11so352182397oif.1 for ; Mon, 12 Sep 2016 19:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to; bh=P0yQi0HNQ13dhVyIo2M7o4nOBisTgXt5Vw2SUTZ2Aa4=; b=DF7iS8lw79uywcUMcTmZhzHFADBw1x9OttwtNMufMOBWIMbSS+VRyEPmFp9baMjTdw 07yLarT+37PXEGbxXweDsAiW6aIDTQWG+M7pFvJ7fyxr9meHrMpMb0DJ8eCdego4pNUA 17xqdjQw1CbqNlmJhd2+kOySBZi4+T6Cd53G5AVPqkCuDV3dJFu/xWtuUChjlCHfWR6i mZNwr6B43ZJdJH1o0Un1o7C7yYG/hQyY1JARl3n8AyHzNR6bSG+GKGqRGeziUb+ZwxcR rC3YqbyU/espyQWC8ZlhIOwTBZwuOGGjJUEZDWnucqsx+vlagLgUe5v7dOVzAlpEgjY/ FWeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=P0yQi0HNQ13dhVyIo2M7o4nOBisTgXt5Vw2SUTZ2Aa4=; b=PTqztbvCFJdDm/iMiISh8/YJdi7h9eebE73QFqjPkFUOQ5yxETDSZbmVD+8Ky5Tt6w Xmz0N4iB0b08ItLOzXWAwxxHcVig+Dq0LM5iVHArUtP25yO5BI8yN1587CZriugtSMXA N3L3YEkkMtwgFo5RzHeSqimE9yRSIcdLYcgti2OQ9xyAdtyRZ1ErJy2fyF6CRh25PZgN G+lx+bJZpYN7iNfP+Tq2ipcpjRXuNMz03oVyS1M/TXfyeHGxuJZPpFj2n/+AK0fY/DKc Dcsl4OYGTJ+90V3/qnWcRDVWsfM6a+TmGuiNQA/MIwrsy2yM220RUsF4/eXanGD74qBn /y6w== X-Gm-Message-State: AE9vXwNZkWEMlSxYwxefLQAn17NQfebDVtj17ANzk9bJduT+BHzH+NKAAOo7KSPNyywylmQwjDzNLHxS4azVEA== X-Received: by 10.157.61.166 with SMTP id l35mr28088236otc.52.1473732369942; Mon, 12 Sep 2016 19:06:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.131.70 with HTTP; Mon, 12 Sep 2016 19:06:09 -0700 (PDT) From: Jeffrey Walton Date: Mon, 12 Sep 2016 22:06:09 -0400 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] What does it mean to resynchronize RFC 7539 ChaCha? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 02:06:16 -0000 I'm working on a test suite that includes RFC 7539 ChaCha. The IETF's implementation is mildly different from Bernstein's ChaCha, and I want to make sure the test suite behaves as expected. If one performs a resynchronize on IETF ChaCha, does it: (1) reset block counter + apply new IV; or (2) apply new IV? Or maybe something else? Thanks in advance. jeff From nobody Wed Sep 14 22:57:51 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F5D12B005 for ; Wed, 14 Sep 2016 22:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtj0wt__ma1W for ; Wed, 14 Sep 2016 22:57:47 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8F512B0CA for ; Wed, 14 Sep 2016 22:57:47 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id k186so46907004wmd.0 for ; Wed, 14 Sep 2016 22:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3gj9xvbNrEADa2XLmJMBkG7gjVpn8ectz0LNjgwhqnM=; b=CXsFnLEL9WtYBNefC8E8SU+4G4/en0iCHuG632RgQGndbEWHbryQmBEg51caZ8f4S8 BahnW0d5vV3LzC5eibdqQCN7KzmJW+h9C8zTYKYkB5w76eSV6ZCk3uaiQ9ECkvYACeHS aoId6FQVrNff4igIvpKM3rl/fTsZUIKGF4UNZesbcOfo9mSrbf7hsy0LSy9yxYVSNVaC VeTwZdphpiqJyaOCiM/ROUJSLPuODGlBvjtDELpgKBw6panQfZyPGS6A7wo12ImsshPz s7hwp9zO0Xh22Q7ZB+uqv+eOJcRcFqQTrLCERUmIphm9z58RZMmvT46br2UTKdu07+i5 ygTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3gj9xvbNrEADa2XLmJMBkG7gjVpn8ectz0LNjgwhqnM=; b=MKGNQIWYWA+Hh+nvXW/4GuggLZKkvXfP2/ErGpbZoWqybDDU6W2eMJZhs3keKQpDbL LVmCtRgnqu7vIUZEX5+hBof3CAQylg70z7Yc3TuQXAu2Jqq3rYK2awTxm6nCwHl3jYaN yJVe7Z/pdHrBIwPDcoDt/9KbRGsvcWJDPn7K+g5+MnWxJj+08VTkKBLIQfA61MHu8rZw EUlJxiLukztoH6YugJPieZK6+N/89lJDbv8Bu/a7DOPGUyYfLHMmpHB7kwupC+tjU4UO Yck3D7L6RMg/v4qvgEC3w4fF15GISBbGZhhJnj3iKHyOuy6YYjGdcCjaKtFju8mLOVTo JW6g== X-Gm-Message-State: AE9vXwOUBZ/G/96sUE8aJtV7OOUkgn3UsKB+KziJM6pkw6bTACCBwQHbECJqcIdTHoBz4g== X-Received: by 10.28.166.149 with SMTP id p143mr1061177wme.21.1473919065731; Wed, 14 Sep 2016 22:57:45 -0700 (PDT) Received: from macbook-pro-2.mshome.net ([176.13.228.140]) by smtp.gmail.com with ESMTPSA id vs7sm1165410wjb.10.2016.09.14.22.57.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Sep 2016 22:57:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Thu, 15 Sep 2016 08:57:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <831D914D-FB60-4118-93E2-EAB648B0B778@gmail.com> References: To: noloader@gmail.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] What does it mean to resynchronize RFC 7539 ChaCha? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 05:57:49 -0000 Hi, Jeff > On 13 Sep 2016, at 5:06 AM, Jeffrey Walton wrote: >=20 > I'm working on a test suite that includes RFC 7539 ChaCha. The IETF's > implementation is mildly different from Bernstein's ChaCha, and I want > to make sure the test suite behaves as expected. Yes. the original ChaCha received a 64-bit nonce and included a 64-bit = block counter. This allows for 2^64 encryptions, each of 2^64 blocks. = Each block is 512 bit or 64 octets, so you can have plaintexts as big as = 2^70 octets. We changed that so that the nonce is 96-bit and the block = counter is 32-bit, limiting the size of the plaintext to 2^38 octets or = 256 GB. This choice was motivated by several reasons: 1. RFC 5119 requires a 96-bit nonce 2. AES-GCM already had a 96-bit nonce 3. Although a single key is rarely used for more than 2^64 encryptions, = it=E2=80=99s sometimes necessary to partition the nonce space. Consider = multi-sender group IPsec (RFC 6407) 4. For most things interesting to the IETF, 256 GB is more than enough. = IPsec packets and TLS records are under 64KB and MIME entities are = typically smaller than that. This is limit. 256 GB is not enough to encrypt all files with one = encryption operation. But we thought it would be a better fit for IETF = protocols. > If one performs a resynchronize on IETF ChaCha, does it: (1) reset > block counter + apply new IV; or (2) apply new IV? Or maybe something > else? Not sure what you mean by resynchronize. But if you mean changing the = nonce, then yes, the block counter resets to zero. Note that all uses of RFC 7539, including the TLS draft and IPsec RFC do = not use ChaCha alone, but the ChaCha20-Poly1305 AEAD. In that = construction the block counter of zero is used to generate the one-time = Poly1305 key, and encryption begins with block counter 1. HTH Yoav= From nobody Sun Sep 18 11:40:23 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1F212B015 for ; Sun, 18 Sep 2016 11:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ3_kep6tzpp for ; Sun, 18 Sep 2016 11:40:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F9F3128B37 for ; Sun, 18 Sep 2016 11:40:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3220FBE47 for ; Sun, 18 Sep 2016 19:40:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MenOlQYfWkJ for ; Sun, 18 Sep 2016 19:40:15 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2ADCBE38 for ; Sun, 18 Sep 2016 19:40:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1474224015; bh=cFUxvbmcMdo8beWHx7TlhT/VBPQJjpxx9V8BjuuNhjg=; h=Subject:References:To:From:Date:In-Reply-To:From; b=q7ZyADOsy1bc7bpPuEd7IU8Tim52Q3bzZ0174hdfhT/aJ87AOkhsGzBz6H8hX31cm dI7vrFsT5MD6l+tyqHnfEKpurUj51kB8DddAy++sytY/pdhZkRfAaoJ2o5s4XI3FM8 4zuARV0UXYX/+j7kySShlRsugKI4bkoA5kI6UIEs= References: <1474209373.3075077.729281857.674CFBF6@webmail.messagingengine.com> To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <1474209373.3075077.729281857.674CFBF6@webmail.messagingengine.com> Message-ID: <7191cd88-079c-891f-636e-1eae7f15d9d1@cs.tcd.ie> Date: Sun, 18 Sep 2016 19:40:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1474209373.3075077.729281857.674CFBF6@webmail.messagingengine.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090508070904040502090502" Archived-At: Subject: [saag] Fwd: [dispatch] Straw man text for proposed charter: Security Event X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2016 18:40:22 -0000 This is a cryptographically signed message in MIME format. --------------ms090508070904040502090502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI. Thoughts on this to the list mentioned below, or to Kathleen, Alexey and I, if not to a list. Ta, S. -------- Forwarded Message -------- Subject: [dispatch] Straw man text for proposed charter: Security Event Date: Sun, 18 Sep 2016 15:36:13 +0100 From: Alexey Melnikov To: DISPATCH Hi, I received a proposal to charter a new WG. Proponents are discussing it on id-event@ietf.org mailing list. Note, that at the moment it is not clear whether this will land in ART or SEC Area, this is to be decided. Please comment on the strawman Charter, which is shown below: Chairs: TBD Applications and Real-Time Area Directors: TBD Applications and Real-Time Area Advisor: TBD Mailing Lists: General Discussion: id-event@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/id-event Archive: https://mailarchive.ietf.org/arch/browse/id-event/ Description of Working Group: Many identity related protocols require a mechanism to convey messages between systems in order to prevent or mitigate security risks, or to provide out-of-band information as necessary. For example, an OAuth authorization server, having received a token revocation request (RFC7009) may need to inform affected resource servers; a cloud provider may wish to inform another cloud provider of suspected fraudulent use of identity information; an identity provider may wish to signal a session logout to a relying party. It is expected that several identity and security working groups and organizations will use Identity Event Tokens to describe area-specific events such as: SCIM Provisioning Events, OpenID RISC Events, and OpenID Connect Backchannel Logout, among others. The Security Event working group will produce a standards-track Event Token specification that includes: - A JWT extension for expressing security events - A syntax that enables event-specific data to be conveyed This Event Token specification will be event transport independent. The working group will also develop a simple standards-track Event Delivery specification that includes: - A method for delivering events using HTTP POST (push) - Metadata for describing event feeds - Methods for subscribing to and managing event feeds - Methods for validating event feed subscriptions Goals and Milestones: October 2016 - Initial adoption of event token and event delivery drafts February 2017 - WG last call of event token draft April 2017 - Event token draft to IESG as a proposed standard July 2017 - WG last call of event delivery draft September 2017 - Event delivery draft to IESG as a proposed standard November 2017 - Work completed; discuss rechartering if needed _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------ms090508070904040502090502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MTgx ODQwMTRaMC8GCSqGSIb3DQEJBDEiBCCzyBtJHKtodv3OA5k+mBD14QVg47y2Nz+APItgLf/y pDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQC14UfnzBZquMZRBXMlbJ9S+ApwSo6Ygvihy1LOnhsJC0/Ygg/npPPr dbljpv1m7AvZKY9nrRYArvRJJmPTb/dMuHBdSZuaNRWO/Y7tDvqjHme82yqjy5m2ajtm4Krn 5aNEAQ/MO3XhnAatmz5ufvlKLY5rwsPC147xDvAI0A/ahyUMrJeTQuCyH8fkNQjUh8+5QfGF vYviRlOc1jPa3ys0YZ8AAtQmxK2Gcmoc57Z2d8r2QR6a6Cx8Ap0oc5XpvorwNzyu37tiOB3d iT7VVeBuC2kKdxbV0N0yDbpW0PnRrwABx0U4kYvSAYJOTE+ErjFOvPxaauTOw2DknyiI3Se+ AAAAAAAA --------------ms090508070904040502090502-- From nobody Mon Sep 19 01:31:18 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EDA12B1F3 for ; Mon, 19 Sep 2016 01:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0d0JHQTJa8I for ; Mon, 19 Sep 2016 01:31:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5232412B1F1 for ; Mon, 19 Sep 2016 01:31:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8D94BE4D for ; Mon, 19 Sep 2016 09:31:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKXLSWth0cmp for ; Mon, 19 Sep 2016 09:31:04 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E140ABE53 for ; Mon, 19 Sep 2016 09:31:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1474273862; bh=fS02OkMj4ScbBKrMYrICzRJkYfkehxojHzI/BL/0RsE=; h=Subject:References:To:From:Date:In-Reply-To:From; b=dPd55b+1jPPonQHAfheeyvAcUR7V1SYPPNbQNoVYJlNSl2aluMoib4lux1nfIIf8r prJctUtkd/LQPKHYHv5CHT3fBhjKl+Q0jQT72BiGpB9gLsmMuxd/iJyqDfylhOYK2R GHFArz/BD+hxVWDBCZx0mbEBchen4QpNxfkoNTlY= References: To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: <23837a1e-47fc-b7e5-873c-edcb965af3c4@cs.tcd.ie> Date: Mon, 19 Sep 2016 09:31:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010505080801090909040107" Archived-At: Subject: [saag] Fwd: FW: New Liaison Statement, "LS on work items Big Data security in ITU-T SG 17" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 08:31:16 -0000 This is a cryptographically signed message in MIME format. --------------ms010505080801090909040107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FYI. Ping Kathleen and/or I if interested. S -------- Forwarded Message -------- Subject: FW: New Liaison Statement, "LS on work items Big Data security in ITU-T SG 17" Date: Mon, 19 Sep 2016 08:16:55 +0000 From: Scott Mansfield To: stephen.farrell@cs.tcd.ie , Kathleen Moriarty (kathleen.moriarty.ietf@gmail.com) This is for information. Please let me know if you need me to distribute this in some way. Regards, -scott. -----Original Message----- From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] Sent: Friday, September 16, 2016 12:13 PM To: Carsten Bormann ; Hannes Tschofenig ; Kepeng Li ; Jaime Jim=C3=A9nez Cc: Stephen Farrell ; Scott Mansfield ; Kepeng Li ; Authentication and Authorization for Constrained Environments Discussion List ; Kathleen Moriarty ; Constrained RESTful Environments Discussion List ; Carsten Bormann ; Ben Campbell ; Alexey Melnikov ; jhnah@etri.re.kr; Hannes Tschofenig ; Jaime Jim=C3=A9nez ; itu-t-liaison@iab.org; Alissa Cooper Subject: New Liaison Statement, "LS on work items Big Data security in ITU-T SG 17" Title: LS on work items Big Data security in ITU-T SG 17 Submission Date: 2016-09-16 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1492/ From: "Martin Euchner" To: Kepeng Li ,Hannes Tschofenig ,Carsten Bormann ,Jaime Jimenez Cc: Constrained RESTful Environments Discussion List ,Kepeng Li ,Alexey Melnikov ,Scott Mansfield ,Ben Campbell ,Stephen Farrell ,Kathleen Moriarty ,Jaime Jimenez ,Hannes Tschofenig ,Carsten Bormann ,Authentication and Authorization for Constrained Environments Discussion List ,Alissa Cooper ,itu-t-liaison@iab.org, Response Contacts: jhnah@etri.re.kr Technical Contacts: Purpose: For information Body: ITU-T Study Group 17, Security, is please to inform you of two items regarding big data security. The attachments are the baseline text for ongoing work on draft Recommendation of ITU-T X.websec-7, Reference monitor for online analytics services, and the template of new work item X.srfb, Security requirements and framework for Big Data analytics in mobile Internet services that was established at our September 2016 meeting. We are looking forward to further collaboration with you on those items. Attachments: 2 -X.websec-7: Draft Reccomendation IETU-T X.websec-7, Reference monitor for online analytics services; -New work item template for X.srfb, Security requirements and framework for Big Data analytics in mobile Internet services Attachments: X.websec-7: Draft Reccomendation IETU-T X.websec-7, Reference monitor for online analytics services https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-09-16-itu-t-sg= -17-core-ace-ls-on-work-items-big-data-security-in-itu-t-sg-17-attachment= -1.pdf New work item template for X.srfb, Security requirements and framework for Big Data analytics in mobile Internet services https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-09-16-itu-t-sg= -17-core-ace-ls-on-work-items-big-data-security-in-itu-t-sg-17-attachment= -2.pdf Liaison https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2016-09-16-itu-t-sg= -17-core-ace-ls-on-work-items-big-data-security-in-itu-t-sg-17-attachment= -3.pdf --------------ms010505080801090909040107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MTkw ODMxMDFaMC8GCSqGSIb3DQEJBDEiBCCtZqtKiiK2oBsDkbj7oLnRgKIOQ2GG9U07yz0RZ5SI uDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAO1lddUE2v+dRBuSvZlNiZ8qlxiSotASRksp0UYjdD4O313TuPH93J JH3S2QkTbZg65qZ2Yjd4o85j3tbe3N3Tajc8hXWVDnb49jFBAjdWFCiNkgQCNn1L1XU/YWyO FtNVJDhXfupPU3mRRdBte/BMOVNXcgxj8qpmYATqnVi+exGdSUGDnH+iXfIV794cFpeBX8k8 /vE/VhDt9YAW9k/1/YosjMje11aSKU9dgZWQ54PRFMp+nOWHp2TZXcPKXA2MXb3X3c0Ua5/B YFQituIREpI3dcMGcQ665vukAQl8Hd0Np7N127g3SiWs+7J0ZyLnQ+qNtPDNk2IgClI+VlKi AAAAAAAA --------------ms010505080801090909040107-- From BATV+e4a5c8c88c3adab274df+4775+infradead.org+dwmw2@bombadil.srs.infradead.org Mon Sep 19 03:23:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A401312B2E0; Mon, 19 Sep 2016 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ4Gc9lMpyKX; Mon, 19 Sep 2016 03:23:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB5E12B2C9; Mon, 19 Sep 2016 03:23:24 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1blvjP-00067V-Ju; Mon, 19 Sep 2016 10:23:23 +0000 Message-ID: <1474280601.144982.263.camel@infradead.org> From: David Woodhouse To: saag@ietf.org, spasm@ietf.org Date: Mon, 19 Sep 2016 11:23:21 +0100 Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-D4sUIoZYXYCq0P1yK9tm" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: [saag] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 10:27:04 -0000 --=-D4sUIoZYXYCq0P1yK9tm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (I hope the cross-post is acceptable; apologies if not.) Various applications will optionally make use of X.509 certificates for client authentication. Those certificates, and the associated private keys, may be found in files on the file system, in PKCS#11 tokens, or in another OS-specific form of certificate database. In my opinion, it would be nice to have some consistency between applications. If a user has a certificate in a certain form, it would be nice for that to Just Work=E2=84=A2 across all well-behaved applications= . In practice, nothing could be further from the truth. Applications *all* suck, and various certificates will spuriously fail to work in one application but not another. Or work if the application is build against crypto library $A but not when built against crypto library $B. Or for objects in PKCS#11 each application might require a *different* identifier string to locate the same object. If they support PKCS#11 at all. I'd like to fix that. I would like to achieve a consensus that a "well- behaved application" SHOULD accept certificates and keys in various (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. I have slowly been working on this. I have encouraged the Fedora distribution of Linux to amend their packaging guidelines to state that software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it would accept a filename. And that software SHOULD load the PKCS#11 tokens which are indicated by the system configuration. We have already fixed various applications to comply with these requirements, and I even mentored a Google Summer of Code project which added RFC7512 support to NSS=C2=B2. I believe the Fedora packaging guidelines have been a success, and I would like to expand the scope. There's no *reason* this should be Fedora-specific, or even specific to Linux or POSIX operating systems. So I'm looking for a forum in which to reach a consensus on what should be accepted, and to publish those guidelines. I'd be very interested in hearing suggestions. Simultaneously, I'm also looking at expanding the technical scope. For my own project, the OpenConnect VPN client, I have started to collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypted = with various algorithms. I have yet to embark of the joy of files with non- ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a bo= ttle of vodka ready to help me do so. My test suite also includes PKCS#11 tests including private keys where the token doesn't expose the public component (which made OpenSSL crash until yesterday, yay!) and certificates with the CKA_PRIVATE attribute set, so some software will fail to *find* them. I am thinking of splitting my torture test out from OpenConnect itself, and making it available as a project in its own right. I can, of course, lobby to expand the Fedora guidelines to state that all software packaged for Fedora SHOULD pass the torture test suite, but I think it makes sense to aim for a wider consensus than that. Opinions welcome... does it make sense to attempt to publish an informational RFC outlining such "expectations"? Or should it take some other form? Or should I just not bother, and continue to push it from the Fedora angle, since it's getting into a lot of upstream software already? I also expect some heckling at my specific test cases =E2=80=94 do we *real= ly* expect everyone to support DSA keys still? And PEM files encrypted the old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? (I can accept 'no' answers to the latter two only if expressed in a form which lets me file bugs against ancient "enterprise" software to stop *creating* them that way...) --=20 dwmw2 =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling =C2=B2 https://bugzil.la/1162897 =C2=B3 http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/test= s/Makefile.am --=-D4sUIoZYXYCq0P1yK9tm Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTE5MTAyMzIxWjAvBgkqhkiG9w0BCQQxIgQgLQ7nkMZwxo8HmMkbSxFaGkVXPrivTKrzNJ8J PAbDyLAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICADwo qNvdEERNUXHfDagCLkb3sCjBqRhCbn+vWijyyjEW5QeOn4A0Bb3OAK4n3h88sxEvzdIGV3R7w1ca fLftiQnWDOWcIKJmj8idmbWrB25EPW5OZEk+/xNygqtEFVFl6xES9WPi6jjSSmXhom4cOjIU43Dp 4eVBm0WIKWVacQ9/eaWWzSrpdDwXyh4cZ7unWxoHaDl+mzAUthB5XHtA664fWayzLQivqh0tuyNj X9hcEiI5APCf/OhIlDua34zuP3hg94K3nPyuzSLDFwe8iPxT41L8XvGlXR+dz6UDJyt/Itr0NcKI L3V/+IzXgrQkgAhHYoYUGmYtZaCcdTNaWe7NzF+8yNhsqMMUsZ8Rsb+sP/uHyQjFQTpJCf6bVN7G 8TqkfiKC0yOrZLhFlzL4BsUyhGkmtxUOb5gJbroaKxITG7VLD/5Eva3AJfmo61vBo7ch/ULoY94j /O11Kp6Gk7R07oN8EKoTtlpJLti+p7jxtH9Zedi9wCgE3DKPGHZVrNn7BEKm7Zb2NVtLzl/atiJs vfaUtwWkHT4EdQKfOt4xglP8QzBRRD+JMcqBTGP7qNZNqC0g7d5lLRioLQGsAk1u/Z7nad0Q/pzP zrb6o0qeoEcBLGZQEHucC5ZDn8vMdkMF9KGYBzYRXT/TNlH5TUA9W42xZA9XyfSwf7+Ogw9oAAAA AAAA --=-D4sUIoZYXYCq0P1yK9tm-- From nobody Mon Sep 19 04:27:02 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B307412B039 for ; Mon, 19 Sep 2016 04:27:00 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCpgqWeYNQRA for ; Mon, 19 Sep 2016 04:26:58 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D6D12B34C for ; Mon, 19 Sep 2016 04:26:57 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id l131so103804729lfl.2 for ; Mon, 19 Sep 2016 04:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZRO4dTK4jHWvRsEkdBBteCNnYLA41DbXtpTDxDlI3IY=; b=YcUJPC3oGKAwaDGXMw8l9eubSLtqBe5ERn2rApbuHadjLacK+HKnaakVAtt8ZrZAw9 gc3gQ+BcLsLM7wBhhdNpDnqiB6/AwTV9/a7crb7ingsihFg+2U8c2ARa5PvDfzF5ZU6j iAEHV97BbhAsN0IitLUCUWU3s0/e9wJ8tW2kBQclryY1GiBHHJOENgTxrdzp+n6IxXwx 1SgfpV4zjVNK6uvX39AiBOU1dEScf7XWYrNwp+mHtCX2xnf51zLNGkGTaQnLbXa11mFS E43jvC+jyWSUq62Z0+I3pJxiyIKwetR8Bo26yRS+XlUPovRIOYjE7HZa09qg4EIbyHtx rBJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZRO4dTK4jHWvRsEkdBBteCNnYLA41DbXtpTDxDlI3IY=; b=L6CBKkm7iWwo+gO3LTqt+lFafA0hAxyBD0YbN0Ie18TKk5o7lQis7g2u6pW2eyVK4m OzNdPRz8RKRb0FjFmIqMPcz4eidBw40r08DcggbIRIGaMPYxVIpjBGsdMe6eczfFEfIX uUn9ZtGLow9l/0SN+xv9NRytYk0DdrtvUOivZFhXb6m+nWc6sahwG/L43UaBuSLgYrSE NFNo9f+k5G+IiwtmFPkV8ejiySrIgc34YJr+azglMLWqVIZiWH54ug5ug9he2gSFJ0u5 YDd/oiSC6CMCkEbQbClhwZt3NNc5iQt+7eTPTMjAYoYyK+oH5DGRfpxfE0dodo7kOmlu zGJA== X-Gm-Message-State: AE9vXwNbbGu8/5HblhpIX3UtrYtZxGRAhjd0AaclVL2iKXiYJ/GJDoCCVce4HkHU4cG9YV2QwiAVNHtcCqX49w== X-Received: by 10.25.76.136 with SMTP id z130mr1110893lfa.126.1474284415481; Mon, 19 Sep 2016 04:26:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Mon, 19 Sep 2016 04:26:14 -0700 (PDT) In-Reply-To: <1474280601.144982.263.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> From: Ted Lemon Date: Mon, 19 Sep 2016 07:26:14 -0400 Message-ID: To: David Woodhouse Content-Type: multipart/alternative; boundary=001a114b1738e20a56053cda9689 Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 11:27:01 -0000 --001a114b1738e20a56053cda9689 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The effort is certainly worth doing. I've encountered the same problem, and also find it frustrating. It might be worth writing an informational doc; the challenge would be socializing it to the people who need to read it. On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse wrote: > (I hope the cross-post is acceptable; apologies if not.) > > Various applications will optionally make use of X.509 certificates for > client authentication. > > Those certificates, and the associated private keys, may be found in > files on the file system, in PKCS#11 tokens, or in another > OS-specific form of certificate database. > > In my opinion, it would be nice to have some consistency between > applications. If a user has a certificate in a certain form, it would > be nice for that to Just Work=E2=84=A2 across all well-behaved applicatio= ns. > > In practice, nothing could be further from the truth. > > Applications *all* suck, and various certificates will spuriously fail > to work in one application but not another. Or work if the application > is build against crypto library $A but not when built against crypto > library $B. Or for objects in PKCS#11 each application might require a > *different* identifier string to locate the same object. If they > support PKCS#11 at all. > > I'd like to fix that. I would like to achieve a consensus that a "well- > behaved application" SHOULD accept certificates and keys in various > (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. > > I have slowly been working on this. I have encouraged the Fedora > distribution of Linux to amend their packaging guidelines to state that > software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it > would accept a filename. And that software SHOULD load the PKCS#11 > tokens which are indicated by the system configuration. > > We have already fixed various applications to comply with these > requirements, and I even mentored a Google Summer of Code project which > added RFC7512 support to NSS=C2=B2. > > I believe the Fedora packaging guidelines have been a success, and I > would like to expand the scope. There's no *reason* this should be > Fedora-specific, or even specific to Linux or POSIX operating systems. > So I'm looking for a forum in which to reach a consensus on what should > be accepted, and to publish those guidelines. I'd be very interested in > hearing suggestions. > > > Simultaneously, I'm also looking at expanding the technical scope. > For my own project, the OpenConnect VPN client, I have started to > collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various > PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypte= d with > various algorithms. I have yet to embark of the joy of files with non- > ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a = bottle > of vodka ready to help me do so. > > My test suite also includes PKCS#11 tests including private keys where > the token doesn't expose the public component (which made OpenSSL crash > until yesterday, yay!) and certificates with the CKA_PRIVATE attribute > set, so some software will fail to *find* them. > > I am thinking of splitting my torture test out from OpenConnect itself, > and making it available as a project in its own right. > > I can, of course, lobby to expand the Fedora guidelines to state that > all software packaged for Fedora SHOULD pass the torture test suite, > but I think it makes sense to aim for a wider consensus than that. > > Opinions welcome... does it make sense to attempt to publish an > informational RFC outlining such "expectations"? Or should it take some > other form? Or should I just not bother, and continue to push it from > the Fedora angle, since it's getting into a lot of upstream software > already? > > I also expect some heckling at my specific test cases =E2=80=94 do we *re= ally* > expect everyone to support DSA keys still? And PEM files encrypted the > old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? > > (I can accept 'no' answers to the latter two only if expressed in a > form which lets me file bugs against ancient "enterprise" software to > stop *creating* them that way...) > > -- > dwmw2 > > =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling > =C2=B2 https://bugzil.la/1162897 > =C2=B3 http://git.infradead.org/users/dwmw2/openconnect.git/ > blob/HEAD:/tests/Makefile.am > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a114b1738e20a56053cda9689 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The effort is certainly worth doing. =C2=A0 I've encou= ntered the same problem, and also find it frustrating. =C2=A0 It might be w= orth writing an informational doc; the challenge would be socializing it to= the people who need to read it.

On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse <d= wmw2@infradead.org> wrote:
= (I hope the cross-post is acceptable; apologies if not.)

Various applications will optionally make use of X.509 certificates for
client authentication.

Those certificates, and the associated private keys, may be found in
files on the file system, in PKCS#11 tokens, or in another
OS-specific form of certificate database.

In my opinion, it would be nice to have some consistency between
applications. If a user has a certificate in a certain form, it would
be nice for that to Just Work=E2=84=A2 across all well-behaved applications= .

In practice, nothing could be further from the truth.

Applications *all* suck, and various certificates will spuriously fail
to work in one application but not another. Or work if the application
is build against crypto library $A but not when built against crypto
library $B. Or for objects in PKCS#11 each application might require a
*different* identifier string to locate the same object. If they
support PKCS#11 at all.

I'd like to fix that. I would like to achieve a consensus that a "= well-
behaved application" SHOULD accept certificates and keys in various (TBD) file formats and also accept PKCS#11 URIs according to RFC7512.

I have slowly been working on this. I have encouraged the Fedora
distribution of Linux to amend their packaging guidelines to state that
software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it
would accept a filename. And that software SHOULD load the PKCS#11
tokens which are indicated by the system configuration.

We have already fixed various applications to comply with these
requirements, and I even mentored a Google Summer of Code project which
added RFC7512 support to NSS=C2=B2.

I believe the Fedora packaging guidelines have been a success, and I
would like to expand the scope. There's no *reason* this should be
Fedora-specific, or even specific to Linux or POSIX operating systems.
So I'm looking for a forum in which to reach a consensus on what should=
be accepted, and to publish those guidelines. I'd be very interested in=
hearing suggestions.


Simultaneously, I'm also looking at expanding the technical scope.
For my own project, the OpenConnect VPN client, I have started to
collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various
PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypted = with
various algorithms. I have yet to embark of the joy of files with non-
ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a bo= ttle
of vodka ready to help me do so.

My test suite also includes PKCS#11 tests including private keys where
the token doesn't expose the public component (which made OpenSSL crash=
until yesterday, yay!) and certificates with the CKA_PRIVATE attribute
set, so some software will fail to *find* them.

I am thinking of splitting my torture test out from OpenConnect itself,
and making it available as a project in its own right.

I can, of course, lobby to expand the Fedora guidelines to state that
all software packaged for Fedora SHOULD pass the torture test suite,
but I think it makes sense to aim for a wider consensus than that.

Opinions welcome... does it make sense to attempt to publish an
informational RFC outlining such "expectations"? Or should it tak= e some
other form? Or should I just not bother, and continue to push it from
the Fedora angle, since it's getting into a lot of upstream software already?

I also expect some heckling at my specific test cases =E2=80=94 do we *real= ly*
expect everyone to support DSA keys still? And PEM files encrypted the
old OpenSSL way? And PKCS#12 files encrypted with MD5-DES?

(I can accept 'no' answers to the latter two only if expressed in a=
form which lets me file bugs against ancient "enterprise" softwar= e to
stop *creating* them that way...)

--
dwmw2

=C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling
=C2=B2 https://bugzil.la/1162897
=C2=B3 http://git.i= nfradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefil= e.am

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


--001a114b1738e20a56053cda9689-- From nobody Mon Sep 19 09:36:33 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5F812B46C for ; Mon, 19 Sep 2016 09:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap3FiN-T9mWz for ; Mon, 19 Sep 2016 09:36:28 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 486CB12B488 for ; Mon, 19 Sep 2016 09:35:09 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n185so15460566qke.1 for ; Mon, 19 Sep 2016 09:35:09 -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:from:date:message-id :subject:cc; bh=5/mIgAuWk/zLNNl6zvkS3brOLxyPA+7SRVWp5HC5ceY=; b=hmNMX1nptKjrsdOKiGgoX5219AkQU+tVlT7uv5eZ6HnV1Dcm4Rw7jjUC+uQaVEIX+s 2aYfkU86TXZIo9zioBfn0goWo5r1FEGsuwIih87YkDWEobRtMnOHmhNoiQXj5TlVNN2b LFIJgIC1wHZ38GehaNDNOFuJWeGUdeiLUm/2KJ3zTsMWAgvLE8JE3XtW2zk1NhkK5cdW 4wIuBCowb/E5pxKa+FthHN/LMJF5ZZgB1jpXvGvUiPtRIks0RQXsGkij0ExkdvzXuXDc 1kPHjPPIJ65a3ieEEkcJbuzW1PfjaYotW6kwS9HWPxzIl5+tpgvYUKjZVEHjCA6ZZ+4Z yf+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc; bh=5/mIgAuWk/zLNNl6zvkS3brOLxyPA+7SRVWp5HC5ceY=; b=hq8TRrdWcxXAV+SNblLxtjeoKAY0J1VC4CNsXICwJdeZVZLuDeAGK2sOTJwwThrmzs CDb2fgEDHA1MN3m6v3seuXJ1q8M2oqkOIiM9i336a4GAAiJt+Ltox3VvPHcolOG1Fvu1 pOq7rqUw9+WdgN/mKiOk951GpO+P0Aw0bRE/u4aOycHjtQyUBLuBLUl47or4I1lM0OeO 1bVPa/0cCVy0DlOT4aUpHoMdWgwUqdwvYhjPHgW0rBLqNm8IZLCauni+9X/MiOllBWgU wp5P/yRIwqYwmI5NcYvU7C1R3sIYn713DNh3EUVhumkgY8u8/DWJvcyzLsE0skDIXN5c 7Byg== X-Gm-Message-State: AE9vXwPDy+OwJ4fJ0GPnIyek7gmN1F0ZBYg1zJ0eJcF6DxCUWEA//P93VT2e245x1OczWF/2p/43+lnyyw8rzg== X-Received: by 10.55.160.145 with SMTP id j139mt32127057qke.167.1474302908230; Mon, 19 Sep 2016 09:35:08 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Mon, 19 Sep 2016 09:35:07 -0700 (PDT) In-Reply-To: <1474280601.144982.263.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> From: Phillip Hallam-Baker Date: Mon, 19 Sep 2016 12:35:07 -0400 X-Google-Sender-Auth: 2SBL5OEcofPE64Cw0PDcERGhQdg Message-ID: Content-Type: multipart/alternative; boundary=94eb2c076206230f3e053cdee561 Archived-At: Cc: spasm@ietf.org, "saag@ietf.org" Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 16:36:30 -0000 --94eb2c076206230f3e053cdee561 Content-Type: text/plain; charset=UTF-8 This is a very common problem and one that I encounter on an hourly basis as I write code for the Mesh. There are three separate formats used for public keys in SSH and four for private. This is all stuff that has dropped off the table as far as the standards groups are concerned because 'it isn't protocol that goes on the wire'. Except of course it does. The way I think we have to approach a solution is to use a container of some type whether that is MIME or JSON that has a slot for metadata describing the content type to follow: Content-Type: application/pkix-certificate Content-Encoding: BASE64 3ljkrf3kjrkj3hrfkjh3fjkh3jkfh34fkjh== It isn't too difficult to allow a choice of MIME or JSON for the container as the JSON will always start with a { and the MIME never will. I use JSON-B which is simply JSON with an added code point that lets me drop specified length binary encoded data into a JSON document at a particular point. But that is because some of my files are rather large. --94eb2c076206230f3e053cdee561 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thi= s is a very common problem and one that I encounter on an hourly basis as I= write code for the Mesh. There are three separate formats used for public = keys in SSH and four for private.

This is all stuff that has dropped off the table as far as the s= tandards groups are concerned because 'it isn't protocol that goes = on the wire'. Except of course it does.

The way I think we have to approach a solution is to u= se a container of some type whether that is MIME or JSON that has a slot fo= r metadata describing the content type to follow:

Content-Type: application/pkix-certificate
Content-Encoding: BASE= 64

3ljkrf3kjrkj3hrfkjh3fj= kh3jkfh34fkjh=3D=3D

It is= n't too difficult to allow a choice of MIME or JSON for the container a= s the JSON will always start with a { and the MIME never will.=C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">
I use JSON-B which is simply J= SON with an added code point that lets me drop specified length binary enco= ded data into a JSON document at a particular point. But that is because so= me of my files are rather large.


--94eb2c076206230f3e053cdee561-- From nobody Mon Sep 19 11:54:34 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0192512B4E6; Mon, 19 Sep 2016 11:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOuRSQP-WT4x; Mon, 19 Sep 2016 11:54:28 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6284C12B4B3; Mon, 19 Sep 2016 11:54:28 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id o139so5784143vka.1; Mon, 19 Sep 2016 11:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JhRGZvApYryGgCIQkMt8usoF/Sb5lPdO2+g/GtH86Tw=; b=CIvdoVtsMlpZSq29Qm42FviG3uxazk0HW3PMPA7ab3s1XZmlF6NoWMUlBqYqW9vQoR Yz4Hmlq5KFCy5ahssNx5ZF2eRh4Es+OjDeQkOqppC4n6no5vjwjiVErriz3WLHL0Uak0 sP36WVfThdec6Lh5t5oxs7PHhxTEoFP6ZBrd9j+byfV2tn3OvnvRm6OkVV00kKG6NltK QxJW7x89SHv0gks0ehli4Jgtfv7UuWKISWPOU7r5+/oaPyKuI6s81CnAF53KY8TsnCcd 0rngpA+QGnVjp30+YHhVDjbSGBgSpix4R2zluYuc3XtHAuRFX5meZWhS3DV/B5xr6+7/ BL7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JhRGZvApYryGgCIQkMt8usoF/Sb5lPdO2+g/GtH86Tw=; b=jVRzilkikFOFBqQjSKhz1aAiDDC7oUWTH04S+TrbCxdIssOMKo1Ry8nReiFtTT7X0v LqeXq6FSOCjWFs6AI2iW5N7Saz62ryRnc+uPHwF9zmSwqnsI6JMJiLm5ZKyuZ+/ZxsPk EqFYJaXu27Lw4Uw5UGWOU83B+Uca4AjYHlBSJWiBOIkbRs1H+eQfVIkYxhPOu+a7JTDF 8+sHQv3GEpSNyFQG4Ss/L9bxpjdV+quyKx5IKH/4oFqfxXmGKgQKrDvV+I2Skt0Yuhmc r156Dnp7OnehqD9zNBvXqjpB/xBfoyGC1nEhBK/bO83jNXHFIdwGSn+CsEZw0t1O+143 slMA== X-Gm-Message-State: AE9vXwPNaE6PU+0x9a6HOG0HZ8AKlQHLHte7jScXzdMqfbaTvgM9gcZAlEmdfVWKw9T03xviDKvJtLW3HNatcQ== X-Received: by 10.31.158.1 with SMTP id h1mr503977vke.44.1474311267371; Mon, 19 Sep 2016 11:54:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.102 with HTTP; Mon, 19 Sep 2016 11:54:26 -0700 (PDT) Received: by 10.176.4.102 with HTTP; Mon, 19 Sep 2016 11:54:26 -0700 (PDT) In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> From: Watson Ladd Date: Mon, 19 Sep 2016 11:54:26 -0700 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11425eec6151c1053ce0d75a Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 18:54:31 -0000 --001a11425eec6151c1053ce0d75a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 19, 2016 at 4:26 AM, Ted Lemon wrote: > The effort is certainly worth doing. I've encountered the same problem, > and also find it frustrating. It might be worth writing an informational > doc; the challenge would be socializing it to the people who need to read > it. The first problem is that there isn't an easy library to integrate that will handle this. If it's a five minute fix that's very different from a long development process. And no, adding better support to NSS doesn't count: NSS has no documentation, as well as missing some important security features. (NSS diffie-hellman ephemeral keys don't rotate for instance). If you want applications to use tokens you need to make doing so a solution, not a problem. Standards can help, but they have also massively hurt. > > On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse > wrote: >> >> (I hope the cross-post is acceptable; apologies if not.) >> >> Various applications will optionally make use of X.509 certificates for >> client authentication. >> >> Those certificates, and the associated private keys, may be found in >> files on the file system, in PKCS#11 tokens, or in another >> OS-specific form of certificate database. >> >> In my opinion, it would be nice to have some consistency between >> applications. If a user has a certificate in a certain form, it would >> be nice for that to Just Work=E2=84=A2 across all well-behaved applicati= ons. >> >> In practice, nothing could be further from the truth. >> >> Applications *all* suck, and various certificates will spuriously fail >> to work in one application but not another. Or work if the application >> is build against crypto library $A but not when built against crypto >> library $B. Or for objects in PKCS#11 each application might require a >> *different* identifier string to locate the same object. If they >> support PKCS#11 at all. >> >> I'd like to fix that. I would like to achieve a consensus that a "well- >> behaved application" SHOULD accept certificates and keys in various >> (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. >> >> I have slowly been working on this. I have encouraged the Fedora >> distribution of Linux to amend their packaging guidelines to state that >> software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it >> would accept a filename. And that software SHOULD load the PKCS#11 >> tokens which are indicated by the system configuration. >> >> We have already fixed various applications to comply with these >> requirements, and I even mentored a Google Summer of Code project which >> added RFC7512 support to NSS=C2=B2. >> >> I believe the Fedora packaging guidelines have been a success, and I >> would like to expand the scope. There's no *reason* this should be >> Fedora-specific, or even specific to Linux or POSIX operating systems. >> So I'm looking for a forum in which to reach a consensus on what should >> be accepted, and to publish those guidelines. I'd be very interested in >> hearing suggestions. >> >> >> Simultaneously, I'm also looking at expanding the technical scope. >> For my own project, the OpenConnect VPN client, I have started to >> collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various >> PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypt= ed with >> various algorithms. I have yet to embark of the joy of files with non- >> ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a= bottle >> of vodka ready to help me do so. >> >> My test suite also includes PKCS#11 tests including private keys where >> the token doesn't expose the public component (which made OpenSSL crash >> until yesterday, yay!) and certificates with the CKA_PRIVATE attribute >> set, so some software will fail to *find* them. >> >> I am thinking of splitting my torture test out from OpenConnect itself, >> and making it available as a project in its own right. >> >> I can, of course, lobby to expand the Fedora guidelines to state that >> all software packaged for Fedora SHOULD pass the torture test suite, >> but I think it makes sense to aim for a wider consensus than that. >> >> Opinions welcome... does it make sense to attempt to publish an >> informational RFC outlining such "expectations"? Or should it take some >> other form? Or should I just not bother, and continue to push it from >> the Fedora angle, since it's getting into a lot of upstream software >> already? >> >> I also expect some heckling at my specific test cases =E2=80=94 do we *r= eally* >> expect everyone to support DSA keys still? And PEM files encrypted the >> old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? >> >> (I can accept 'no' answers to the latter two only if expressed in a >> form which lets me file bugs against ancient "enterprise" software to >> stop *creating* them that way...) >> >> -- >> dwmw2 >> >> =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHandling >> =C2=B2 https://bugzil.la/1162897 >> =C2=B3 >> http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makef= ile.am >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. --001a11425eec6151c1053ce0d75a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Sep 19, 2016 at 4:26 AM, Ted Lemon <mellon@fugue.com> wrote:
> The effort is certainly worth doing. I've encountered the same pro= blem,
> and also find it frustrating. It might be worth writing an information= al
> doc; the challenge would be socializing it to the people who need to r= ead
> it.

The first problem is that there isn't an easy library to= integrate that will handle this. If it's a five minute fix that's = very different from a long development process. And no, adding better suppo= rt to NSS doesn't count: NSS has no documentation, as well as missing s= ome important security features. (NSS diffie-hellman ephemeral keys don'= ;t rotate for instance).

If you want applications to use tokens you need to make doin= g so a solution, not a problem. Standards can help, but they have also mass= ively hurt.

>
> On Mon, Sep 19, 2016 at 6:23 AM, David Woodhouse <dwmw2@infradead.org>
> wrote:
>>
>> (I hope the cross-post is acceptable; apologies if not.)
>>
>> Various applications will optionally make use of X.509 certificate= s for
>> client authentication.
>>
>> Those certificates, and the associated private keys, may be found = in
>> files on the file system, in PKCS#11 tokens, or in another
>> OS-specific form of certificate database.
>>
>> In my opinion, it would be nice to have some consistency between >> applications. If a user has a certificate in a certain form, it wo= uld
>> be nice for that to Just Work=E2=84=A2 across all well-behaved app= lications.
>>
>> In practice, nothing could be further from the truth.
>>
>> Applications *all* suck, and various certificates will spuriously = fail
>> to work in one application but not another. Or work if the applica= tion
>> is build against crypto library $A but not when built against cryp= to
>> library $B. Or for objects in PKCS#11 each application might requi= re a
>> *different* identifier string to locate the same object. If they >> support PKCS#11 at all.
>>
>> I'd like to fix that. I would like to achieve a consensus that= a "well-
>> behaved application" SHOULD accept certificates and keys in v= arious
>> (TBD) file formats and also accept PKCS#11 URIs according to RFC75= 12.
>>
>> I have slowly been working on this. I have encouraged the Fedora >> distribution of Linux to amend their packaging guidelines to state= that
>> software packaged for Fedora SHOULD accept a PKCS#11 URI wherever = it
>> would accept a filename. And that software SHOULD load the PKCS#11=
>> tokens which are indicated by the system configuration.
>>
>> We have already fixed various applications to comply with these >> requirements, and I even mentored a Google Summer of Code project = which
>> added RFC7512 support to NSS=C2=B2.
>>
>> I believe the Fedora packaging guidelines have been a success, and= I
>> would like to expand the scope. There's no *reason* this shoul= d be
>> Fedora-specific, or even specific to Linux or POSIX operating syst= ems.
>> So I'm looking for a forum in which to reach a consensus on wh= at should
>> be accepted, and to publish those guidelines. I'd be very inte= rested in
>> hearing suggestions.
>>
>>
>> Simultaneously, I'm also looking at expanding the technical sc= ope.
>> For my own project, the OpenConnect VPN client, I have started to<= br> >> collect a torture test suite=C2=B3 of RSA, DSA and EC keys in vari= ous
>> PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and e= ncrypted with
>> various algorithms. I have yet to embark of the joy of files with = non-
>> ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I = have a bottle
>> of vodka ready to help me do so.
>>
>> My test suite also includes PKCS#11 tests including private keys w= here
>> the token doesn't expose the public component (which made Open= SSL crash
>> until yesterday, yay!) and certificates with the CKA_PRIVATE attri= bute
>> set, so some software will fail to *find* them.
>>
>> I am thinking of splitting my torture test out from OpenConnect it= self,
>> and making it available as a project in its own right.
>>
>> I can, of course, lobby to expand the Fedora guidelines to state t= hat
>> all software packaged for Fedora SHOULD pass the torture test suit= e,
>> but I think it makes sense to aim for a wider consensus than that.=
>>
>> Opinions welcome... does it make sense to attempt to publish an >> informational RFC outlining such "expectations"? Or shou= ld it take some
>> other form? Or should I just not bother, and continue to push it f= rom
>> the Fedora angle, since it's getting into a lot of upstream so= ftware
>> already?
>>
>> I also expect some heckling at my specific test cases =E2=80=94 do= we *really*
>> expect everyone to support DSA keys still? And PEM files encrypted= the
>> old OpenSSL way? And PKCS#12 files encrypted with MD5-DES?
>>
>> (I can accept 'no' answers to the latter two only if expre= ssed in a
>> form which lets me file bugs against ancient "enterprise"= ; software to
>> stop *creating* them that way...)
>>
>> --
>> dwmw2
>>
>> =C2=B9 https://fedoraproject.org/wiki/Packaging:SSLCertificateHan= dling
>> =C2=B2 https://bugzil.la/116= 2897
>> =C2=B3
>> http://git.infradead.org/users/dwmw2/openconnec= t.git/blob/HEAD:/tests/Makefile.am
>>
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www= .ietf.org/mailman/listinfo/saag
>>
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.iet= f.org/mailman/listinfo/saag
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a11425eec6151c1053ce0d75a-- From nobody Mon Sep 19 12:28:12 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16DD12B0AF; Mon, 19 Sep 2016 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OwiAqxLJa1X; Mon, 19 Sep 2016 12:28:08 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B994812B04B; Mon, 19 Sep 2016 12:28:08 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bm4EZ-0006wF-Nd; Mon, 19 Sep 2016 19:28:08 +0000 Message-ID: <1474313284.144982.367.camel@infradead.org> From: David Woodhouse To: Phillip Hallam-Baker Date: Mon, 19 Sep 2016 20:28:04 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-l4imTMt6nNn2bR7NhCXb" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, "saag@ietf.org" Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 19:28:11 -0000 --=-l4imTMt6nNn2bR7NhCXb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-19 at 12:35 -0400, Phillip Hallam-Baker wrote: > This is a very common problem and one that I encounter on an hourly > basis as I write code for the Mesh. There are three separate formats > used for public keys in SSH and four for private. >=20 > This is all stuff that has dropped off the table as far as the > standards groups are concerned because 'it isn't protocol that goes > on the wire'. Except of course it does. >=20 > The way I think we have to approach a solution=C2=A0is to use a container > of some type whether that is MIME or JSON that has a slot for > metadata describing the content type to follow: Hm... the problem is that there exists a plethora of different file formats, and applications are massively inconsistent about which ones they support. Your proposed solution is to add a new file format to the mix? That is... not entirely what I had in mind. :) I suppose it *would* improve consistency, in an unhelpful kind of a way... it would give a new format that all existing applications would *consistently* fail to support, --=20 dwmw2 --=-l4imTMt6nNn2bR7NhCXb Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTE5MTkyODA0WjAvBgkqhkiG9w0BCQQxIgQgj1CutSB8UpwB+wSg3ZKii7ENCZM+9mKdnumz M4CKzZ8wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAD3P tfQ80lsAHlIY3Xvl5Poj9ESosINiU4e8juXrIl0kZxT1ks869aI2IIhvaWRLzP5cewgFU5ctHNkF Y3mhRJE9LiS6KUNqLobNCOlLH17zp6KoPDmEq7jqVM2lOSf4e3xu0+pi0cjf/StTyEWNfWwJW7XX Zm78jq1Stz93m65rDHXNOM5jSqx6WH2o0W82fQ/7Ny09sZdNhbhNMEb8qifgBGPD1AP4AmHvgysy BP+STsWWEvw+n0lufLGF87LfqzAkDTC+vxyhiKlAZZjMHs6AvX/tAMAMY7P/aPYSLNS7Nn3EfdNc BBY02a8uAsjyXv9oSVrM85aKoqSKcUoWAoa/U20eEf2waHEN7JwXn8K+8ivjqTAp1xYwarqugHiz nPhYLBmx5vnqLYrmfr5nE+7LSRMx+GEFWPVwfNQhg16jW1RBChejyEE3zvgdKGPsy6fxeCXzrPrH uzLC2nYsw2XXPt+V1U/Jh11KLzTmZ1mkBJ2AhgY795avGL6BIOwuQYT0+vf34HA4cWCyaXbn7agf yn58ZXFAzNfOiNCO4B18e6swVUx8/sBp5CVwAi5hWU7wB9X8WxpBapjPfhvhkj59xPIlXUaO6gJz qQMvSW8S4YxiCT3K2V1la2//Uj+VYSdSiX+gEbeXATQhG0q7OAazGBTItxx4cOBOr1Nj1jOpAAAA AAAA --=-l4imTMt6nNn2bR7NhCXb-- From nobody Mon Sep 19 12:56:47 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB78E12B532; Mon, 19 Sep 2016 12:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tpLuDI99Wel; Mon, 19 Sep 2016 12:56:40 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5109412B531; Mon, 19 Sep 2016 12:56:40 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bm4gA-0002Gh-Uj; Mon, 19 Sep 2016 19:56:39 +0000 Message-ID: <1474314996.144982.391.camel@infradead.org> From: David Woodhouse To: Watson Ladd , Ted Lemon Date: Mon, 19 Sep 2016 20:56:36 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-uhxd37pAYUpMOTWuI+ap" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 19:56:46 -0000 --=-uhxd37pAYUpMOTWuI+ap Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-19 at 11:54 -0700, Watson Ladd wrote: > On Mon, Sep 19, 2016 at 4:26 AM, Ted Lemon wrote: > > The effort is certainly worth doing. I've encountered the same problem, > > and also find it frustrating. It might be worth writing an informationa= l > > doc; the challenge would be socializing it to the people who need to re= ad > > it. > > The first problem is that there isn't an easy library to integrate > that will handle this. If it's a five minute fix that's very > different from a long development process. I'll restate that differently: the problem is that *all* the crypto libraries go out of their way to make it *hard* for applications to do this correctly. I have *pondered* splitting out my file-handling code from OpenConnect into a BSD-licensed library. That does handle the task of working out what type of file it's dealing with, and tickling the crypto library (well, OpenSSL or GnuTLS) in precisely the right way to load it. On the whole though, I'd rather just fix the libraries so that the application doesn't *need* to do that kind of nonsense. > And no, adding better support to NSS doesn't count: NSS has no > documentation, as well as missing some important security features. > (NSS diffie-hellman ephemeral keys don't rotate for instance). Sure, there are *lots* of things to be fixed. Fixing NSS to use PKCS#11 URIs addresses only part of the problem. Using *files* from NSS is also a complete pain in the posterior. There exists nss-pem but it's baroque and supports only a tiny set of file formats. > If you want applications to use tokens you need to make doing so a > solution, not a problem. Standards can help, but they have also > massively hurt. When you say 'tokens' you're talking about PKCS#11? That part is actually relatively easy, at least for the crypto libraries I've been looking at. NSS is mostly resolved; there's the question of loading the system-configured PKCS#11 providers but we have a way forward and patches filed for that too:=C2=A0https://bugzil.la/1296263 GnuTLS has worked for as long as I can remember =E2=80=94 you just pass it = a PKCS#11 URI in place of a filename and it Just Works=E2=84=A2. And I've fix= ed up its file support in places too, for example by adding support for the OpenSSL encrypted PEM files. For OpenSSL there is engine_pkcs11, which I've recently fixed so it is loaded simply with ENGINE_by_id("pkcs11") and takes PKCS#11 URIs to load keys and certs. Longer-term, there are moves afoot to integrate PKCS#11 support directly into OpenSSL. Other crypto libraries exist, of course, but not so much on platforms where PKCS#11 is prevalent. But that's just me tilting at windmills on my own. The point of reaching out in this forum is to try to reach a consensus on what we should expect from applications, and maybe even get others to help :) --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-uhxd37pAYUpMOTWuI+ap Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTE5MTk1NjM2WjAvBgkqhkiG9w0BCQQxIgQgs4v+NGkYRRrm7gw+LbOXKgohcp03eUqSyDd0 rd96W1wwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICALo5 UyAh9m83Ub35t4kMpQdWtBTZFrsIxEO10BjlNER47SzKJUdGB9/mQI/C3WwIEN5lgz4mQ60C2L02 D7dIDJApI1na79vvJFxEmPnyGBAnqNe5SomVfVQqx/uWlJDqYtZM+bsKNKCjekc/N6Lzy2uvfXhk phYM+3ksKSF5HZsIZD4fOMbKifYWhqtQhM6hz9XE/KShbXnrRKminL6wK16Ad0seOESVqDCZqu/F R7M4ks82OgkjRYIU7z/FiMbUxD04r8/KU+DY8ZfNmxw8e0TM9DX1lrsqrDfxrSYUa0WkKhDE1eqr i0whexLY6/FaqUplJm+W+va5o/3f4k5aQBgmyDRqIorFpxLft0ii2CdLCTsWEg2yYlU2ix/D/zKb +9BO5DbeafjEGclBHupRr3YYlpr4rxi6bAbtIrID+BIM5i5buAqDvLob7rOwvi74L3HLRI3I81ze 5qqVqEEW2EdMXe+/Pw5sDXBgKGlwUVV4FTd5DRPYmxZdwEbQEG1p1N0JbtgshNp0mi09YsXuAXNn 2XCeBqeoboJ5Gt4qUeTp7CNtqIdn2n0J8TnuUQmduv4V2oB/EWsITJTzmzKriycm/iA3mtF9gXX4 tJLHyMJngGhQwEz67Cat3XMlqbPIGcENedyfC+QkrPsXcViO83VuEGOZSjeKdtW13O4q1XboAAAA AAAA --=-uhxd37pAYUpMOTWuI+ap-- From nobody Tue Sep 20 08:10:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2528212B6DB; Tue, 20 Sep 2016 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjLCdw9YMDAR; Tue, 20 Sep 2016 08:10:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3843D12B3CE; Tue, 20 Sep 2016 07:49:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 373402009E; Tue, 20 Sep 2016 11:02:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 30B726392C; Tue, 20 Sep 2016 10:49:31 -0400 (EDT) From: Michael Richardson To: David Woodhouse In-Reply-To: <1474314996.144982.391.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 15:10:52 -0000 --=-=-= Content-Type: text/plain David Woodhouse wrote: >> And no, adding better support to NSS doesn't count: NSS has no >> documentation, as well as missing some important security features. >> (NSS diffie-hellman ephemeral keys don't rotate for instance). > Sure, there are *lots* of things to be fixed. > Fixing NSS to use PKCS#11 URIs addresses only part of the problem. > Using *files* from NSS is also a complete pain in the posterior. There > exists nss-pem but it's baroque and supports only a tiny set of file > formats. NSS seems hostile to having private keys loaded. It expects to manage all of that, and for partly good reasons: the private key may be in a module or something. But the result is that you basically can't write regression tests for NSS. At least that's my experience. > But that's just me tilting at windmills on my own. The point of > reaching out in this forum is to try to reach a consensus on what we > should expect from applications, and maybe even get others to help :) I expect applications to: a) be runable without a system resource. so: b) they can be tested without an install. so: c) I can run the executable from the source directory. It's great if applications, once installed, can be told about system wide keys and the like, and we can arrange to share things appropriately, but too often the system-wide stuff has gotten in the way of actually making things work. Frankly, it's why SSH took off in the 1990s, while ssltelnet and ktelnet failed: minimal to no infrastructure. Building scalable systems doesn't mean building them for 1,000,000 people, it means building them for a range, ideally down to 1. I think that the major problem with X.509 client certificates is that many applications and protocols don't know if 509 is being used as a container for a self-signed certificate, for poorly(privately) signed certificate, a corporate CA, or a webCA. That's where PHB's suggestion of a new meta-format would win. (It means that we could eventually not have the keys in X.509 format.) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV+FMd4CLcPvd0N1lAQKP0wf9FiyBzL1h1njdHio791Ng1pgQW6EM3Ckb QXrS01L8LBdYBRUnstsFFJeFAwmec0oG1cgW1GNV4jd+V4NL/+tqV02O73MTTjIb tx3zasQJHJBRBJmtpjIIDbPLlPpS84N8sp+CpaWJEZjA+PTYT1S8BkpCswgoyf/f YYD+rR071H1HX4EuxdXQG+3fJ3vhgxbHOX5FcW9H1jk3J+hKtEqXFYhQ1MWehC0D kQGnTO12JV6sRddPqmjNLG2z9L0gAxv8Y30otuQv/B4319O4RPVDfKFk7nkUTghk FmtjlUsY+v3aueWRp1Z3Wig1rTbwCJOSgq1BNHpxt1bHpshR6IxyMg== =4kWt -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 20 08:43:23 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F3512B348; Tue, 20 Sep 2016 08:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQylzhE45eLx; Tue, 20 Sep 2016 08:43:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 310C212B6DB; Tue, 20 Sep 2016 08:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 730CA1EF7; Tue, 20 Sep 2016 15:43:03 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJWr1W-QVSLK; Tue, 20 Sep 2016 15:43:03 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id CF2061B5B; Tue, 20 Sep 2016 15:43:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <22611.1474382971@obiwan.sandelman.ca> Date: Tue, 20 Sep 2016 11:43:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 15:43:19 -0000 On Sep 20, 2016, at 10:49 AM, Michael Richardson = wrote: > I think that the major problem with X.509 client certificates is that = many > applications and protocols don't know if 509 is being used as a = container for > a self-signed certificate, for poorly(privately) signed certificate, a > corporate CA, or a webCA. >=20 > That's where PHB's suggestion of a new meta-format would win. > (It means that we could eventually not have the keys in X.509 format.) This proposal may be applicable: https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 Alan DeKok. From BATV+228e0feef8add010b485+4776+infradead.org+dwmw2@bombadil.srs.infradead.org Tue Sep 20 08:57:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC612B2A4; Tue, 20 Sep 2016 08:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vXWFSzrt76q; Tue, 20 Sep 2016 08:57:52 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA9112B108; Tue, 20 Sep 2016 08:57:52 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmNQb-0007XA-5b; Tue, 20 Sep 2016 15:57:49 +0000 Message-ID: <1474387066.144982.443.camel@infradead.org> From: David Woodhouse To: Michael Richardson Date: Tue, 20 Sep 2016 16:57:46 +0100 In-Reply-To: <22611.1474382971@obiwan.sandelman.ca> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-RbuX5Hubs30PKsN5anTK" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 16:06:57 -0000 --=-RbuX5Hubs30PKsN5anTK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 10:49 -0400, Michael Richardson wrote: > I expect applications to: > a) be runable without a system resource. > so: > b) they can be tested without an install. > so: > c) I can run the executable from the source directory. Yes, all of these are good practice. They are orthogonal to what I'm trying to achieve, but certainly I wouldn't do anything to *discourage* the above. > It's great if applications, once installed, can be told about system wide > keys and the like, and we can arrange to share things appropriately, but = too > often the system-wide stuff has gotten in the way of actually making thin= gs > work. Frankly, it's why SSH took off in the 1990s, while ssltelnet and > ktelnet failed: minimal to no infrastructure. I think that's orthogonal to my purpose here too. You're talking about the infrastructure on the server side, used to determine which client keys to trust. What I'm talking about here is *clients* finding the keys to use. For X.509 certificates and keys, applications need to be able to support various file formats *and* should support using objects from a system-specific central store *if* such exists on the platform. Starting with just the files... take a look at the test cases in http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makef= ile.am There are various PKCS#1, PKCS#8, PKCS#12 files in various PEM and DER permutations with a selection of weak and strong encryption types (and lack of encryption). I know of NOT A SINGLE APPLICATION which will Just Work=E2=84=A2 for every = one of those test cases. And looking beyond files: if I go and purchase a hardware crypto device lik= e a Yubikey, and plug it into my system. I install the OpenSC package which= has a PKCS#11 provider module for it, and provision a key in it.... now, h= ow do I use it? The answer should be simple. I determine a RFC7512 identifier for the key I= want to use (e.g. 'pkcs11:manufacturer=3Dpiv_II;id=3D%01') and then every = application in the system SHOULD just accept that identifier in place of a = filename. That is the scope of what I'm trying to do here =E2=80=94 nothing more. Jus= t making client applications consistent in what forms of key they accept, a= nd how the user identifies them. Note that I don't need to *install* my client application for the system ce= rtificate support to work. I can run it from its build directory and using = "-c 'pkcs11:manufacturer=3Dpiv_II;id=3D%01'" should still work. My test cas= es jump through hoops to use a SoftHSM token for testing, with its storage = database actually kept in the git repository. But that's just for testing. --=C2=A0 dwmw2 --=-RbuX5Hubs30PKsN5anTK Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIwMTU1NzQ2WjAvBgkqhkiG9w0BCQQxIgQgt1EhhCjsh4O8B5KvWH5gwcS5OSy7UOreeFHp GfrDgtUwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAAC6 GFoNBPi4QL5R4hlCmyjIe/ed2UpDML26SIQeH+bjqZZIz021v8szfpzUOzsZm8w41LkBBzQfU4p2 05S3OVrTJ46IVkKe74Kc/Nd3yommbKtI7Nl24GAmMs2IUIkY7FTL+QYMnffaptw08CRSIY7uTrIU o2/9clzrv/BjQ3A4XmdOwNb7cZV7YmOFIEUPHFTSTktUH/V4rrHbhdFYDJ+89ZFcQFBSYdrdsqP0 BGOO65SYYNbCfFCbzncoDo1dQGTg7QUgrM70Ma1RoRmo1e+ZlHg9uWite+dCFLBws3VcrNKzVdsH +MJFOpfwXhktb1MS0OBDlTEM0g6X+kclvs0MnZFXaij8uply/fQaSSuTIsFj+RKCn10Ka20ZkN8M LLj5itZBwKtFfxuJGbglJAmkC49gQQHX/L4NnFSDzE72Eomkr1tZBfJlUy0SGD3YrK+L1CC1GRSG /oMFVpBxG2q5k3Q+ktwFBolqgaA+flnwVlVGx4yCA1uG45FVcD0xruXbehWoouQJvys4nOioC4DV sj4g2wo0WYk6klM3UsbCmqSw0kGE8Utq/8fz1/XPUZ2tzlPVXsWOoyj7zQ5We7w3nHNqN+tOb74y YVHYffrJRuNWprEmAObtwf2eQqoIGeLyJ6EfoF8EZ5hbfen4EQHTwmaLypB3OEormSx8iulkAAAA AAAA --=-RbuX5Hubs30PKsN5anTK-- From BATV+228e0feef8add010b485+4776+infradead.org+dwmw2@bombadil.srs.infradead.org Tue Sep 20 09:06:48 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E485D12B3BC; Tue, 20 Sep 2016 09:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8x09RWKB-1E; Tue, 20 Sep 2016 09:06:44 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E4C12B377; Tue, 20 Sep 2016 09:06:44 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmNZA-00043E-RF; Tue, 20 Sep 2016 16:06:41 +0000 Message-ID: <1474387598.144982.452.camel@infradead.org> From: David Woodhouse To: Alan DeKok , Michael Richardson Date: Tue, 20 Sep 2016 17:06:38 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-YwJ/lnlnSFahAHrz2F0m" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 16:07:58 -0000 --=-YwJ/lnlnSFahAHrz2F0m Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 11:43 -0400, Alan DeKok wrote: > On Sep 20, 2016, at 10:49 AM, Michael Richardson = wrote: > >=20 > > I think that the major problem with X.509 client certificates is that m= any > > applications and protocols don't know if 509 is being used as a contain= er for > > a self-signed certificate, for poorly(privately) signed certificate, a > > corporate CA, or a webCA. > >=20 > > That's where PHB's suggestion of a new meta-format would win. > > (It means that we could eventually not have the keys in X.509 format.) >=20 > This proposal may be applicable: >=20 > https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 That looks like a layer above what I'm talking about. My goal is that we should be able to refer to certificates in a simple consistent way. If the certificate is in a system store then applications should allow it to be used by means of a consistent identifier string (which is defined by RFC7512 for PKCS#11, and may be different for OSX/Windows system certificate stores). If the certificate is in a file, obviously the identifier is the filename... but we need to fix applications so that they actually *accept* all types of files. Which as I said, none of them do at the moment. Looking at the proposal above, I see there is some attempt to handle certificate encodings =E2=80=94 it the CertEncodingEnum has values of PEM, = DER, and P12. This looks a lot like the problematic applications we need to fix... for PKCS#1 and PKCS#8 you have to manually specify whether it's PEM or DER file even though the software could work that out for itself. And for PKCS#12 you *don't* have to specify; it's going to assume DER. All very suboptimal. My assertion is that applications shouldn't *need* that nonsense, and should just take the filename and deal with the contents. Please don't entrench that horridness further. It also seems that the proposal you reference doesn't have any kind of support for using keys from hardware. If the key I want to use is identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this format? --=20 dwmw2 --=-YwJ/lnlnSFahAHrz2F0m Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIwMTYwNjM4WjAvBgkqhkiG9w0BCQQxIgQg2slSW4SZHYgpGahGEdoveEdVMimaHN9eziV7 q1XFG74wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAID9 4QpxFM6aiVEq5bkC/Ifp5K3VrlepyyijbxTiHJ/xdOAeWHpUbASklC9xV6vxIqg+/upxlf9DNX+d A86ySGVIR5J2Z3dtm4AGYCy8kehuKpLw0dZI242LAR8+9gBgU7IYS2NUVR14kBcWKKRGhP03DRMa Esaz/sTSsqTjAawXxz8YUYGVCWR6VLu3ENmcbGlB++0YcCV7Zij2izJ7UBNiEi68SiInjbr80Evg sPoCAG4+U1WHTxS55bIGDzcDqPAdHXjVGE0Unu2NktWNLpHrfPDJJ9GucRePkNp2ul1bos9CXsCs QKTyNMr4H7QQqEPAigI0H62NxUzzjReh19FiCp2Jriq7XXcG5NoxocHH4g/HiBQdNfeFhcC92uO8 ZekZnglUua9a5uWG4N8a/dOHYKDj2iwOPVN5A4A218GLzhCmhO3v+zjP1+nOwu5KorpeaMCqn0Vw yib+6IO54POP11/CuquyML+HZfUSPpuTqPCklomTx4mCgohS+kJLf5UDPUnXOLLKV1YI3xACvtoR ouSvyUIBGC/sJaYzGJsa21aY/A9GzCCZaMbQQmy6Jmdx5BnR0cK2DM//TXYO3VnYnWNXA3WG8V9I 2/CI9QTuCTy9IDCXcOhlQ/yQtTpdeDETLl9MkGJX8yM6tEgq7LNfI3eskpMHgSGhtG9XYVkVAAAA AAAA --=-YwJ/lnlnSFahAHrz2F0m-- From nobody Tue Sep 20 09:36:05 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB5512B3A2; Tue, 20 Sep 2016 09:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUdPoaYH_Ope; Tue, 20 Sep 2016 09:36:01 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1D03012B0E9; Tue, 20 Sep 2016 09:36:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 70D341EF7; Tue, 20 Sep 2016 16:36:00 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOjVjW8pOs3z; Tue, 20 Sep 2016 16:36:00 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id BADC31704; Tue, 20 Sep 2016 16:35:59 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1474387598.144982.452.camel@infradead.org> Date: Tue, 20 Sep 2016 12:36:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> To: David Woodhouse X-Mailer: Apple Mail (2.3124) Archived-At: Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Winter Stefan Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 16:36:03 -0000 On Sep 20, 2016, at 12:06 PM, David Woodhouse = wrote: >> https://tools.ietf.org/html/draft-winter-opsec-netconfig-metadata-00 >=20 > That looks like a layer above what I'm talking about. My goal is that > we should be able to refer to certificates in a simple consistent way. >=20 > If the certificate is in a system store then applications should allow > it to be used by means of a consistent identifier string (which is > defined by RFC7512 for PKCS#11, and may be different for OSX/Windows > system certificate stores). I think that the two solutions complement each other. > Looking at the proposal above, I see there is some attempt to handle > certificate encodings =E2=80=94 it the CertEncodingEnum has values of = PEM, DER, > and P12. >=20 > This looks a lot like the problematic applications we need to fix... > for PKCS#1 and PKCS#8 you have to manually specify whether it's PEM or > DER file even though the software could work that out for itself. And > for PKCS#12 you *don't* have to specify; it's going to assume DER. All > very suboptimal. I agree. > My assertion is that applications shouldn't *need* that nonsense, and > should just take the filename and deal with the contents. Please don't > entrench that horridness further. I understand, but... that's easier than scanning the file to see if = it's one of N possible unknown formats. And likely more secure. > It also seems that the proposal you reference doesn't have any kind of > support for using keys from hardware. If the key I want to use is > identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this > format? The proposal would need updating to handle that. Alan DeKok. From nobody Tue Sep 20 10:08:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC59812B413; Tue, 20 Sep 2016 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRcpXRitZv1R; Tue, 20 Sep 2016 10:08:49 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EDC12B407; Tue, 20 Sep 2016 10:08:47 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmOXF-0005zD-No; Tue, 20 Sep 2016 17:08:46 +0000 Message-ID: <1474391322.144982.459.camel@infradead.org> From: David Woodhouse To: Alan DeKok Date: Tue, 20 Sep 2016 18:08:42 +0100 In-Reply-To: <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <11F16CFE-3554-4F07-811A-8F5D4BE3A6AE@deployingradius.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ASIsEMorymqZWp83s9cR" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Winter Stefan Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Sep 2016 17:08:51 -0000 --=-ASIsEMorymqZWp83s9cR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-09-20 at 12:36 -0400, Alan DeKok wrote: >=20 > > My assertion is that applications shouldn't *need* that nonsense, and > > should just take the filename and deal with the contents. Please don't > > entrench that horridness further. >=20 > =C2=A0 I understand, but... that's=C2=A0easier than scanning the file to = see if > it's one of N possible unknown formats.=C2=A0 And likely more secure. Easier for whom? Not for the user, certainly. Users should be able to ask applications just to use a certificate/key from a given file, without worrying about the minutiae of what's inside it. Besides, it's not like it's hard to tell the difference between PEM and DER files. And if you're already accepting "DER" as a filetype, that covers all manner of stuff including PKCS#8, PKCS#1 and the various unencrypted forms of DSA and EC keys. It's not like recognising PKCS#12 in that code path is particularly difficult *either*, if you were doing it properly. Which, as I noted, no application does. > > It also seems that the proposal you reference doesn't have any kind of > > support for using keys from hardware. If the key I want to use is > > identified by an RFC7512 PKCS#11 URI, how do I indicate *that* in this > > format? >=20 > =C2=A0 The proposal would need updating to handle that. Yes. Yes, it does :) --=20 dwmw2 --=-ASIsEMorymqZWp83s9cR Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIwMTcwODQyWjAvBgkqhkiG9w0BCQQxIgQg2anFHKINopEydtqh1K2d4OJXURP64i08sy90 bQu+xtwwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAJZv kfxvjSeMC9U2HysoMQ6CeH+uNf7mlr8n22zoAd5HkGH7CoI4B2Xf86xERUeartKPZ/so6jPYpVdv DsjDQVqaNphcUaw0dDJQunvSxiwCJy963YfGDYqKm2u/9p0etM/I4O7D1J8GpC0uLHo54CMjNI4N iyGEXTODdbLP10+xtK08srpxfa/aa7ZwPKSX0lcCW8xgXWyXFC9L9PcVhLQd153v5As+CQt2gZF4 y5gSPoIOjvAeVrbSEK5cfltLGC+wwgLA6OSCv+p8HNGQzWnEZui7m2Hu+VBimq2QWIlXd/tIX8/A S+CMnBosPffGp3ADHZ0fT2cTXxH3q2Yzr4w46AwmhC9uV6qSEti0548ZYjuT7GdYP1RdT5hoCwHI 41tFR1xOKWwUfevK8S5spQ23atq5EjvD358SfItudEIYBom1KNrbaEkR19ZEBQatPpdZKJ7oaIRT 7a4vCE1pxwdASbYsawcULSjb8KW70LE0KdYkwTirMyRG4P7lboa4elhH4bccoqjjL2OejAxy7cxp Zz04sMMqWBJnVYUZ7ryIYUB4AFiimnS7gjwdJHTPzt7bmAcZTk8BlvL/qT7s4sPYMwbwShPOouQq KgZR/fKxWO3EecgoCe2e/GIA0GNmbMoCoMfwCpBwHUKBA2p1iEHz7vmK72dp/y2o3oiFlK42AAAA AAAA --=-ASIsEMorymqZWp83s9cR-- From nobody Tue Sep 20 17:29:55 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533012B4EE; Tue, 20 Sep 2016 17:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG8vFCB6PI8R; Tue, 20 Sep 2016 17:29:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9B312B10D; Tue, 20 Sep 2016 17:29:53 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 46E36E1D3; Tue, 20 Sep 2016 20:42:53 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D5E036392C; Tue, 20 Sep 2016 20:29:51 -0400 (EDT) From: Michael Richardson To: David Woodhouse In-Reply-To: <1474387066.144982.443.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: spasm@ietf.org, Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 00:29:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable David Woodhouse wrote: > And looking beyond files: if I go and purchase a hardware crypto devi= ce > like a Yubikey, and plug it into my system. I install the OpenSC > package which has a PKCS#11 provider module for it, and provision a k= ey > in it.... now, how do I use it? > The answer should be simple. I determine a RFC7512 identifier for the > key I want to use (e.g. 'pkcs11:manufacturer=3Dpiv_II;id=3D%01') and = then > every application in the system SHOULD just accept that identifier in > place of a filename. yes, that would be great. Maybe we need to register the pkcs11: URI, such that we can then say it's a URI, and file:// would also naturally work. > That is the scope of what I'm trying to do here =E2=80=94 nothing mor= e. Just > making client applications consistent in what forms of key they accep= t, > and how the user identifies them. +10. > Note that I don't need to *install* my client application for the > system certificate support to work. I can run it from its build > directory and using "-c 'pkcs11:manufacturer=3Dpiv_II;id=3D%01'" shou= ld > still work. My test cases jump through hoops to use a SoftHSM token f= or > testing, with its storage database actually kept in the git > repository. But that's just for testing. +100. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBV+HUfYCLcPvd0N1lAQKcFwf7BdjeURrpTjzUjzJu7WMfUT4nBBaeLitr Roa2DuXQ+tgd1WjRPv8rioSTNuKTOMHdUxSSl7BiNA+sKhhdxQM/9nZBrfeD1qte ghAYMMgUFWsHp4Z4+EW9OKnVBCdTAsvc/HNEdQDD5j2NA8hTMPn2gx42+TPiXW26 Y/hUrOzGw2fjxaTNZ1V2xhbwx+sHICjYZPLcntIVDXuL9+5tH1eA8RYMHNXktbs4 2AIADfHS8O3fPlm8S6OLz1ZRgwsQ2IEZAK/TI70ey1WLyixfThcE5kf4/zG4ltvL rRm4HR+3/zfQT+eiiDrHtVL3hfSg6aWhK3w/k3A2QnbHuVB95IA2Sg== =A5V0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 20 23:28:07 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47312B0A8 for ; Tue, 20 Sep 2016 23:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.837 X-Spam-Level: X-Spam-Status: No, score=-16.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAuEaPJqMiqs for ; Tue, 20 Sep 2016 23:28:02 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6440B12B183 for ; Tue, 20 Sep 2016 23:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11740; q=dns/txt; s=iport; t=1474439281; x=1475648881; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=fYg/wPIozlvD+PCZK8TApSCT3w7Cp2L5GUQrCw38dxg=; b=j3JorIyh1ADc2CWyF2b+AeM0WR4EA3ilWvOZk6vvu0320f93u6f77Vwk SkI3dQMWTiQI7e56QsNHu0WPXEbkSZb8rptLZ01mXB33Q7r7DTxDJltzZ fbglaJOz0WibFa3VKy8clsEEi9IqhtBBXfxhmlf7I1HwiBGcK8zoOPs0q 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AhAgDOJ+JX/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAXUqUo0zpjaFD4IEGQEKgkSDNgKCEhQBAgEBAQEBAQF?= =?us-ascii?q?eJ4RiAQEEAQEBIEsbCw4KKgICJzAGAQwGAgEBiEcOrXqMXgEBAQEBAQEDAQEBA?= =?us-ascii?q?QEBAQEBAQEOCQWIM4JYh0iCWgWZdINBgXaKKolmhgaQYh42JYJ0BBaBUjw0hm0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.30,372,1470700800"; d="asc'?scan'208,217";a="645846237" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2016 06:27:56 +0000 Received: from [10.61.227.111] ([10.61.227.111]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u8L6RuKZ013718; Wed, 21 Sep 2016 06:27:56 GMT To: David Woodhouse , saag@ietf.org References: <1474280601.144982.263.camel@infradead.org> From: Eliot Lear Message-ID: <0ca146f9-f916-b066-55ca-852f957e013f@cisco.com> Date: Wed, 21 Sep 2016 08:27:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474280601.144982.263.camel@infradead.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f5NFlp5cIWM53gVvQNkXMNtsBwxQXgN2b" Archived-At: Subject: Re: [saag] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 06:28:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f5NFlp5cIWM53gVvQNkXMNtsBwxQXgN2b Content-Type: multipart/mixed; boundary="lVaq4OIvAP61qIMr7bxisA4v3NwACbv4s"; protected-headers="v1" From: Eliot Lear To: David Woodhouse , saag@ietf.org Message-ID: <0ca146f9-f916-b066-55ca-852f957e013f@cisco.com> Subject: Re: [saag] Best practices for applications using X.509 client certificates References: <1474280601.144982.263.camel@infradead.org> In-Reply-To: <1474280601.144982.263.camel@infradead.org> --lVaq4OIvAP61qIMr7bxisA4v3NwACbv4s Content-Type: multipart/alternative; boundary="------------9D82E248729F0A448150051A" This is a multi-part message in MIME format. --------------9D82E248729F0A448150051A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, Related, but not the same concern: I wonder if we could go further on guidance for signing and verifying of data at rest. There are two clear issues that one could write a lot about: * canonicalization; when/how/best practices * best practices for establishing trust of the anchors. I know this isn't what you were going to hit, but maybe it interests you and others anyway. Eliot On 9/19/16 12:23 PM, David Woodhouse wrote: > (I hope the cross-post is acceptable; apologies if not.) > > Various applications will optionally make use of X.509 certificates for= > client authentication. > > Those certificates, and the associated private keys, may be found in > files on the file system, in PKCS#11 tokens, or in another > OS-specific form of certificate database. > > In my opinion, it would be nice to have some consistency between > applications. If a user has a certificate in a certain form, it would > be nice for that to Just Work=E2=84=A2 across all well-behaved applicat= ions. > > In practice, nothing could be further from the truth. > > Applications *all* suck, and various certificates will spuriously fail > to work in one application but not another. Or work if the application > is build against crypto library $A but not when built against crypto > library $B. Or for objects in PKCS#11 each application might require a > *different* identifier string to locate the same object. If they > support PKCS#11 at all. > > I'd like to fix that. I would like to achieve a consensus that a "well-= > behaved application" SHOULD accept certificates and keys in various > (TBD) file formats and also accept PKCS#11 URIs according to RFC7512. > > I have slowly been working on this. I have encouraged the Fedora > distribution of Linux to amend their packaging guidelines to state that= > software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it > would accept a filename. And that software SHOULD load the PKCS#11 > tokens which are indicated by the system configuration. > > We have already fixed various applications to comply with these > requirements, and I even mentored a Google Summer of Code project which= > added RFC7512 support to NSS=C2=B2. > > I believe the Fedora packaging guidelines have been a success, and I > would like to expand the scope. There's no *reason* this should be > Fedora-specific, or even specific to Linux or POSIX operating systems. > So I'm looking for a forum in which to reach a consensus on what should= > be accepted, and to publish those guidelines. I'd be very interested in= > hearing suggestions. > > > Simultaneously, I'm also looking at expanding the technical scope. > For my own project, the OpenConnect VPN client, I have started to > collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various > PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encryp= ted with > various algorithms. I have yet to embark of the joy of files with non- > ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have = a bottle > of vodka ready to help me do so. > > My test suite also includes PKCS#11 tests including private keys where > the token doesn't expose the public component (which made OpenSSL crash= > until yesterday, yay!) and certificates with the CKA_PRIVATE attribute > set, so some software will fail to *find* them. > > I am thinking of splitting my torture test out from OpenConnect itself,= > and making it available as a project in its own right. > > I can, of course, lobby to expand the Fedora guidelines to state that > all software packaged for Fedora SHOULD pass the torture test suite, > but I think it makes sense to aim for a wider consensus than that. > > Opinions welcome... does it make sense to attempt to publish an > informational RFC outlining such "expectations"? Or should it take some= > other form? Or should I just not bother, and continue to push it from > the Fedora angle, since it's getting into a lot of upstream software > already? > > I also expect some heckling at my specific test cases =E2=80=94 do we *= really* > expect everyone to support DSA keys still? And PEM files encrypted the > old OpenSSL way? And PKCS#12 files encrypted with MD5-DES? > > (I can accept 'no' answers to the latter two only if expressed in a > form which lets me file bugs against ancient "enterprise" software to > stop *creating* them that way...) > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------9D82E248729F0A448150051A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi David,

Related, but not the same concern: I wonder if we could go further on guidance for signing and verifying of data at rest.=C2=A0= There are two clear issues that one could write a lot about:

  • canonicalization; when/how/best practices
  • best practices for establishing trust of the anchors.

I know this isn't what you were going to hit, but maybe it interests you and others anyway.

Eliot


On 9/19/16 12:23 PM, David Woodhouse wrote:
(I hope the cross-post is acceptable; apologies if n=
ot.)

Various applications will optionally make use of X.509 certificates for
client authentication.

Those certificates, and the associated private keys, may be found in
files on the file system, in PKCS#11 tokens, or in another
OS-specific form of certificate database.

In my opinion, it would be nice to have some consistency between
applications. If a user has a certificate in a certain form, it would
be nice for that to Just Work=E2=84=A2 across all well-behaved applicatio=
ns.

In practice, nothing could be further from the truth.

Applications *all* suck, and various certificates will spuriously fail
to work in one application but not another. Or work if the application
is build against crypto library $A but not when built against crypto
library $B. Or for objects in PKCS#11 each application might require a
*different* identifier string to locate the same object. If they
support PKCS#11 at all.

I'd like to fix that. I would like to achieve a consensus that a "well-
behaved application" SHOULD accept certificates and keys in various
(TBD) file formats and also accept PKCS#11 URIs according to RFC7512.

I have slowly been working on this. I have encouraged the Fedora
distribution of Linux to amend their packaging guidelines to state that
software packaged for Fedora SHOULD accept a PKCS#11 URI wherever it
would accept a filename. And that software SHOULD load the PKCS#11
tokens which are indicated by the system configuration.

We have already fixed various applications to comply with these
requirements, and I even mentored a Google Summer of Code project which
added RFC7512 support to NSS=C2=B2.

I believe the Fedora packaging guidelines have been a success, and I
would like to expand the scope. There's no *reason* this should be
Fedora-specific, or even specific to Linux or POSIX operating systems.
So I'm looking for a forum in which to reach a consensus on what should
be accepted, and to publish those guidelines. I'd be very interested in
hearing suggestions.


Simultaneously, I'm also looking at expanding the technical scope.
For my own project, the OpenConnect VPN client, I have started to
collect a torture test suite=C2=B3 of RSA, DSA and EC keys in various
PKCS#1, PKCS#8 and PKCS#12 forms =E2=80=94 both unencrypted, and encrypte=
d with
various algorithms. I have yet to embark of the joy of files with non-
ASCII passphrases, especially in non-UTF8 locales =E2=80=94 but I have a =
bottle
of vodka ready to help me do so.

My test suite also includes PKCS#11 tests including private keys where
the token doesn't expose the public component (which made OpenSSL crash
until yesterday, yay!) and certificates with the CKA_PRIVATE attribute
set, so some software will fail to *find* them.

I am thinking of splitting my torture test out from OpenConnect itself,
and making it available as a project in its own right.

I can, of course, lobby to expand the Fedora guidelines to state that
all software packaged for Fedora SHOULD pass the torture test suite,
but I think it makes sense to aim for a wider consensus than that.

Opinions welcome... does it make sense to attempt to publish an
informational RFC outlining such "expectations"? Or should it take some
other form? Or should I just not bother, and continue to push it from
the Fedora angle, since it's getting into a lot of upstream software
already?

I also expect some heckling at my specific test cases =E2=80=94 do we *re=
ally*
expect everyone to support DSA keys still? And PEM files encrypted the
old OpenSSL way? And PKCS#12 files encrypted with MD5-DES?

(I can accept 'no' answers to the latter two only if expressed in a
form which lets me file bugs against ancient "enterprise" software to
stop *creating* them that way...)




_______________________________________________
saag mailing list
saag@=
ietf.org
https://www.ietf.org/mailman/listinfo/saag

--------------9D82E248729F0A448150051A-- --lVaq4OIvAP61qIMr7bxisA4v3NwACbv4s-- --f5NFlp5cIWM53gVvQNkXMNtsBwxQXgN2b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJX4ihsAAoJEIe2a0bZ0noz4mIH/R9rEsolbHCBZrXs00bRMq4z Kb38vyr/Slm/+jRzMtLzGFrbReHoloBh69MRMPz5FxIYa8Tv1asZoGLkT+mi8ME9 dKWHQTLomGTyAuaV3BIjEXxNFzeuXPGln33xVVWDGoYpbFONwliCVi2O1cNPRREH A+9PM0q8RqmHJHcLQYJvuYzEuS2rwkJBHjx6M3Y82DazFF4/lUnVFQ7FYN9zY+Vm ZYG7nhUekZhuCBvbQTPr+7cL7xo/UWovB96mp33j0eDdYLTQtLiETXqOTGI18Cv3 bNcoVYzYbGR5nCKrgXDxpp4tAK4BKN42loCX9+g5s/kBGKuAwsiySDNnQvJGidI= =eBWs -----END PGP SIGNATURE----- --f5NFlp5cIWM53gVvQNkXMNtsBwxQXgN2b-- From BATV+2953c840cc985df65dd1+4777+infradead.org+dwmw2@bombadil.srs.infradead.org Wed Sep 21 02:31:14 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D712B004 for ; Wed, 21 Sep 2016 02:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pHycq7ZQO8c for ; Wed, 21 Sep 2016 02:31:13 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7B8128B44 for ; Wed, 21 Sep 2016 02:31:12 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmds0-0007fX-4C; Wed, 21 Sep 2016 09:31:12 +0000 Message-ID: <1474450269.45169.33.camel@infradead.org> From: David Woodhouse To: Eliot Lear , saag@ietf.org Date: Wed, 21 Sep 2016 10:31:09 +0100 In-Reply-To: <0ca146f9-f916-b066-55ca-852f957e013f@cisco.com> References: <1474280601.144982.263.camel@infradead.org> <0ca146f9-f916-b066-55ca-852f957e013f@cisco.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-XSsm060VDCLkgIW/rkuG" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [saag] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 10:02:57 -0000 --=-XSsm060VDCLkgIW/rkuG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2016-09-21 at 08:27 +0200, Eliot Lear wrote: > Hi David, > Related, but not the same concern: I wonder if we could go further on > guidance for signing and verifying of data at rest.=C2=A0 There are two > clear issues that one could write a lot about: These sound like fun, but I do prefer to tilt at one windmill at a time! > =E2=80=A2 canonicalization; when/how/best practices There are a lot of forms of 'data at rest' to worry about here, with a lot of different use cases. If you're writing a best practice here I'm not quite sure how much more specific you can be than just restating Postel's law :) > =E2=80=A2 best practices for establishing trust of the anchors. That's fairly OS-specific, I think. For X.509 trust anchors we've made good progress on this in Linux. There is now an expectation that you can install a trusted CA and expect it to work across all applications in the system, regardless of which crypto library they use. (This is true for the Fedora distribution of Linux, at least. Although the pieces are all there, other distributions are being *very* slow to pick them up and ship them in a coherent fashion so that this actually works.) For other operating systems, it's been working for much longer =E2=80=94 ad= ding a CA to the system certificate store in Windows also comes with an expectation that well-behaved applications will actually *trust* it for the specified purposes, and I believe it's similar on OSX. --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-XSsm060VDCLkgIW/rkuG Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIxMDkzMTA5WjAvBgkqhkiG9w0BCQQxIgQgA7+x76TVPajrmi9USDsl2QG2ZpjyMAcRDI0D MCg+pQ4wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAMRw yaHRMpw+6MUu9RWZT4U8W16PjhGhPYk1LmPd/mCIULkcUyhWDWxIdjYtz7dxjyQH7qexblS5xxWI jl4sAxkt58LHvRe/7vBXVhOH/E+Zy/nSzptKanspECrKuc5+iq3b0uo223rx7TrfGAebW+wJOz4e XXMj28b3AVN3Uya+cl50+apWXTyslKlFzE2IbvuZyfM7DxOb5594DR+8s66ufYJdrZZFIv1+CJR5 YGc8/3qmFI2hAX6ZTOAYBq6xsXT7h3hsL3W0CjO0mm58zU4wUo44auGdmASipn22dvYFCjf7jYcA 6UNT84UTvPYp5VhC8jMhQDccpuA81c8qtE+upUu5jZjJ+wQIGZfAf0fNQb6EfqJzQAx4u6fsIt4N 5ke3JDOB7/tvzzoU0w60f2q5wqhsHB1ShkkVMPxZoGV0suyB0nZKpUVElCiFQNC8bbHYLSHpzrtg AbLbWjDa8795sRKNg4Xy7Pu98SiNGqjeEsuHzwhcnY7cG+oL+QKzqxzT+wI5cpCT34VbkAHd2xtw FKUBizbQ4zyH0QM+7jbxHVN/sI4884K6vE9+UNd/Ayt1oMcZQZGd0sn8MdS7Msk/E8/G7c1/wvGG P5soJmYvNsLCCWcKLmkBd3NIvjej1kNbN+tgUcTGc3GiNfQwLQgm/ZOU7IKXLxD0Ajsm+XfeAAAA AAAA --=-XSsm060VDCLkgIW/rkuG-- From nobody Wed Sep 21 08:11:59 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24A12B4C1; Wed, 21 Sep 2016 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99tCdmuXvHYz; Wed, 21 Sep 2016 08:11:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1ABE12B4BB; Wed, 21 Sep 2016 08:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1474470715; x=1506006715; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FTBE47BOlfPivYs+3hye3ISPynq0xFFnhMc4SD/v4CE=; b=xSk/lT+YP17uMFaswzvuGsVDwPVSvn2H9HBuqhVnx+xGRGmPltOPgN9X b4T8xNmaXO4dGObINkdFgfj3qIg5DPhFcTLq+IumRTne/vtKVjoBn9flR gqJZ7+Q2SfMMrbyA/fnuo5mShJQkq2Zb71x8Aq+40oKKHilnYQpOObrUX z7qYIyXfRIr/Py8Lt2/Br6KplwKkhw0au+iK2J/YcbhvcXJcSwAsL+nVw DswlwumtNxCNiHGftplUii90eHj5pPzIM7MKTvTmYykbKI2S773wLTN8G St9JpJwxjCWaZK60dyxtyQC7+pE3shXIW5te5UP9ZRMh7TTQvUlAPLm6e A==; X-IronPort-AV: E=Sophos;i="5.30,374,1470657600"; d="scan'208";a="106850386" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2016 03:11:49 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 22 Sep 2016 03:11:49 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 22 Sep 2016 03:11:49 +1200 From: Peter Gutmann To: David Woodhouse , Michael Richardson Thread-Topic: [saag] [Spasm] Best practices for applications using X.509 client certificates Thread-Index: AQHSEq/5nIMxm+cmykaH/hYw9B3r/6CBrdmAgAATEQCAAk6N/w== Date: Wed, 21 Sep 2016 15:11:49 +0000 Message-ID: <1474470703731.18547@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>, <1474387066.144982.443.camel@infradead.org> In-Reply-To: <1474387066.144982.443.camel@infradead.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 15:11:58 -0000 David Woodhouse writes:=0A= =0A= >There are various PKCS#1, PKCS#8, PKCS#12 files in various PEM and DER=0A= >permutations with a selection of weak and strong encryption types (and lac= k=0A= >of encryption).=0A= >=0A= >I know of NOT A SINGLE APPLICATION which will Just Work=99 for every one o= f=0A= >those test cases.=0A= =0A= That's not surprising, you've barely scratched the surface of the mess of= =0A= what's out there for storing private keys, some of it completely undocument= ed,=0A= and yet you want some magic piece of code or app to be able to work with al= l=0A= of them. Not just that, but you're saying that you want Internet Explorer = to=0A= be able to grab GPG keys and OpenSSL to be able to grab Apple account keys = and=0A= Flash Player to be able to grab OpenSSH keys. Is that really what you're= =0A= after?=0A= =0A= Peter.= From nobody Wed Sep 21 14:58:07 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15D12B461; Wed, 21 Sep 2016 14:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwHsCqpKbgj3; Wed, 21 Sep 2016 14:58:02 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E73112B154; Wed, 21 Sep 2016 14:58:02 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bmpWf-0007KR-BK; Wed, 21 Sep 2016 21:57:57 +0000 Message-ID: <1474495074.30494.21.camel@infradead.org> From: David Woodhouse To: Peter Gutmann , Michael Richardson Date: Wed, 21 Sep 2016 22:57:54 +0100 In-Reply-To: <1474470703731.18547@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> , <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-PGZyFu4LE/NvdHG5s9ka" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 21:58:03 -0000 --=-PGZyFu4LE/NvdHG5s9ka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2016-09-21 at 15:11 +0000, Peter Gutmann wrote: > David Woodhouse writes: >=20 > >There are various PKCS#1, PKCS#8, PKCS#12 files in various PEM and DER > >permutations with a selection of weak and strong encryption types (and l= ack > >of encryption). > > > >I know of NOT A SINGLE APPLICATION which will Just Work=E2=84=A2 for eve= ry one of > >those test cases. >=20 > That's not surprising, you've barely scratched the surface of the mess of > what's out there for storing private keys, some of it completely undocume= nted, > and yet you want some magic piece of code or app to be able to work with = all > of them.=C2=A0 Not just that, but you're saying that you want Internet Ex= plorer to > be able to grab GPG keys and OpenSSL to be able to grab Apple account key= s and > Flash Player to be able to grab OpenSSH keys.=C2=A0 Is that really what y= ou're > after? No, the scope here is limited to X.509 certificates and the associated keys, and the *common* formats for those keys. Using GPG and OpenSSH private keys is definitely a long way outside that scope. So let's assume I have a key in a given PEM or DER format file as issued through my employer's PKI infrastructure (and associated client- side provisioning tools. I also have a variety of client applications on my system (openconnect, openvpn, curl, wpa_supplicant, etc.) which can use certificates from files. I just want those applications to work consistently. I don't want them to support different subsets of the common file formats depending on which crypto library they happen to be built against this week, and how much attention their author was paying to such matters. There are a variety of forms which have been the *default* output of tools like OpenSSL over the years, and I've recently been finding some of those which are not accepted by certain client applications (and libraries). That's not acceptable. I don't want *every* possible format to be supported; just the common ones which people are *likely* to encounter in real life. And for hardware tokens... if my employer provided me with a hardware crypto token such as a Yubikey, and the OpenSC driver is installed correctly in my system, then I *really* want to be able to pass the RFC7512 identifier "pkcs11:manufacturer=3Dpiv_II;id=3D%01" to any of those applications and expect them to Just Work=E2=84=A2. That's actually a very reasonable request, I think. --=C2=A0 dwmw2 --=-PGZyFu4LE/NvdHG5s9ka Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIxMjE1NzU0WjAvBgkqhkiG9w0BCQQxIgQgEUfvPPvTDnGHdabTkTgpsgHgQRHDGF7YRnUx nFw6FiMwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAFFU ijFNtN6/yFrEXF4i05727guKZRu/xxNR3gGM215rmA+bKUYDAcMI/vKTmE3Jyx/A/vrDQdXcZoAo tBxVvzUtRbJRY/ltmIk7NYW9WHUoPaaMpPdeytWJqU/Pd07KbBByWQwbHw1bYLgKz89GWTQZhOFa se557mIcOdqklBSOse4QOhMTu0xw9wFxJXAyMqXOJ0a1XGuaXB2FXeP03OYQIQ3J5QBg1fysJ6i1 E2hfY3hCgPlfiEudlKQUCigwRLcP1OHq/skoPXXE+S2iHiARcRy3QhBMD/yA8WgAywpRv+6vbzlQ scK9rWa4Idzax7cfMgSwMrhMKmm90BTFRcpnRcn9oLNizz9rVhlOp4JpOI4iNol5USFXfossTBfM AlfRRGUGVqQGQeA2AGKJwfgEzmQT6NOtDXEHf9G+VAi/05cFDf7ozfGumvUlP1IuSzb6ctg7mANq agGV7EF3ETNua0r8aAM1ckUM61qcB+WkXiTvPTkfL96X2q/dhO2fYdeszVglFNRzKsKPnHFY05s3 88q9PPlN+iOFQQOWlIXgUs6QeYnYE3dSeMOSxlnH3BKiat2s62D2JFUQTlYUy3tqRIQ1rM294Q0y L7ZDSb02Xyv/BeqTbP9Fqoz4xYOHjZNFJhtHdjyy/QXNO9ppIeEo+DnNbPHBhhEzQaIGk9+zAAAA AAAA --=-PGZyFu4LE/NvdHG5s9ka-- From nobody Wed Sep 21 22:04:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDDC12B799; Wed, 21 Sep 2016 22:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feIvbB43a9Mt; Wed, 21 Sep 2016 22:04:35 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6509812B679; Wed, 21 Sep 2016 22:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1474520674; x=1506056674; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YqiutOFUQoErx7eztKowvBX0/0vIdT2S07Zwi8L/egY=; b=EnakGBreG75UO/k+L/aKl+Qu0hmPQ0tFq2C1/OZb3P2fGbhViYOxpYxH Qlo4xpRvG1wJhs0ol4loyFMVgeVyFX1lqppC+62jG2NKePtscaY7tgo5E gTl4IE6FIr9VhQVISG/C/qiDZIm5t2zmMGF2DNeghQK5CyJie1MHHudhz NllObA8sIoBblMki6Zo4jud5QxmRbHHk1Mm8gfx0B+aFdalbesdiQQ0yF CmNscpoWro31zW2P1N4R+ZX6mc747/p7J2c0V08XuWWZwQZ0Xy51LQsfW 5Knw6DssDaTsL0FHvVFC1TgW4waccsBV2cLqJT02R+bRyIAl3M3wye+OL Q==; X-IronPort-AV: E=Sophos;i="5.30,377,1470657600"; d="scan'208";a="106970680" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2016 17:04:32 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 22 Sep 2016 17:04:32 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 22 Sep 2016 17:04:32 +1200 From: Peter Gutmann To: David Woodhouse , Michael Richardson Thread-Topic: [Spasm] [saag] Best practices for applications using X.509 client certificates Thread-Index: AQHSFFM8/XRSMCovG0SGBgcgJhzHQaCE9KsU Date: Thu, 22 Sep 2016 05:04:31 +0000 Message-ID: <1474520671777.43424@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> , <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz>, <1474495074.30494.21.camel@infradead.org> In-Reply-To: <1474495074.30494.21.camel@infradead.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 05:04:36 -0000 David Woodhouse writes:=0A= =0A= >That's actually a very reasonable request, I think.=0A= =0A= I don't know about reasonableness (hey, possibly it is), but it's highly=0A= unlikely it'll ever be addressed. This situation has been with us for=0A= twenty years without much, if any, progress being made (you can go back=0A= two decades and find people complaining about the same thing). You just ha= ve =0A= to work around it... that kinda sucks, but then lots of life in general doe= s.=0A= =0A= Peter.=0A= From BATV+66c94379fcb09c76a7b5+4778+infradead.org+dwmw2@bombadil.srs.infradead.org Thu Sep 22 03:27:28 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92AC12BF33; Thu, 22 Sep 2016 03:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDR91IpOlifV; Thu, 22 Sep 2016 03:27:27 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0277A12BF32; Thu, 22 Sep 2016 03:27:27 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn1Du-0001mT-2Y; Thu, 22 Sep 2016 10:27:22 +0000 Message-ID: <1474540039.45169.62.camel@infradead.org> From: David Woodhouse To: Peter Gutmann , Michael Richardson Date: Thu, 22 Sep 2016 11:27:19 +0100 In-Reply-To: <1474520671777.43424@cs.auckland.ac.nz> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> , <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> ,<1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-9RJlX7kAi3/EPUg9EJ7Z" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "spasm@ietf.org" , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 10:28:25 -0000 --=-9RJlX7kAi3/EPUg9EJ7Z Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 05:04 +0000, Peter Gutmann wrote: > David Woodhouse writes: >=20 > >=20 > > That's actually a very reasonable request, I think. >=20 > I don't know about reasonableness (hey, possibly it is), but it's highly > unlikely it'll ever be addressed. This situation has been with us for > twenty years without much, if any, progress being made (you can go back > two decades and find people complaining about the same thing). You just = have=20 > to work around it... that kinda sucks, but then lots of life in general d= oes. Heh, that's a very defeatist attitude :) I'm happy to tilt at windmills, and writing out a clear set of guidelines for applications to follow will be an important step to pushing them in the right direction. Even without that, there *has* been progress on this front. Below is a non-exhaustive list of "crappiness" that users have experienced =E2=80=94 especially with a focus on Linux and similar operatin= g systems. Note that we have *already* fixed almost all of these, so I am not as pessimistic as you about it being "highly unlikely it'll ever be addressed". I think it makes a lot of sense to write up the recommended best practice, and fix the crypto libraries so they make it hard for applications *not* to follow the best practice, instead of making it hard for applications to get it *right*. Sure, it won't be a panacea, but a world where users have higher expectations and file bugs for "this application does not follow the documented best practice" *will* be a better place. Here's that list of mostly-already-fixed problems: "My distribution builds this application against GnuTLS but this PEM=20 file is in the non-standard OpenSSL encrypted form so it doesn't=20 work." "My token doesn't expose the EC public key so I can't authenticate to the VPN... unless I rebuild OpenConnect to use GnuTLS instead of=20 OpenSSL. But I'm on CentOS where GnuTLS is too old to support Cisco's broken pre-standard version of DTLS." "My distribution builds cURL against NSS so the standard form of the PKCS#11 URI doesn't work and I have to use a NSS-specific way to specify the cert instead." "Hm, my token is installed correctly and works everywhere. I can see=20 my cert in 'seahorse' and 'p11tool' and use it from OpenConnect=E2=80=A6 = but why doesn't it work in Firefox? Oh, because NSS doesn't actually=20 load the tokens listed in the system configuration." "OK, so I fixed that... but now why doesn't it show up in Chrome. That uses NSS too, right? Oh, I have to add it to a *different* configuration file, ffs." "Now openvpn doesn't support the standard URI form either, it uses libpkcs11-helper which has an entirely different format that I need to use to specify the certificate." "Ick, when wpa_supplicant is built against OpenSSL it needs all this=20 explicit "engine" configuration nonsense in *addition* to needing the cert to be specified in a non-standard form. Unlike when built with GnuTLS, when it does just accept a RFC7512 PKCS#11 URI in its 'certificate' option." "Argh, FFS. The OpenSSL engine doesn't load the tokens listed in the=20 system configuration *either*, and needs to be explicitly told which provider module to load. And my application doesn't even give me the=20 hook to do that." "Oh, 'openvpn --cert' takes PEM files according to its documentation=E2=80= =A6 but wait, *this* is a PEM file and it doesn't seem to work. Why?" "Hm, all this *used* to work but when I just renewed my certificate, it magically stopped working... oh, because the new cert was issued with OpenSSL 1.1 and that uses a SHA256 HMAC by default which this version of GnuTLS doesn't cope with. "Oh, my cert is marked with CKA_PRIVATE but libp11 doesn't return it from PKCS11_enumerate_certs() even *after* I log in, so the application can't find it." "Hm, I need to configure my VPN to use the cert in my token but the GUI configuration dialog only lets me choose from a file." --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-9RJlX7kAi3/EPUg9EJ7Z Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTAyNzE5WjAvBgkqhkiG9w0BCQQxIgQgkSdqLaZgEtRMjpU/kgnhCSnOna1FGX2AqsQJ T9ijmRcwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAIrA 3+1TRHC/7hxIg0vGHZofW9axRxnthAUYAJSbPedTb6CnAoHAojZxmmfdUsxq66GekTZQLR4wruRR 3CxV63OmikBYO44DylQrfIi0ockAnbitduVrH4wkjNSCMXnfBfnUyq/xnBekPGbIOq2Z0gSkMRws 6s01WHEyk3kwJl34Gbo01yOYGTO8hY6h4le2PBe7s+U38WI+Bw/7V1HXvs0XyEVGa/gchZwTcXi5 FzOimSyAKgdFDrlEMQlbqmS3e6t23OGITvArCmOhecgFhD2gmmQkgRRU8c6DTGKpNqE6E7L+tVer kNPclfkwhlpq2QIvnVfcnirAofYjVoXqZ6XFfl4bVyZAhlsEW6DDw8DAu3iAR9th9ScclmBT8GsS NnoVujvzYxareJlZChVkZcQGumNeMvgdIsOXNvdeMPaARQeU8IAjcGEckMI6gpiGW5Cv4KIetwpn yobOMqhPnFa/1JdZhDSzsKAueDxMeanf4DPGq588kfY+YTbqONDyQtWfymkJcXmzxI8tDOYUCi0Z ufYLuT41D8F17NLu7+CmQR+wEe1EIWA8KAEt/QbrYZjHlNrKmNQi3NGMhlS8qgW+hjfcy+A+k+Os 7Ojl4fNTTDAeIqLDMm1rJ6kQ1UKHMVgAEWT96JChxQS6yyreqiS+YEhZieHs7diIwxzeXETJAAAA AAAA --=-9RJlX7kAi3/EPUg9EJ7Z-- From nobody Thu Sep 22 07:37:40 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEDE12B21F; Thu, 22 Sep 2016 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FLAEDlK1aWR; Thu, 22 Sep 2016 07:37:36 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BA84012B4F9; Thu, 22 Sep 2016 07:18:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id C426E1F0B; Thu, 22 Sep 2016 14:18:24 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UoGoaVAExUm; Thu, 22 Sep 2016 14:18:24 +0000 (UTC) Received: from [192.168.100.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 1770B1EA6; Thu, 22 Sep 2016 14:18:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1474540039.45169.62.camel@infradead.org> Date: Thu, 22 Sep 2016 10:18:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> To: David Woodhouse X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 14:37:39 -0000 On Sep 22, 2016, at 6:27 AM, David Woodhouse = wrote: > Below is a non-exhaustive list of "crappiness" that users have > experienced =E2=80=94 especially with a focus on Linux and similar = operating > systems. Note that we have *already* fixed almost all of these, so I = am > not as pessimistic as you about it being "highly unlikely it'll ever = be > addressed". I see many of those issues as: * not implementing the standards correctly * using application-specific solutions instead of pre-existing solutions = already in wide use * implementations which produce bad or non-existent log messages=20 In my experience, many critical network applications or "security" = applications produce wonderful messages like "failed". Or "byte 14 not = 6 in my_foo_function()". Nonsense like that degrades security. This problem isn't programming, it's psychology. The programmers have = a mental model in which administrators know everything the programmers = know. This mental model is wrong. Administrators (and end users) need = *different* information than what programmers typically produce. As a case in point, I tried to get client certs working with a = commonly-used application. I followed the docs, and everything looked = like it succeeded. Yet the application refused to use the client = certificate. Why? I have *no idea*. There were no log messages, error = messages, or *anything* which let me know what the application was = doing, and how I could fix the problem. I eventually gave up, and installed a competing product. Which worked = fine the first time. I would hope that any X.509 best practice document takes this into = account. i.e. recommend that the application have a "security log" = which describes WHERE it's looking for certs, WHAT it found, WHY it = worked (or didn't work). Recommending formats for log messages would be = a big plus. It would be good to walk through typical usage scenarios, = and explain which log message should be produced when. Both for "it = works" cases, and for "it doesn't work" cases. Simple messages like that go a *long* way to educating the end user. = Instead of clicking through warning pop-ups, the user has some insight = into what's going on, and why. This empowers the end user to make = better choices. Alan DeKok. From nobody Thu Sep 22 08:33:55 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97B412B3A9 for ; Thu, 22 Sep 2016 08:33:51 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYzsMeuG9NkL for ; Thu, 22 Sep 2016 08:33:49 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E54012BBE3 for ; Thu, 22 Sep 2016 08:33:01 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id y6so72071393lff.1 for ; Thu, 22 Sep 2016 08:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b7bZG7FFn3kNTohc1W2rl/CUKqKo84N0tcI4ZexVsMY=; b=mS41uabSRsUhWE08TXSxVnyUVvBp6vMUfelkxaMW90AYi6Q4/fLmEmNrDnlRd/xu1G F3mNv+Xdwz2qJa9lvAKNejUz9HL+TuZDlV9tHDsvfgG9HuEsKLTeiusqkmmPFOG3egFv K1ndK10b36Om6q5UIUJWzoBQlqArNMBFky4zha/TsPWSZV0AyKXXX9xuorQUp8OhkVZx suK4Su9Mr0fTY4phUiDSMMcfew+61MT3EoMjTtgcxcbGA8+Vrr9ba/KCwnUe9/tbRfKh AhHnfYaQ9WjoLBSu/QpaQIF5nzZ5n0IDD12TENriNO9kksaKl+60KkExZfilh6ydaUhZ N/oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b7bZG7FFn3kNTohc1W2rl/CUKqKo84N0tcI4ZexVsMY=; b=ASzsli1UmrhGZS1aqVKohnOrFVcbJmZyvGPfB5+VBx7J1eC/Y5H87zMx93JUiAYANp gNOpDe3hWCY0rj0lFbq64qBiEextCvpRHJfXaGNeGEa9KqhRMGeI01lqRfcjHmNCjnC/ /pM4u2reuQcjQw6Q9IdKDhC5TG36LMQZmeKHtVmRCPq771FZ/uEG/FnBmtb3+YkkPMHx H8UnGED5NeIkH1EdUL2MuUJpJgXE4Onq9Ka+JvHLwMesp/XF9y6pdxDjPrqWtpfnxSh3 jAcpkoWOQ/Ui26xvLqLhqkfZfzVnMzAdMx6hA2qs/DQ4l1YQ6kXhHBhXBVXOgiLdw9i6 uxsQ== X-Gm-Message-State: AE9vXwMm2sm+5VYr2SbKT6X3OFvn4FckeDh1DCrDFEKQ66K+GwUQJCO3B7eWEoyAvyS27Z2/nCjEJWNOEWKG1Q== X-Received: by 10.25.28.19 with SMTP id c19mr1252400lfc.56.1474558379357; Thu, 22 Sep 2016 08:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 22 Sep 2016 08:32:18 -0700 (PDT) In-Reply-To: <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> From: Ted Lemon Date: Thu, 22 Sep 2016 11:32:18 -0400 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=001a11401be8671a3d053d1a6075 Archived-At: Cc: "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 15:33:52 -0000 --001a11401be8671a3d053d1a6075 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 22, 2016 at 10:18 AM, Alan DeKok wrote: > I would hope that any X.509 best practice document takes this into > account. i.e. recommend that the application have a "security log" which > describes WHERE it's looking for certs, WHAT it found, WHY it worked (or > didn't work). Recommending formats for log messages would be a big plus. > It would be good to walk through typical usage scenarios, and explain which > log message should be produced when. Both for "it works" cases, and for > "it doesn't work" cases. > > Simple messages like that go a *long* way to educating the end user. > Instead of clicking through warning pop-ups, the user has some insight into > what's going on, and why. This empowers the end user to make better > choices. > Yes, this! --001a11401be8671a3d053d1a6075 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 22, 2016 at 10:18 AM, Alan DeKok <aland@deployingradius.co= m> wrote:
=C2=A0I would hop= e that any X.509 best practice document takes this into account.=C2=A0 i.e.= recommend that the application have a "security log" which descr= ibes WHERE it's looking for certs, WHAT it found, WHY it worked (or did= n't work).=C2=A0 Recommending formats for log messages would be a big p= lus.=C2=A0 It would be good to walk through typical usage scenarios, and ex= plain which log message should be produced when.=C2=A0 Both for "it wo= rks" cases, and for "it doesn't work" cases.

=C2=A0 Simple messages like that go a *long* way to educating the end user.= =C2=A0 Instead of clicking through warning pop-ups, the user has some insig= ht into what's going on, and why.=C2=A0 This empowers the end user to m= ake better choices.

Yes, this!=C2=A0

--001a11401be8671a3d053d1a6075-- From nobody Thu Sep 22 09:08:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C290E12B1E9; Thu, 22 Sep 2016 09:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bODsfqLzGL3T; Thu, 22 Sep 2016 09:08:16 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048AD12B5E5; Thu, 22 Sep 2016 09:08:16 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn6Xg-00016h-KD; Thu, 22 Sep 2016 16:08:09 +0000 Message-ID: <1474560485.45169.92.camel@infradead.org> From: David Woodhouse To: Alan DeKok , Nikos Mavrogiannopoulos Date: Thu, 22 Sep 2016 17:08:05 +0100 In-Reply-To: <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-nNG2tgSKA7YUApXLKcF5" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 16:08:23 -0000 --=-nNG2tgSKA7YUApXLKcF5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 10:18 -0400, Alan DeKok wrote: > On Sep 22, 2016, at 6:27 AM, David Woodhouse wrote: > >=20 > > Below is a non-exhaustive list of "crappiness" that users have > > experienced =E2=80=94 especially with a focus on Linux and similar oper= ating > > systems. Note that we have *already* fixed almost all of these, so I am > > not as pessimistic as you about it being "highly unlikely it'll ever be > > addressed". >=20 > I see many of those issues as: >=20 > * not implementing the standards correctly >=20 > * using application-specific solutions instead of pre-existing solutions = already in wide use And partly the fact that there are TOO MANY standards; both de facto and de jure. Just look at the class of "stuff which OpenSSL has produced by default over the years for private keys", including the output of tools such as 'openssl req -new'. There's about a dozen different file formats with which applications should "Just Work", right there. We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back, because OpenSSL 1.1 does that by default. We added pbeWithMD5AndDES-CBC=20 support too, Turns out OpenSSL 1.0.2 is still producing *that* by default with 'openssl pkcs8 -topk8' :) > * implementations which produce bad or non-existent log messages=20 >=20 >=20 > =C2=A0 In my experience, many critical network applications or "security" > applications produce wonderful messages like "failed". Or "byte 14 > not 6 in my_foo_function()". Nonsense like that degrades security. I'd note that those are two very different classes of bad error message. The first is bad because it doesn't provide any information about what went wrong; merely that something did. This is the type of bad error message which is most common. The second is bad because it's giving the wrong information. But it's still better than the first, because at least I can go and read my_foo_function() and see what's going on. > =C2=A0 I would hope that any X.509 best practice document takes this into > account. i.e. recommend that the application have a "security log" > which describes WHERE it's looking for certs, WHAT it found, WHY it > worked (or didn't work). Recommending formats for log messages would > be a big plus. It would be good to walk through typical usage > scenarios, and explain which log message should be produced when.=20 > Both for "it works" cases, and for "it doesn't work" cases. Crappy error handling is a personal bugbear of mine... but I'd actually tried *not* to get too distracted by it in putting together the draft. It's not really specific to X.509 best practices at all. Nevertheless, some wording on it did slip into the draft that Nikos and I have started working on, because I just couldn't help myself. Here is a very early attempt at that draft. I have tried quite hard to limit the scope because as this discussion has showed, there are plenty of possibilities for "mission creep". http://david.woodhou.se/draft-woodhouse-cert-best-practice.html https://github.com/dwmw2/ietf-cert-best-practice I should point out that although I put Nikos's name on it and he has contributed many improvements, any egregious errors and stupidities in it should be blamed on me. Especially as I didn't actually double-check=20 with him before posting it here. :) --=C2=A0 dwmw2 --=-nNG2tgSKA7YUApXLKcF5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTYwODA1WjAvBgkqhkiG9w0BCQQxIgQgN6MXXpabIjGdvddFe8b5ZAIY+RHGkV4ZsTn6 HDBMqQowgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAH0I 640SKOGZgAX5pQnqEo7oQTIB2Qcpj1cGyaXMZpxBc8Z404CfTazy/L/d+E8wrq9KWwZ07dmomGgE lHkpqSrwIDr9I5NhQQP2LGic3OpNpXEaw+rd4LkDABdKoPqJk2EDIHaL51F+YufZRPnf+SYcjXgv mthbh28Vx/WBJwkP4ULESPIhkRXnIgFtY5E9zurFQmwl3F7tHkd6W9NXMZWRIXQLIav2D5mT/fNi 9ZnXI4i+0St7x3Nec7CJrmgwD0rd+X3ZEoK9aAgUe3XYmnUp0bUaY6b8tcQPiEjtS04dn3p0L6pD /7FCelKk7NV/3ryaQJZV3hW1NEvT6OtSzFzE/xbc1nodZFFF2qVp3ZeLTggjwfBgHACOjgpQNHJO FKMXIhdrAuXRmnpD6cejrIFhT195VtAqEpKB7Wf5uwsTGoJh1aVFF18z8lkxQcOLA1xuiUZavBm2 mgsrTCk7+lqiLvjdIZKVPS2NHNfYkJTqR6d+/tojpeAR4Feptwgc/nIeLwRRp8L72ubbYGbvEulf chXvxQPKNWJ247iDksM8sK/lSc5SuSNLocfFsMXSKe4Zj7odeMG6DQ2jTfvVq9T5bh9yqjJaIi7l sECOgjZGQpQVa1JGY4fE9osmPGClXvJS1Q2OCArk01ychd8BGrP1MDhAbvMGhvbZW4v6XjFSAAAA AAAA --=-nNG2tgSKA7YUApXLKcF5-- From nobody Thu Sep 22 09:18:15 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA5112B8AA for ; Thu, 22 Sep 2016 09:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMmjkhw9oLYv for ; Thu, 22 Sep 2016 09:18:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B3E12D7E2 for ; Thu, 22 Sep 2016 09:17:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1727E284809; Thu, 22 Sep 2016 16:17:28 +0000 (UTC) Date: Thu, 22 Sep 2016 16:17:28 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20160922161728.GC4670@mournblade.imrryr.org> References: <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1474560485.45169.92.camel@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 16:18:13 -0000 On Thu, Sep 22, 2016 at 05:08:05PM +0100, David Woodhouse wrote: > We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back, > because OpenSSL 1.1 does that by default. One might reasonably say that's progress. > We added pbeWithMD5AndDES-CBC > support too, Turns out OpenSSL 1.0.2 is still producing *that* by > default with 'openssl pkcs8 -topk8' :) One might reasonably say that's backwards compatibility. Stable releases get bug fixes, not feature changes. Legacy behaviour sucks, but not as badly as incompatible changes that break stuff. -- Viktor. From nobody Thu Sep 22 09:29:27 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1BD12C07E for ; Thu, 22 Sep 2016 09:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkrhC_SlK3hI for ; Thu, 22 Sep 2016 09:29:24 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1A712D999 for ; Thu, 22 Sep 2016 09:28:59 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn6rq-0008NE-M2; Thu, 22 Sep 2016 16:28:59 +0000 Message-ID: <1474561736.45169.100.camel@infradead.org> From: David Woodhouse To: Viktor Dukhovni , saag@ietf.org Date: Thu, 22 Sep 2016 17:28:56 +0100 In-Reply-To: <20160922161728.GC4670@mournblade.imrryr.org> References: <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-F83w50SoZVIqbfoMZcAo" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 16:29:26 -0000 --=-F83w50SoZVIqbfoMZcAo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 16:17 +0000, Viktor Dukhovni wrote: > On Thu, Sep 22, 2016 at 05:08:05PM +0100, David Woodhouse wrote: > > We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back, > > because OpenSSL 1.1 does that by default. >=20 > One might reasonably say that's progress. >=20 > > We added pbeWithMD5AndDES-CBC=20 > > support too, Turns out OpenSSL 1.0.2 is still producing *that* by > > default with 'openssl pkcs8 -topk8' :) > > One might reasonably say that's backwards compatibility. Stable > releases get bug fixes, not feature changes. Legacy behaviour > sucks, but not as badly as incompatible changes that break stuff. Surely we could at least update to 3-DES without breaking too much? But yes, one might reasonably say both those things. One might even *try* to say them both in the same breath and keep a straight face. :) But actually I'm not *complaining* about that. I am merely saying "These things exist. Client applications need to cope with them." If you want *complaining*, see the bit about "crypto libraries need to make it hard for the application authors to get this WRONG, not hard for them to get it RIGHT". And the bit about character set handling PKCS#12 passwords. That one is *definitely* complaining :) --=20 dwmw2 --=-F83w50SoZVIqbfoMZcAo Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTYyODU2WjAvBgkqhkiG9w0BCQQxIgQg92MeD0MCRzZmFHVA8t9pjHjwiyi2ijTsUlHL KsDoe4QwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAJ53 rKqEtz6/FVyWGE/xa+8ART/iS4QuJRqCs02R7LVMZrFVMmk9233wzXPZoFZ2ba7+FtnQBcYdwdZE 0jAOFsicz8ix3xrM8fNxYqXKiQCpQ3I0GAfH5deYvP8GdX/7U0Pxo2+lBJxig4UO2R3nH3Sk2XPn eYv0/e6n9bco/LHzWbcJvO67qGaWqjeUMUMi6srbc6NNrbboH2WZtLTQkbSFJDhJbam/ziTibz0l YkHdzhdFOLk9K6KtKf5X7x2lDM/0m3hJXFp9dDXfXll2MyMNDB/pjUusUrWaF4srATMHYrSY+zvc NAxdNmvo+8YAcTXfe1HjHTwWZvqxO51CUkbHpB2MFtB/UM7TI2ETIyROIYV57nRFOm+uRpaLcUtC eI82Y/6Sgf9sLpyk5Dxs2z6IJtvSFqFmU0IEphm73ER4GHvswZl1RVQakdsqDzTZ6+8zUleNsPlx 9d7T9VsTT7oF/uEv579lIprJWoHri3adnjxNb57XOB7kho4CYWNVMGevosA08KXKYT/wNB0Xrejo dYS0sV8y47LZYxEKLKrV0fqJ6p+g/E3APFylGVeHS7v26uy99SIHbl67sw5PJulG1+WgxCl2dpYt FmKE8Jfu4yFP5f0wFw/WXnSkl5tbzuhu1+fhzwV5rG9kWm6LN6aoiSS715FLz1wBuhC7mEzeAAAA AAAA --=-F83w50SoZVIqbfoMZcAo-- From nobody Thu Sep 22 09:52:38 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6612D115 for ; Thu, 22 Sep 2016 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xGPu6QzR07O for ; Thu, 22 Sep 2016 09:52:34 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FFF12D5B0 for ; Thu, 22 Sep 2016 09:49:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 19CAE284809; Thu, 22 Sep 2016 16:49:24 +0000 (UTC) Date: Thu, 22 Sep 2016 16:49:24 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20160922164924.GD4670@mournblade.imrryr.org> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1474561736.45169.100.camel@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 16:52:37 -0000 On Thu, Sep 22, 2016 at 05:28:56PM +0100, David Woodhouse wrote: > > One might reasonably say that's backwards compatibility. Stable > > releases get bug fixes, not feature changes. Legacy behaviour > > sucks, but not as badly as incompatible changes that break stuff. > > Surely we could at least update to 3-DES without breaking too much? Hard to say what would break, changing default formats in a stable release is not really an option. Users who want a specific format can explicitly request it. Examples of recommended default overrides in the documentation would probably be a good idea. Figuring out sensible overrides is not always easy. > But yes, one might reasonably say both those things. One might even > *try* to say them both in the same breath and keep a straight face. :) Indeed, straight as an arrow. :-) > And the bit about character set handling PKCS#12 passwords. That one is > *definitely* complaining :) That's a fun one. A lot of discussion went into the compromise approach to that issue in 1.1.0. If you think the end result could be significantly improved, do speak up (issue or pull request on Github would be great). -- Viktor. From nobody Thu Sep 22 10:07:52 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6059512D9D5 for ; Thu, 22 Sep 2016 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uY1SCj8UPvkC for ; Thu, 22 Sep 2016 10:07:38 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E42D12B2FF for ; Thu, 22 Sep 2016 10:02:38 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn7OF-0005hg-1l; Thu, 22 Sep 2016 17:02:27 +0000 Message-ID: <1474563744.45169.105.camel@infradead.org> From: David Woodhouse To: Viktor Dukhovni , saag@ietf.org Date: Thu, 22 Sep 2016 18:02:24 +0100 In-Reply-To: <20160922164924.GD4670@mournblade.imrryr.org> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-qv4hKiBwgACYvhSVs6lA" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 17:07:51 -0000 --=-qv4hKiBwgACYvhSVs6lA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 16:49 +0000, Viktor Dukhovni wrote: > On Thu, Sep 22, 2016 at 05:28:56PM +0100, David Woodhouse wrote: >=20 > >=20 > > >=20 > > > One might reasonably say that's backwards compatibility. Stable > > > releases get bug fixes, not feature changes. Legacy behaviour > > > sucks, but not as badly as incompatible changes that break stuff. > >=20 > > Surely we could at least update to 3-DES without breaking too much? >=20 > Hard to say what would break, changing default formats in a stable > release is not really an option.=20 Ah, but if I let you get away with saying "in a stable release" then we have to take a long hard look at the fact that OpenSSL 1.0.2 was released in January of last year, and Single-DES+MD5 wasn't *really* a good thing to have as a default even then :) But I'm fairly sure I checked when I was first putting together my torture tests, and OpenSSL 1.1 *has* updated the default here. So I'll stop being cruel :) > > And the bit about character set handling PKCS#12 passwords. That one is > > *definitely* complaining :) >=20 > That's a fun one. A lot of discussion went into the compromise > approach to that issue in 1.1.0. If you think the end result could > be significantly improved, do speak up (issue or pull request on > Github would be great). https://github.com/openssl/openssl/pull/1518 is a start, just some preliminary cleanup without actually making functional changes. I think that that point I hadn't *quite* realised that I'd missed the boat for 1.1. --=20 dwmw2 --=-qv4hKiBwgACYvhSVs6lA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTcwMjI0WjAvBgkqhkiG9w0BCQQxIgQgEDd++ZVr+bsU3U+42on/zeq3zFQ+B1fvjoD+ /fpk4SUwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICABMG Rr0C+7xGT5OV4w20DFnnO1z8+yq9BKY7Kr7FUkajiUU8wx2L3i9KFEgBk12G5Y02DRqvbAb7ir5X 1AMKEBQwmTWjh9G/AmvUrUddiHhsvrApUYhQvOUGS99vL9U7bTXH5s+OXIpVv2VwPTXPbDsur928 yVLcopUnK4TNG2VDD9Cnci0TsYiOteMQgsOvSuJchLSmyDKdA00ESYJrw2TF/Wa5Otd6lFWjKe04 QxrkiimiR2gLySX4vRzlVCRPexHY1Y7HeKz1OOCMNj5v+oA9LFz6v4WH4yQGpurHfsZvgVsscxkE vYLpY7brQ0R3ZljrEIXEJLTSdaUY0yC8DvNWbRUExKtC/gcTr5vY+EEL8/y7JZZ23xiSlywEy3qx 8AZgtQBlu7OZEhrEKHi+uAcTZtOJ+UlJdoumLnTwEjjIhaqIpxLvdE/o9QwLcSoemPb3vt8FwyZb Yf5D4CSHkd4p/uVXHRN5AEN9rjqNKdd2PCZCR0RZFcyE9Ayc7bE/WG+P3zlNacezgj2AwSfYh6st bpJPt+uvI6U8DS0AWnHQiBU4PPc9IpzAJV8DpND2S7VfetInw1XXaUyObnKvF/QmcMjFSQYpgrGb v4wqnE09zs+XgcAwTIUrL0U/F6WCpYEkj5TZ/TEUO/q8aQxGWxZ2e2eK/tMhbgrbKVbwJqktAAAA AAAA --=-qv4hKiBwgACYvhSVs6lA-- From nobody Thu Sep 22 10:36:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2812C06C for ; Thu, 22 Sep 2016 10:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnBQaRMeFdxD for ; Thu, 22 Sep 2016 10:36:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D2112D142 for ; Thu, 22 Sep 2016 10:36:50 -0700 (PDT) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 19D4D282D45 for ; Thu, 22 Sep 2016 17:36:50 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <1474563744.45169.105.camel@infradead.org> Date: Thu, 22 Sep 2016 13:36:49 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> <1474563744.45169.105.camel@infradead.org> To: Security Area Advisory Group X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Security Area Advisory Group List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 17:36:52 -0000 > On Sep 22, 2016, at 1:02 PM, David Woodhouse wrote: > > But I'm fairly sure I checked when I was first putting together my > torture tests, and OpenSSL 1.1 *has* updated the default here. So I'll > stop being cruel :) Yes, 1.0.2 is from Jan/2015, but the contract with the users is that maj.min.mic

releases just fix bugs, maj.min.mic+1 releases add compatible features, and maj.min+1 releases are where we can make any necessary incompatible changes. The 1.0.x series started with 1.0.0 on 2010/03/29. It is rather long in the tooth, and will be a decade old by the time the 1.0.2 LTS release reaches end-of-life. -- Viktor. From nobody Thu Sep 22 11:08:36 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9EC12B6C2 for ; Thu, 22 Sep 2016 11:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugTItQ7F4yvN for ; Thu, 22 Sep 2016 11:08:34 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0047812B3E6 for ; Thu, 22 Sep 2016 11:08:33 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn8QC-0003cG-U7; Thu, 22 Sep 2016 18:08:33 +0000 Message-ID: <1474567710.30494.54.camel@infradead.org> From: David Woodhouse To: Viktor Dukhovni , Security Area Advisory Group Date: Thu, 22 Sep 2016 19:08:30 +0100 In-Reply-To: References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> <1474563744.45169.105.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-hrC9EQrF5erJJ1HfU316" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 18:08:35 -0000 --=-hrC9EQrF5erJJ1HfU316 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 13:36 -0400, Viktor Dukhovni wrote: > Yes, 1.0.2 is from Jan/2015, but the contract with the users is that > maj.min.mic

releases just fix bugs, maj.min.mic+1 releases add > compatible features, and maj.min+1 releases are where we can make > any necessary incompatible changes. >=20 > The 1.0.x series started with 1.0.0 on 2010/03/29.=C2=A0=C2=A0It is rathe= r > long in the tooth, and will be a decade old by the time the 1.0.2 > LTS release reaches end-of-life. OK, then I concede the point. Single-DES and MD5 were a *perfectly* acceptable default in 2010, and nobody could have predicted that they would be considered obsolete within the lifetime of the OpenSSL 1.0.x series. Neither would anyone consider it a bug that Single-DES and MD5 are being employed by default in 2016. :) (And to be fair, who uses 'openssl pkcs8 -topk8' anyway? It's not like this is in the output of 'openssl req -new' or stuff like that. That one is at least AES128 in OpenSSL 1.0.2 isn't it?) --=20 dwmw2 --=-hrC9EQrF5erJJ1HfU316 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTgwODMwWjAvBgkqhkiG9w0BCQQxIgQg4wDqmJY2SmU6XiiSI9vFZQeDlY292TX14W8Z CWKmuVMwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICALm5 EKJzVjgbCaDDC/LxVtpbijBaN0kFp7vt97+KcQ2ez+Rzl6u10WvNPSGqmwsMvazGGxiYTimfc1Gm NaDAhxrMkpmBuHcyROgScFM9e8eIv3z3sWSAxwa882yXtiJ2vMw5jrIM/4Fo+vkuFP0q9Gq/B8Dh dlBKPV7rXo+REvESRQOfMa3id/hRX6Y2Oz4y9yB0de8eCzUNVm+ZRjT7U22wI7qGy8B8x0cvqxzL w41rkPRdALlGyhj1y5+QShf9ejRvOYv0CjL1BcON1bNMKeTwe1oAXHcsrBAyOS4yfYMzSzFghHoU 8dN3Z6z9DpHHao/gw7kYcNW8HHeh/7jmWia5B45RsJ7JmxxAdLwCcE+yHbXHA81U8lMaIjNKOsIR a6HalVL8N7XbDL02XqvF7B991QHHOGbVD9hI8uLUyKqI4PvBdNGfLViXgt4XD06sBS/a54bd7DcY xjHBXnA2Sz+2Gfkztka5ctHJcJa/3s6/9Gmk4ipz+xyhb5UAt+hErodip9hKIDJy/3tKs8Nqgdu2 v1X2pB6XHCyzeKrUDSVWBkTEXaeR3Pa2WSxhiNyy6/d4A6sxBL1wGHTMhVD4+UmWSZOPUFUFTcew UBxwXclPZqqtBbPumSvdHv8pKRrMK8KP+WkAMSqzhKww4Fyqi9U7bB3omMK/u5oEEOWMXggAAAAA AAAA --=-hrC9EQrF5erJJ1HfU316-- From nobody Thu Sep 22 11:25:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FAA12B150 for ; Thu, 22 Sep 2016 11:24:57 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4cubNXtTrcX for ; Thu, 22 Sep 2016 11:24:53 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F018F12B092 for ; Thu, 22 Sep 2016 11:24:52 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id b71so49056210lfg.0 for ; Thu, 22 Sep 2016 11:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pHSBjIs5cVU7g7tvJY/wTJfxp0ocpXbQ0Ohz+hF2tvk=; b=V/97N9tWnhUFj0HBoFdbw8+Nd3fVuNpJYcXFbu8V2ddsz90fhhLhKnu4X5w2hT40ig HoQR5qjO5A0tfwGvZY3v9fNDDJxxRXa3r9QmFUVbgkybWpfVqQHCMi7XPkqZFp3u+GKH GQT48pYxFVWujtWpITBKs7zrPh687ILnA+mckG8EbLHKYN0zCQqQ5L+27wvMi5JQFRwE 1QT+s/9htxhs+Jvsy6wmj6PRKAnV2zKc9O+53zV4GynL7LfJdYBHGAfnchXDX8v2A/ys R/pbyHrxRqATbVmTiEhPTDq4fnq8ILujR5WWG4YDMAVvp5ZNxtnYRCAece5l+9zNNDF9 eksg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pHSBjIs5cVU7g7tvJY/wTJfxp0ocpXbQ0Ohz+hF2tvk=; b=ZEC/mZqHaGDDtL+EKByawlGhMhCmynwuQyM3u/zhWsCMIaGOb7E77LNwW9USPA6PyN pQWPC8R0o35lcT1nBU+yBJrE7SgU+uIFtMsLMj0HzII0RkftGt+g/UOAah7tZenM4yiQ 4Q7XDLqlECzIdgX9CBwvI/rbFZka6Xy5He06eXCQT0crBb6kDe0cKtoNGgq6wJWIE9CK WCgXZzqfDG5zOpZew7TZF+nCSP0TsMSvi7TIA52gKGzZT/S9ZVvUQHg2tKrJulQpNVy/ RWxD2pxJkJR1jqmOhvblFTNAbnZ3VkyETwhFQ3/TYOSP6xyPTvjOTfUw/uIyJVsnCwWT Dd1A== X-Gm-Message-State: AE9vXwOxjfus1oLKPYHmBCxcrFYTD+lxgPB9azxhQ0qa7NoQRrOwSsdThcpJ0MzAr6JU/659nkm3h435b+IB6w== X-Received: by 10.25.18.23 with SMTP id h23mr1505428lfi.5.1474568690909; Thu, 22 Sep 2016 11:24:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 22 Sep 2016 11:24:10 -0700 (PDT) In-Reply-To: <1474560485.45169.92.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> From: Ted Lemon Date: Thu, 22 Sep 2016 14:24:10 -0400 Message-ID: To: David Woodhouse Content-Type: multipart/alternative; boundary=001a113fb46004de82053d1cc734 Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 18:24:58 -0000 --001a113fb46004de82053d1cc734 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This looks good generally. However, one concern I have about it is that we actually really don't want applications to have access to private keys. Well, anyway I don't. I want the private key to be in an engine where it can't be gotten out by the application, and I want the application to provide data for the engine to process: cleartext in, ciphertext out. This is a big ask, and I realize that, so I am not saying that this document is wrong. But I'm bringing it up because I wonder if you've thought about it, and possibly considered specifying this operational model as well. Not being a security expert myself, is what I am asking for technically unreasonable, or do you just think it doesn't need to be scoped in to this work? On Thu, Sep 22, 2016 at 12:08 PM, David Woodhouse wrote: > On Thu, 2016-09-22 at 10:18 -0400, Alan DeKok wrote: > > On Sep 22, 2016, at 6:27 AM, David Woodhouse > wrote: > > > > > > Below is a non-exhaustive list of "crappiness" that users have > > > experienced =E2=80=94 especially with a focus on Linux and similar op= erating > > > systems. Note that we have *already* fixed almost all of these, so I = am > > > not as pessimistic as you about it being "highly unlikely it'll ever = be > > > addressed". > > > > I see many of those issues as: > > > > * not implementing the standards correctly > > > > * using application-specific solutions instead of pre-existing solution= s > already in wide use > > And partly the fact that there are TOO MANY standards; both de facto > and de jure. > > Just look at the class of "stuff which OpenSSL has produced by default > over the years for private keys", including the output of tools such as > 'openssl req -new'. There's about a dozen different file formats with > which applications should "Just Work", right there. > > We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back, > because OpenSSL 1.1 does that by default. We added pbeWithMD5AndDES-CBC > support too, Turns out OpenSSL 1.0.2 is still producing *that* by > default with 'openssl pkcs8 -topk8' :) > > > * implementations which produce bad or non-existent log messages > > > > > > In my experience, many critical network applications or "security" > > applications produce wonderful messages like "failed". Or "byte 14 > > not 6 in my_foo_function()". Nonsense like that degrades security. > > I'd note that those are two very different classes of bad error message. > > The first is bad because it doesn't provide any information about what > went wrong; merely that something did. This is the type of bad error > message which is most common. > > The second is bad because it's giving the wrong information. But it's > still better than the first, because at least I can go and read > my_foo_function() and see what's going on. > > > I would hope that any X.509 best practice document takes this into > > account. i.e. recommend that the application have a "security log" > > which describes WHERE it's looking for certs, WHAT it found, WHY it > > worked (or didn't work). Recommending formats for log messages would > > be a big plus. It would be good to walk through typical usage > > scenarios, and explain which log message should be produced when. > > Both for "it works" cases, and for "it doesn't work" cases. > > Crappy error handling is a personal bugbear of mine... but I'd actually > tried *not* to get too distracted by it in putting together the draft. > It's not really specific to X.509 best practices at all. Nevertheless, > some wording on it did slip into the draft that Nikos and I have > started working on, because I just couldn't help myself. > > Here is a very early attempt at that draft. I have tried quite hard to > limit the scope because as this discussion has showed, there are plenty > of possibilities for "mission creep". > > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html > https://github.com/dwmw2/ietf-cert-best-practice > > I should point out that although I put Nikos's name on it and he has > contributed many improvements, any egregious errors and stupidities in > it should be blamed on me. Especially as I didn't actually double-check > with him before posting it here. :) > > -- > dwmw2 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --001a113fb46004de82053d1cc734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This looks good generally. =C2=A0 However, one concern I h= ave about it is that we actually really don't want applications to have= access to private keys. =C2=A0 Well, anyway I don't. =C2=A0 I want the= private key to be in an engine where it can't be gotten out by the app= lication, and I want the application to provide data for the engine to proc= ess: cleartext in, ciphertext out. =C2=A0 This is a big ask, and I realize = that, so I am not saying that this document is wrong. =C2=A0 But I'm br= inging it up because I wonder if you've thought about it, and possibly = considered specifying this operational model as well. =C2=A0 Not being a se= curity expert myself, is what I am asking for technically unreasonable, or = do you just think it doesn't need to be scoped in to this work?

On Thu, Sep 22, 201= 6 at 12:08 PM, David Woodhouse <dwmw2@infradead.org> wrote= :
On Thu, 2016-09-22 at = 10:18 -0400, Alan DeKok wrote:
> On Sep 22, 2016, at 6:27 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > Below is a non-exhaustive list of "crappiness" that use= rs have
> > experienced =E2=80=94 especially with a focus on Linux and simila= r operating
> > systems. Note that we have *already* fixed almost all of these, s= o I am
> > not as pessimistic as you about it being "highly unlikely it= 'll ever be
> > addressed".
>
>=C2=A0 =C2=A0I see many of those issues as:
>
> * not implementing the standards correctly
>
> * using application-specific solutions instead of pre-existing solutio= ns already in wide use

And partly the fact that there are TOO MANY standards; both de facto=
and de jure.

Just look at the class of "stuff which OpenSSL has produced by default=
over the years for private keys", including the output of tools such a= s
'openssl req -new'. There's about a dozen different file format= s with
which applications should "Just Work", right there.

We added HMAC-SHA256 support to GnuTLS PKCS#12 just a week or two back,
because OpenSSL 1.1 does that by default. We added pbeWithMD5AndDES-CBC
support too, Turns out OpenSSL 1.0.2 is still producing *that* by
default with 'openssl pkcs8 -topk8' :)

> * implementations which produce bad or non-existent log messages
>
>
> =C2=A0 In my experience, many critical network applications or "s= ecurity"
> applications produce wonderful messages like "failed".=C2=A0= Or "byte 14
> not 6 in my_foo_function()".=C2=A0 Nonsense like that degrades se= curity.

I'd note that those are two very different classes of bad error = message.

The first is bad because it doesn't provide any information about what<= br> went wrong; merely that something did. This is the type of bad error
message which is most common.

The second is bad because it's giving the wrong information. But it'= ;s
still better than the first, because at least I can go and read
my_foo_function() and see what's going on.

> =C2=A0 I would hope that any X.509 best practice document takes this i= nto
> account.=C2=A0 i.e. recommend that the application have a "securi= ty log"
> which describes WHERE it's looking for certs, WHAT it found, WHY i= t
> worked (or didn't work).=C2=A0 Recommending formats for log messag= es would
> be a big plus.=C2=A0 It would be good to walk through typical usage > scenarios, and explain which log message should be produced when.
> Both for "it works" cases, and for "it doesn't work= " cases.

Crappy error handling is a personal bugbear of mine... but I'd a= ctually
tried *not* to get too distracted by it in putting together the draft.
It's not really specific to X.509 best practices at all. Nevertheless,<= br> some wording on it did slip into the draft that Nikos and I have
started working on, because I just couldn't help myself.

Here is a very early attempt at that draft. I have tried quite hard to
limit the scope because as this discussion has showed, there are plenty
of possibilities for "mission creep".

http://david.woodhou.se/draft-wo= odhouse-cert-best-practice.html
https://github.com/dwmw2/ietf-cert-best-practic= e

I should point out that although I put Nikos's name on it and he has contributed many improvements, any egregious errors and stupidities in
it should be blamed on me. Especially as I didn't actually double-check=
with him before posting it here. :)

--=C2=A0
dwmw2
_______________________________________________=
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--001a113fb46004de82053d1cc734-- From nobody Thu Sep 22 12:01:42 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ABD12B74A; Thu, 22 Sep 2016 12:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvmrIgt83KiV; Thu, 22 Sep 2016 12:01:36 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E981A12B43B; Thu, 22 Sep 2016 12:01:12 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn9F6-0003k9-IK; Thu, 22 Sep 2016 19:01:08 +0000 Message-ID: <1474570865.30494.68.camel@infradead.org> From: David Woodhouse To: Ted Lemon Date: Thu, 22 Sep 2016 20:01:05 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ZiKvNRFPg/W+IjAqnOh0" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:01:38 -0000 --=-ZiKvNRFPg/W+IjAqnOh0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 14:24 -0400, Ted Lemon wrote: > This looks good generally. =C2=A0 However, one concern I have about it is > that we actually really don't want applications to have access to > private keys. =C2=A0 Well, anyway I don't. =C2=A0 I want the private key = to be > in an engine where it can't be gotten out by the application, and I > want the application to provide data for the engine to process: > cleartext in, ciphertext out.=20 This sounds a little bit like the model we were using with TPM(v1). With the OpenSSL TPM ENGINE, the user 'wraps' a key with the TPM and gets to keep a PEM file that starts like this: -----BEGIN TSS KEY BLOB----- Whenever the user wants to use that key, they simply use that PEM file instead of one of the other multitude of supported formats and it "Just Works". I had lots of fun making that work for GnuTLS too: http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.= c Is that what you were after? I did consider writing that one down too, but figured it was a little too esoteric. And perhaps we should have exposed the TPM via a PKCS#11 provider in the first place anyway. > =C2=A0 This is a big ask, and I realize that, so I am not saying that thi= s > document is wrong. =C2=A0 But I'm bringing it up because I wonder if > you've thought about it, and possibly considered specifying this > operational model as well. =C2=A0 Not being a security expert myself, is > what I am asking for technically unreasonable, or do you just think > it doesn't need to be scoped in to this work? I absolutely agree that applications MUST NOT rely on having access to the actual private key material. They need to support using opaque keys from hardware and software tokens. But I was envisaging that PKCS#11 would be the vehicle for that. --=20 David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation --=-ZiKvNRFPg/W+IjAqnOh0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTkwMTA1WjAvBgkqhkiG9w0BCQQxIgQgC5Sw0BLnGHsrtdALj2OPMRaXEYq7hbNfAOSj AeETGyQwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAMON B3cXy4mH3WHRP7k/dweuhwCILvtQCoW3YB4RmtFWOistnRradBmx2BWgeO8sl1zm6c3NuLSSaHSx +7IcqjKLY1MJ6DFTLguIVx6qkBA8SdGhI7OiThVhwMthY59esl0/JWtcg3nb6Um3JzVBwh8jq0HW KbCpnEDe7wqnmYYbzNonxzKbhlYP+orIpk+EE4IeQd2ad0wKkY77/3evD/aQC0L52KrOzbM0RWjL Ut/FG865EovwVwvCD4A1ZMxkaWjzbQhab6xe/ulcMdpKaVc8zwLht6lisSGebblaGlpYoVkQhg74 R3OiesWlIMVxCRMOZw28ioR0qRF9UayWXKNmRcbyHvFFQSPfnJpRCuAmFmsfE4Fdfd6vW2EUhcYr 4/ID9c0TnjgIPB1xN5LHeI/TeXGmv4cMxOTerHw0qm9t/ZhxzbN9WCPD8L4Y8cHFF1+zPFOvFJQP 3UgO8dbpMuhVKBagxnrO9sg6+YmpmIrDc3skA2hDzAQsXEFgTVkHTeAyLU0HDDjwJkaJ5aBRxAhp ul2oBzMGDFo7KB/JV2Qje89wMzAqwnY2az8c3vFWek88Xk94M3kaj//T4rpWRNqHjMeYOCddRBJE Pe04uqlS6tMCxYByYT7sQSiuuPk2wVihC4SeodwHmOb6vAhPCA5x8CWQlDkTS+oZgqLfx6ahAAAA AAAA --=-ZiKvNRFPg/W+IjAqnOh0-- From nobody Thu Sep 22 12:19:55 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E18512D8E1 for ; Thu, 22 Sep 2016 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jsrjFv8oRMf for ; Thu, 22 Sep 2016 12:19:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E76412BC8F for ; Thu, 22 Sep 2016 12:19:50 -0700 (PDT) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 0CD04282F88 for ; Thu, 22 Sep 2016 19:19:49 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <1474567710.30494.54.camel@infradead.org> Date: Thu, 22 Sep 2016 15:19:48 -0400 Content-Transfer-Encoding: 7bit Message-Id: <36E0AD53-91B2-44EC-AACF-C7BB7E60113D@dukhovni.org> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> <1474563744.45169.105.camel@infradead.org> <1474567710.30494.54.camel@infradead.org> To: Security Area Advisory Group X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Security Area Advisory Group List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:19:52 -0000 > On Sep 22, 2016, at 2:08 PM, David Woodhouse wrote: > > > OK, then I concede the point. Single-DES and MD5 were a *perfectly* > acceptable default in 2010, and nobody could have predicted that they > would be considered obsolete within the lifetime of the OpenSSL 1.0.x > series. Neither would anyone consider it a bug that Single-DES and MD5 > are being employed by default in 2016. > > :) > > (And to be fair, who uses 'openssl pkcs8 -topk8' anyway? It's not like > this is in the output of 'openssl req -new' or stuff like that. That > one is at least AES128 in OpenSSL 1.0.2 isn't it?) Sarcasm bordering on trolling is fun, for real excitement hop into your handy back-yard time-machine, go back to 2010, donate your copious spare time (hey you've got a time-machine) to OpenSSL and get it fixed! :-) :-) -- Viktor. From nobody Thu Sep 22 12:26:57 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CE112DA4F for ; Thu, 22 Sep 2016 12:26:56 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKV-F9kkvUsp for ; Thu, 22 Sep 2016 12:26:53 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCDF12DA56 for ; Thu, 22 Sep 2016 12:26:53 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id b71so50244719lfg.0 for ; Thu, 22 Sep 2016 12:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vet11LBI3lqudwixskGSeEL3xK3dMGBU9gZPpei3uAI=; b=OA/TwuI46+WphzdX1G56R/pTtyFhMJO9IyhSUeTULLzzV2KNRwtSfqabcCVaffUd+C tY1/XYqfWgJhux7EBALjo1HHEWqDpT4oNmlqiSr8XbH6z1MYGJEnaHFF6krVzpqehvrc p+HCsQPSlTLMvX0hRPKH0mzNM7DodIkW/4zYl8lplghvdCnFDM1W9EzUcFQt1/9O4R3X 263GO7RbahAcFacV7fCWWqr1B2FBqk4ONSCGYRYQYjqTrbEdimhBCZdeQh6d7Xla4JUv TIo2JA0Xa3oUSORSzufqaOAcbtweYBvCT/C/1GUKWMit7WvY4b9eXJ0iaPjZEKe394bm bGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vet11LBI3lqudwixskGSeEL3xK3dMGBU9gZPpei3uAI=; b=ByUXy9f0nllihVnINpQnq8iUWNdLoTnPPpnOOyVnClpdmqPLzu19ZeKLuMdmlx9jy5 vrfMRbX95SsRzuqW3zQT0DmvdVtEzS2o9z++zNFgoLr4JXkmwP7OY0YwIPnpietp7RRl /LuyFyOj0bzalUK3wGMPMUmCVGjGQx/Q8NqELfvBEqzM3vEQ32r0kUsSFvzU6Sbg5ago 0FVsMdSWcAPDrxkzOM/CjsvB5XN/OULIrHA6XYyuETdkeCOFxetJZ6eg3YOwQ3KCN9Jh XjIpbgibLFypjLwPVQWUBeTbSYCDg8xWcnNLidHTfpp402q2D+jI+yPGH/ksB+xY9ksg Egmg== X-Gm-Message-State: AE9vXwN8p5NchH+T4r0HJ/Exb3SrnIbu961scdfQlrcJxzIWIq4MRmsuHqsHZYdQQrgjD8l8It4IcXWtaaiyhw== X-Received: by 10.46.9.87 with SMTP id 84mr1585103ljj.0.1474572411106; Thu, 22 Sep 2016 12:26:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 22 Sep 2016 12:26:10 -0700 (PDT) In-Reply-To: <1474570865.30494.68.camel@infradead.org> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> From: Ted Lemon Date: Thu, 22 Sep 2016 15:26:10 -0400 Message-ID: To: David Woodhouse Content-Type: multipart/alternative; boundary=001a114b0d76c28b08053d1da480 Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Michael Richardson , Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:26:56 -0000 --001a114b0d76c28b08053d1da480 Content-Type: text/plain; charset=UTF-8 Well, here is the reason that I carefully said "not a security expert" earlier. I suspect that PKCS#11 is a better answer than a shim. Thanks for the clue stick! On Thu, Sep 22, 2016 at 3:01 PM, David Woodhouse wrote: > On Thu, 2016-09-22 at 14:24 -0400, Ted Lemon wrote: > > This looks good generally. However, one concern I have about it is > > that we actually really don't want applications to have access to > > private keys. Well, anyway I don't. I want the private key to be > > in an engine where it can't be gotten out by the application, and I > > want the application to provide data for the engine to process: > > cleartext in, ciphertext out. > > This sounds a little bit like the model we were using with TPM(v1). > With the OpenSSL TPM ENGINE, the user 'wraps' a key with the TPM and > gets to keep a PEM file that starts like this: > > -----BEGIN TSS KEY BLOB----- > > Whenever the user wants to use that key, they simply use that PEM file > instead of one of the other multitude of supported formats and it "Just > Works". I had lots of fun making that work for GnuTLS too: > http://git.infradead.org/users/dwmw2/openconnect.git/ > blob/HEAD:/gnutls_tpm.c > > > Is that what you were after? I did consider writing that one down too, > but figured it was a little too esoteric. And perhaps we should have > exposed the TPM via a PKCS#11 provider in the first place anyway. > > > This is a big ask, and I realize that, so I am not saying that this > > document is wrong. But I'm bringing it up because I wonder if > > you've thought about it, and possibly considered specifying this > > operational model as well. Not being a security expert myself, is > > what I am asking for technically unreasonable, or do you just think > > it doesn't need to be scoped in to this work? > > I absolutely agree that applications MUST NOT rely on having access to > the actual private key material. They need to support using opaque keys > from hardware and software tokens. But I was envisaging that PKCS#11 > would be the vehicle for that. > > -- > David Woodhouse Open Source Technology Centre > David.Woodhouse@intel.com Intel Corporation > > --001a114b0d76c28b08053d1da480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, here is the reason that I carefully said "not a= security expert" earlier. =C2=A0 I suspect that PKCS#11 is a better a= nswer than a shim. =C2=A0 Thanks for the clue stick!

On Thu, Sep 22, 2016 at 3:01 PM, D= avid Woodhouse <dwmw2@infradead.org> wrote:
On Thu, 2016-09-22 at 14:24 -0400, Ted= Lemon wrote:
> This looks good generally. =C2=A0 However, one concern I have about it= is
> that we actually really don't want applications to have access to<= br> > private keys. =C2=A0 Well, anyway I don't. =C2=A0 I want the priva= te key to be
> in an engine where it can't be gotten out by the application, and = I
> want the application to provide data for the engine to process:
> cleartext in, ciphertext out.

This sounds a little bit like the model we were using with TPM(v1).<= br> With the OpenSSL TPM ENGINE, the user 'wraps' a key with the TPM an= d
gets to keep a PEM file that starts like this:

-----BEGIN TSS KEY BLOB-----

Whenever the user wants to use that key, they simply use that PEM file
instead of one of the other multitude of supported formats and it "Jus= t
Works". I had lots of fun making that work for GnuTLS too:
http://git.infradead.org= /users/dwmw2/openconnect.git/blob/HEAD:/gnutls_tpm.c


Is that what you were after? I did consider writing that one down too,
but figured it was a little too esoteric. And perhaps we should have
exposed the TPM via a PKCS#11 provider in the first place anyway.

> =C2=A0 This is a big ask, and I realize that, so I am not saying that = this
> document is wrong. =C2=A0 But I'm bringing it up because I wonder = if
> you've thought about it, and possibly considered specifying this > operational model as well. =C2=A0 Not being a security expert myself, = is
> what I am asking for technically unreasonable, or do you just think > it doesn't need to be scoped in to this work?

I absolutely agree that applications MUST NOT rely on having access = to
the actual private key material. They need to support using opaque keys
from hardware and software tokens. But I was envisaging that PKCS#11
would be the vehicle for that.

--
David Woodhouse=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Open Source Technology Centre
David.Woodhouse@intel.com= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Intel Corporation


--001a114b0d76c28b08053d1da480-- From nobody Thu Sep 22 12:35:00 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F4F12BBA3 for ; Thu, 22 Sep 2016 12:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4jupLZgdrIO for ; Thu, 22 Sep 2016 12:34:55 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BFB12B557 for ; Thu, 22 Sep 2016 12:34:55 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn9lm-0000v8-Ee; Thu, 22 Sep 2016 19:34:54 +0000 Message-ID: <1474572892.30494.82.camel@infradead.org> From: David Woodhouse To: Viktor Dukhovni , Security Area Advisory Group Date: Thu, 22 Sep 2016 20:34:52 +0100 In-Reply-To: <36E0AD53-91B2-44EC-AACF-C7BB7E60113D@dukhovni.org> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> <1474563744.45169.105.camel@infradead.org> <1474567710.30494.54.camel@infradead.org> <36E0AD53-91B2-44EC-AACF-C7BB7E60113D@dukhovni.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-4aWGXmaFLcW3d8wlWEQG" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:34:57 -0000 --=-4aWGXmaFLcW3d8wlWEQG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 15:19 -0400, Viktor Dukhovni wrote: > >=20 > > On Sep 22, 2016, at 2:08 PM, David Woodhouse wrot= e: > >=20 > >=20 > > OK, then I concede the point. Single-DES and MD5 were a *perfectly* > > acceptable default in 2010, and nobody could have predicted that they > > would be considered obsolete within the lifetime of the OpenSSL 1.0.x > > series. Neither would anyone consider it a bug that Single-DES and MD5 > > are being employed by default in 2016. > >=20 > > :) > >=20 > > (And to be fair, who uses 'openssl pkcs8 -topk8' anyway? It's not like > > this is in the output of 'openssl req -new' or stuff like that. That > > one is at least AES128 in OpenSSL 1.0.2 isn't it?) > Sarcasm bordering on trolling is fun, for real excitement hop into > your handy back-yard time-machine, go back to 2010, donate your copious > spare time (hey you've got a time-machine) to OpenSSL and get it fixed! >=20 > :-) :-) I know, I'm only playing because you are. I wasn't *actually* complaining about the DES-MD5 thing in the first place, just saying that we need to support it. Hell, I live in a world where we have corporate blessing to store VPN private keys encrypted with a passphrase which is the UUID of the file system on which they are stored =E2=80=94 on the basis that this is equival= ent to the security provided by the 'export prevented' bit in the Windows certificate store. That is, it'll hold up a na=C3=AFve user who just wants to copy a cert from one machine to another, for at least 30 seconds. And that's long enough to make them want to follow the policy and get a *new* cert for their second machine. And software happily supports keys which are completely unencrypted, and there are reasons why that's OK. So honestly, I have no problem with DES-MD5. I merely presented it as the other end of the spectrum to the HMAC-SHA256 example, to show the range of what is *still* being created. But once you started trying to justify it, I *had* to take the bait :) As for 2010, I was too busy trying to get AES-NI support working in that timeframe, IIRC, and needed my time machine to get it submitted *before* the feature freeze... --=20 dwmw2 --=-4aWGXmaFLcW3d8wlWEQG Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTkzNDUyWjAvBgkqhkiG9w0BCQQxIgQgnm13N/nfWrv/VQ4F3qWeTMJBEeX1HBtaTH3E 1JR0wzswgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAGKj wMZqc2LQe78plpGeXgmhAazDRU/y2xENxZl77A1HsT1ngxftR0H4hDtd5CftP2aOTdwDfZyWVJD+ GPtJlA1qE8zVOWlVO3TeXjPpXdzZMwjjtnY2ufh2yame/TPtbwVos/lpEQtKUge47MpytO7BtEs1 vAdYGndUP1fLrHh+D07HO1OYG5vUY7W9YNnmBx0KzqtgXxp1FLm5/ww+J69UxZWA1m76j09CDX4/ IWwwPOb7twFwECCRenLRxgFvzjBAdADydbWrnGdLB8oy3usTM8IyPy1N1OkL/Bpj6YKNK4rl8AI1 rKY/DoR+aTK0kVUQlVZ1o+iNmyBRzOuJu6qTEA5oXvcp/WGx+SFI3vaMH/kZZ18Zkb4Fpjft+Bej dmApR3v4iAvuenm5lU1v5yCjnOQqFfTEImjvoQ4Da42wjhS6MOXkpTeDXmNjlKdY+s1K6y1h1HPU u1e8tEm7U2WbOCUvZILXaYUjgWu+Qe9kjiTIhOopYQwFjmdvZnHHkmlZCpUQXEWrFqUS3HbX6RAw QNSKU8IR/oZvmIIdn9s56UiEW8In5jTDJEowBkxP28u5C8QvZvB8HSmVY94AYWU1PBt+GM/TpPzM CqCpD3Aap9X1j3TmIK/y+2AwwPFTeOYAOGwZeG3TfpeM3MGm03rLHjVCAQiUFkn0ih+w28R0AAAA AAAA --=-4aWGXmaFLcW3d8wlWEQG-- From nobody Thu Sep 22 12:45:39 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B5A12B5FF for ; Thu, 22 Sep 2016 12:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJqpXRV5wd4F for ; Thu, 22 Sep 2016 12:45:35 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 672BA12B5BA for ; Thu, 22 Sep 2016 12:45:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id B618E1F0B; Thu, 22 Sep 2016 19:45:33 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q6xSQFaORxY; Thu, 22 Sep 2016 19:45:33 +0000 (UTC) Received: from [192.168.120.42] (unknown [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 3334E1EA6; Thu, 22 Sep 2016 19:45:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <1474567710.30494.54.camel@infradead.org> Date: Thu, 22 Sep 2016 15:45:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <152D43CC-EC2D-4A5A-90BC-821A75EB5417@deployingradius.com> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> <1474563744.45169.105.camel@infradead.org> <1474567710.30494.54.camel@infradead.org> To: David Woodhouse X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:45:37 -0000 On Sep 22, 2016, at 2:08 PM, David Woodhouse = wrote: > OK, then I concede the point. Single-DES and MD5 were a *perfectly* > acceptable default in 2010,=20 http://www.oreilly.com/pub/pr/584 Project leader John Gilmore remarked, "If a civil liberties group can = build a DES Cracker for less than $250,000, practically anyone else can = too." That's from 1998. Hugh Daniels showed me one of the cards from the machines in 2006. It = was old even then. Alan DeKok. From nobody Thu Sep 22 12:47:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C02112B971; Thu, 22 Sep 2016 12:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2Tv_dzV81E4; Thu, 22 Sep 2016 12:47:00 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4627012B93B; Thu, 22 Sep 2016 12:47:00 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bn9xT-00065n-8g; Thu, 22 Sep 2016 19:46:59 +0000 Message-ID: <1474573616.30494.90.camel@infradead.org> From: David Woodhouse To: Ted Lemon Date: Thu, 22 Sep 2016 20:46:56 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <1474570865.30494.68.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-0SAm96cGgOiQR0fpAe8j" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Nikos Mavrogiannopoulos , "spasm@ietf.org" , Security Area Advisory Group , Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:47:02 -0000 --=-0SAm96cGgOiQR0fpAe8j Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 15:26 -0400, Ted Lemon wrote: > Well, here is the reason that I carefully said "not a security > expert" earlier. =C2=A0 I suspect that PKCS#11 is a better answer than a > shim. =C2=A0 Thanks for the clue stick! FWIW if you want to put the key beyond copying by normal users, for many purposes you can do that right now on a Linux system. See https://bugzilla.gnome.org/show_bug.cgi?id=3D704866#c9=C2=A0(and #c10) The example there is the OpenConnect VPN client, but on Fedora if you find *any* application which would accept a certificate in a file and doesn't accept a RFC7512 PKCS#11 URI, please file a bug and Cc me. Because although I'm only now working on this I-D, that much *is* already part of the Fedora packaging guidelines. And if you're not on Linux or something similar... and if you're not on Windows or OSX which have their own keystores which at least *pretend* to prevent the kind of export you're talking about, then what platform *are* you thinking of? :) --=20 dwmw2 --=-0SAm96cGgOiQR0fpAe8j Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTk0NjU2WjAvBgkqhkiG9w0BCQQxIgQgAaZ3T9nAd9MKrFlmEyg15rRzhcks537QnFoU jneeZoQwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAFz2 94ibVoFuH9PwPTn9nejiOuIxJ6xPSTtRkRxOlpyOoUk0Jz6Hglo+jyHtd4dOkJUZbI7GGZiJKCmz f3AOKrg65qnyVFzY73TuDzFLkr5yHzlTAjvU/uKiC/HvtbSjouOzUSs+g93nxszg1AmCg6QFOE0U oWd46304sN+znOKYefCxhaRw/xgscESkvpBXoydLkVLIiMVWQr5hk+pwavwCbXmRur5xTPAEPEyK QrX3c1vMEW0a/CtjvnoyBUtAJf5CVgqVZJhKGdlf8GXJQn2FE4wMJgPIfx+E61rBGZieBQJ1Tw5L Zf3RWUFXIWOXFATWYgTGLmVRM6Og2v1elKoajOFsv6igOJ9Jgw7Mwdo0GLyXEmDC2zFpzN83YFHc hKMyCZE6wt9et3PawdZDhf2mkQcXvIPHk9XHryXQa6b/GPiUV5g5wwHw3aaGVz12XhB1z2G25lwT IK8DfYPdVG5JgufHILxHh/h97txGmtPs/2SITXMXldxPCczMGodwJOOUqB6dGR5Hj6LFDzcsg0I2 vochBj1aRjJJfI/ZLGfn8TRzMlDRS1U4MwHILV2kGH1PUD+l3UqIaIXbh5wqmHESHSr0+2GB0v9q hzNClFAAVmIC2IZ0nDrMly5KAqqGEADCNbE8qKtPYoWLr5wZuQsOry9HCEKRamdkOt1LPFtRAAAA AAAA --=-0SAm96cGgOiQR0fpAe8j-- From nobody Thu Sep 22 12:56:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43512B442 for ; Thu, 22 Sep 2016 12:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCGcwn_9ECQO for ; Thu, 22 Sep 2016 12:55:51 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E5912B3B9 for ; Thu, 22 Sep 2016 12:55:49 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bnA5z-0001RL-RO; Thu, 22 Sep 2016 19:55:48 +0000 Message-ID: <1474574145.30494.96.camel@infradead.org> From: David Woodhouse To: Alan DeKok Date: Thu, 22 Sep 2016 20:55:45 +0100 In-Reply-To: <152D43CC-EC2D-4A5A-90BC-821A75EB5417@deployingradius.com> References: <22611.1474382971@obiwan.sandelman.ca> <1474387066.144982.443.camel@infradead.org> <1474470703731.18547@cs.auckland.ac.nz> <1474495074.30494.21.camel@infradead.org> <1474520671777.43424@cs.auckland.ac.nz> <1474540039.45169.62.camel@infradead.org> <881A4E2D-82C6-46B4-8A48-2FB1E3604E70@deployingradius.com> <1474560485.45169.92.camel@infradead.org> <20160922161728.GC4670@mournblade.imrryr.org> <1474561736.45169.100.camel@infradead.org> <20160922164924.GD4670@mournblade.imrryr.org> <1474563744.45169.105.camel@infradead.org> <1474567710.30494.54.camel@infradead.org> <152D43CC-EC2D-4A5A-90BC-821A75EB5417@deployingradius.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-82za4KSX7stRsJkTrOCY" X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 19:55:53 -0000 --=-82za4KSX7stRsJkTrOCY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-09-22 at 15:45 -0400, Alan DeKok wrote: > On Sep 22, 2016, at 2:08 PM, David Woodhouse > wrote: > > OK, then I concede the point. Single-DES and MD5 were a *perfectly* > > acceptable default in 2010,=C2=A0 >=20 > http://www.oreilly.com/pub/pr/584 Alright, *all done* teasing Viktor about Single-DES. :) That *really* wasn't my point in mentioning it. --=20 dwmw2 --=-82za4KSX7stRsJkTrOCY Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIyMTk1NTQ1WjAvBgkqhkiG9w0BCQQxIgQgRUS7l7+hbC9eHsrI5IgA5yBFS0FRzuOTBU1D o7T7AqQwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAJU0 KrAhQZUqAo6Qu7uigi2284uzYeFyXisl0xmZRdxcA1MwbbYWW+T/XKXzvjblDKDLJStqCPLtI549 VRGirkDLEN9XvhYxOi6BI5biEzgEmvgSibb74eBUG4vLwwxkXAMdc4rfN4Mc7jqShwxWCi9i1e4Y 5FNUZLSdZBK/4IkUq6QelKTM5cVyoakGctpRXCXHGl9q6XQ+07Kz6on1sBPmmeEiHAnTqu//A2dI V+DzncfRehNdY1Jv1jANeIZc5cUO10Erf2RDucZP1oy+MfPbyAsh99jpUB7J+b+wOVf/6X+L/mWe pbhBwP+queKbDltOUiY1IidfbjnDQHuOqOYS4ALAIyqMkQS/4opN/8naABPl3GO4wHPxI2kptUr5 0VQXlc/8ry6XN+CTtY0FnGsyeC+ifb03mKoNsn+Rk3aU91whTM9yBBRBmWSPVR6HRczp/lebtqk+ QuyR6fdNdeG1chtKireAWbsJgzLOtpLzf84vxzLvEoQi7UzlPE7C0pnVFzX+4FmL3UFAEnh5fDXA fAfsKoEyAbz+KxIcIK+pdPPbi95frmC1iv472pFrVkkm7q03iJ7cx+KhNqRCNhrACxPJ2oxjMCR6 nLVQhuxzQSNaz6IDtcHgKRBps4Gz8zJ5pUTUnD44+Ko9uChBfHLDwWPtY9/VSPLSe5djiAI9AAAA AAAA --=-82za4KSX7stRsJkTrOCY-- From nobody Fri Sep 23 02:58:25 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EDE12B3AA for ; Fri, 23 Sep 2016 02:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9ei2wZWIkGh for ; Fri, 23 Sep 2016 02:58:22 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C148A12BE8E for ; Fri, 23 Sep 2016 02:58:21 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id q42so32114457uaq.1 for ; Fri, 23 Sep 2016 02:58:21 -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; bh=ST9bursMja4sg86t7k1sa1PAw3anW7jALUZteinZ5eY=; b=MlY9T4VuNEGnAYt3jx67Vc2t8ieRUIwKrVd1N8nuPgnG8w+KlxH3ZiEa+EwonVciJQ IqfAa0wpwCUr2WZh4AmPZOg7K5pzOgctWnouUc4+KdvNJy0x2ceHCFO/2nUD7zCMyjzJ WzRylt301t4mxPEa7LrlyBjZxY/A2SUJYZ6BHaBGddNHYiB5KNl+s6rL5bINyBAxGZWr cK68FQqMzRFYaNfYLn9NqSn4DV2XjYdLltlHwvUVXIXEqLotTI0H5sARIJZBnMAJD8u1 BV0hNny9xdySvLL0iT8PL32eCDRyR1H/C4jOYB32W1pRjKsehtbATIHHxReqdzOAQwau /xjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ST9bursMja4sg86t7k1sa1PAw3anW7jALUZteinZ5eY=; b=CP/cZ6gH3Cq73fkqICEktcTnFtkV7e2C4XGAnwZYcPaavtUTVDSWr/C43FjYZeF5m1 96a8TpcO8wVTgXW46io4bi06J6Mh47ETInzGatldiKpbQjL4w+43JMBDRySKRKAxMzzl vSVJTHJ2kAIAca8KRREsxCpOzO/keliXbDElbsqtgWbSCq2F82HfGkqOzKDhyH4XQp/K AemmDVzseNvFm4KNEK3QgxaIiyn76531aBlDRsk7NLRhJ830sx+aHR1Bit0ZMY2zXYZT M3gUgPSJsVl5RIXJ2CeAmoITtitQr5XZzv+OyQgUz2El+SVv/94OshHBZk70FbH6JUtC 8Vyw== X-Gm-Message-State: AA6/9Rlq2VebEjHC1a70MR2EJOph0bKWSjym7zr40HChRV1YvwcZVO76fnMzRuqNVeBsksOYnMOqRriJwIEwUQ== X-Received: by 10.176.0.139 with SMTP id 11mr3635445uaj.28.1474624700779; Fri, 23 Sep 2016 02:58:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.118.4 with HTTP; Fri, 23 Sep 2016 02:57:40 -0700 (PDT) From: Nikos Mavrogiannopoulos Date: Fri, 23 Sep 2016 11:57:40 +0200 Message-ID: To: IETF SAAG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [saag] openconnect (ssl) vpn protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 09:58:23 -0000 Hi, The last few weeks together with David Woodhouse have improved the openconnect VPN protocol quite significantly and eliminated any legacy constructs arising from the pre-DTLS era, and pre-TLS-PSK era. Even though it still provides backwards compatibility with the cisco's anyconnect protocol, it has been greatly simplified, making it one of the simplest SSL VPN protocols I'm aware of. It is described at: https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00 We would appreciate any feedback on the protocol and approach. regards, Nikos From BATV+12ba29f4eaba1644bf7a+4779+infradead.org+dwmw2@bombadil.srs.infradead.org Fri Sep 23 03:04:35 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42C812B4DA for ; Fri, 23 Sep 2016 03:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnjg6Z4XLvG3 for ; Fri, 23 Sep 2016 03:04:34 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD4412B306 for ; Fri, 23 Sep 2016 03:04:34 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bnNLN-0001Wv-On; Fri, 23 Sep 2016 10:04:34 +0000 Message-ID: <1474625071.45169.131.camel@infradead.org> From: David Woodhouse To: Nikos Mavrogiannopoulos , IETF SAAG Date: Fri, 23 Sep 2016 11:04:31 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-dEeVds7Drv2aSjdS3Qr6" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [saag] openconnect (ssl) vpn protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2016 10:07:06 -0000 --=-dEeVds7Drv2aSjdS3Qr6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-09-23 at 11:57 +0200, Nikos Mavrogiannopoulos wrote: > Hi, > The last few weeks together with David Woodhouse have improved the > openconnect VPN protocol quite significantly and eliminated any legacy > constructs arising from the pre-DTLS era, and pre-TLS-PSK era. Even > though it still provides backwards compatibility with the cisco's > anyconnect protocol, it has been greatly simplified, making it one of > the simplest SSL VPN protocols I'm aware of. It is described at: > https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00 >=20 > We would appreciate any feedback on the protocol and approach. Did I catch a suggestion that using PSK in (D)TLSv1.3 is going to require us to pre-agree a hash algorithm for the hello_finished? --=20 dwmw2 --=-dEeVds7Drv2aSjdS3Qr6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTIzMTAwNDMxWjAvBgkqhkiG9w0BCQQxIgQg+W2C11uSRwpBnHPv1ZtQ0TQGOKzUTKprYtev fRg0DQgwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICACeM c6VTCrzi5CgzABoNbwhbAUtQdesgMfik4NoOIuLKwn101s5EZ8hV7KVpjGQRN35WQYnQwq+0N/sr ew9fLthH8lT7yZ07BBfhtQVvkzxQI1SrOXZ8WeM5cX/CaTPMGtKoRLfQn/fR85B85GTTdKwwuc5N 0xj4Q3TYHW8sTub4SIFokr+J4mcX/aSCVvJrhZ9UX1eEOvDetMyR1+vEIzybEQvSsja68vIkMDLp v+hJNnHewMv2rgwGTIZmLtULD5Zq1ml/Uyr3FZvw1JKxB+7rkHOSQHTtSqqpkadkzeIQNdNASlMO D9O+jyVwL7guYD3/Mu0Rmpdd79YboxS/unCn/6iRTR8LQlZIcCqp8HX+dr+lKVFU/eGAjS527DPB dpKvx6226DusLyjK3yCvK3Sih39/4ku/k7fQ45Q8ABaGBTh+7IkpLxKtEHq54MxBv7x4TRflx2c6 gMzcdWVXsdzDLPR6dIOCfsNxLXaFbMt3jdvydOgcaQ/StnSHWv4E7IdkaDQrQ4gB/gNxxNWv6j+B lBpI69VU/N1ceNRfu+qcPwDfi/W8LMMbOjPYuRKH9mQq5CxlDItlqgGjrcMANadrcQs3xkUFAjRz diB2IJCvDqL+XvMVXaqGHxueWD10veYjrPVv4guuxPrjSYyc7dVkbqMlUeuBtjfIVuOt4tjSAAAA AAAA --=-dEeVds7Drv2aSjdS3Qr6-- From nobody Sun Sep 25 18:49:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAD12B062; Sun, 25 Sep 2016 18:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oPt1DxWeTMt; Sun, 25 Sep 2016 18:49:05 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59B512B05D; Sun, 25 Sep 2016 18:49:04 -0700 (PDT) Received: from [10.59.2.102] (unknown [206.214.36.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A2D150A73; Sun, 25 Sep 2016 21:49:01 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Leonard In-Reply-To: <1474387598.144982.452.camel@infradead.org> Date: Sun, 25 Sep 2016 18:48:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 01:49:07 -0000 > On Sep 20, 2016, at 9:06 AM, David Woodhouse = wrote: >=20 > My goal is that > we should be able to refer to certificates in a simple consistent way. >=20 > If the certificate is in a system store then applications should allow > it to be used by means of a consistent identifier string (which is > defined by RFC7512 for PKCS#11, and may be different for OSX/Windows > system certificate stores). >=20 > If the certificate is in a file, obviously the identifier is the > filename... but we need to fix applications so that they actually > *accept* all types of files. Which as I said, none of them do at the > moment. Hello David: draft-seantek-certspec =E2=80=9CTextual Specification for = Certificates=E2=80=9D is exactly what you=E2=80=99re looking for. https://tools.ietf.org/html/draft-seantek-certspec-09 That is for certificates. And yes, it handles pkcs11 just like = everything else. It also has an algorithm for automatically detecting = textual encoding (RFC 7468) vs. DER encoding. Discussions about PKCS #12 = issues were added to recent drafts. *** Private keys are another matter. The approach could easily be extended = to handle private keys. They are just identifiers, after all. However, = by definition secure private keys are a =E2=80=9Clocal matter=E2=80=9D. = I do not see the value of standardizing an identifier for private keying = materials when the implementations are all different and are not = supposed to communicate with each other. You can, of course, always = refer to a private key indirectly, by referencing an associated = certificate. It is very plausible to identify a certificate stored in a = local file (that does not need to be encrypted), and then to look up the = associated private key on a token that has a lot more protection around = the key, by using the certificate or its metadata as the dbkey/index. [The aforementioned paragraph is also responsive to Ted Lemon=E2=80=99s = concern: =E2=80=9Cone concern I have about it is that we actually really = don't want applications to have access to private keys.=E2=80=9D] Regards, Sean From BATV+421cd2077d379962b7d4+4782+infradead.org+dwmw2@bombadil.srs.infradead.org Mon Sep 26 02:17:37 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5286712B071; Mon, 26 Sep 2016 02:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARArsZJvO1GS; Mon, 26 Sep 2016 02:17:35 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497E612B0A6; Mon, 26 Sep 2016 02:17:35 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1boS2V-0003a3-03; Mon, 26 Sep 2016 09:17:31 +0000 Message-ID: <1474881447.45169.205.camel@infradead.org> From: David Woodhouse To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group Date: Mon, 26 Sep 2016 10:17:27 +0100 In-Reply-To: <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-OLXiXaPVXHHam9n3Gfbx" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 09:28:35 -0000 --=-OLXiXaPVXHHam9n3Gfbx Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2016-09-25 at 18:48 -0700, Sean Leonard wrote: > Hello David: >=20 > draft-seantek-certspec =E2=80=9CTextual Specification for Certificates=E2= =80=9D is > exactly what you=E2=80=99re looking for. >=20 > https://tools.ietf.org/html/draft-seantek-certspec-09 Thanks; that's very interesting. I'm not sure it covers exactly the same use case, but it's very closely related. > That is for certificates. And yes, it handles pkcs11 just like > everything else.=20 ... but not like RFC7512 does, I note. Is it worth trying to achieve some better consistency there? After all, I can *already* refer to the certificate in my crypto token consistently as=C2=A0 'pkcs11:manufacturer=3Dpiv_II;id=3D%01' in a variety of applications using different crypto libraries. And in fact on my operating system of choice I can file a bug for any application which *doesn't* accept that string, when it would have taken a filename. So I'd definitely like to see your draft make explicit reference to RFC7512 in some form or other. > *** >=20 > Private keys are another matter. The approach could easily be > extended to handle private keys. They are just identifiers, after > all. However, by definition secure private keys are a =E2=80=9Clocal matt= er=E2=80=9D. > I do not see the value of standardizing an identifier for private > keying materials when the implementations are all different and are > not supposed to communicate with each other.=20 Ah, but that is *precisely* the matter I was most concerned about. It's not so much about implementations communicating with each other; it's about consistency and (hence) usability. Not very long ago, in order to use that key in the crypto token I mentioned above, I had to do something *different* for fairly much every application: =C2=A0=E2=80=A2 for OpenVPN, I had to manually specifier the PKCS#11 provid= er =C2=A0 =C2=A0module and use one form of identifier string. =C2=A0=E2=80=A2 for OpenConnect, RFC7512 identifiers Just Worked, and it us= ed =C2=A0 =C2=A0the PKCS#11 providers indicated by the system configuration. (= Yay!) =C2=A0=E2=80=A2 for Curl (if built with NSS) I needed to manually edit conf= iguration =C2=A0 =C2=A0files to make it load the right module, and then refer to the =C2=A0 =C2=A0object by a *third* form of identifier string. =C2=A0=E2=80=A2 for wpa_supplicant I had to manually configure it to use an= OpenSSL =C2=A0 =C2=A0"Engine", specify the provider in yet *another* different mann= er =C2=A0 =C2=A0because that also ignored the system configuration, and then g= ive =C2=A0 =C2=A0the certificate ID in a *fourth* different form. And that was just for the applications which *could* use PKCS#11. Many just couldn't do it at all. And for some, they needed to be configured differently depending on which crypto library they'd been built against. It made me kind of sad. FWIW I have all of the above just taking PKCS#11 URIs according to RFC7512 now, without any of the additional configuration nonsense like loading engines and specifying provider modules. Now, *part* of that is addressed by your draft (although it's already addressed by RFC7512 in the case of PKCS#11, and the conflicts there want resolving). But other parts are not =E2=80=94 and I'm not sure you rea= lly want to expand your scope to cover them. They include: =C2=A0=E2=80=A2 Using the system configuration for which PKCS#11 providers = to load. =C2=A0=E2=80=A2 The search algorithm, identifying when to log in to a token= to =C2=A0 =C2=A0attempt to find a certificate with CKA_PRIVATE and how to loca= te =C2=A0 =C2=A0the key corresponding to a given certificate, etc. =C2=A0=E2=80=A2 The requirement that opaque private keys without access to = the =C2=A0 =C2=A0corresponding public key SHALL work. That's just for PKCS#11. of course. For files there are a different set of issues =E2=80=94 mostly the fact that every application on the system wi= ll currently support a *different* subset of private key file formats. So a user with a certificate+key provisioned through her organisation's proprietary scripting will find that it works with *some* applications and not others, for reasons which are entirely intractable, such as: =C2=A0=E2=80=A2 It uses the non-standard OpenSSL 'encrypted PEM' format. =C2=A0=E2=80=A2 It uses a SHA256 HMAC which isn't universally supported. =C2=A0=E2=80=A2 It is encrypted with DES-MD5, which isn't universally suppo= rted. =C2=A0=E2=80=A2 It is in DER form, which applications need to jump through = hoops =C2=A0 =C2=A0to cope with loading because crypto libraries hate us all. The idea of my draft is to give a set of "best practice" guidelines for applications so that the user *can* just use the same certificate and key with any well-behaved application, with exactly the same identifier, and it will Just Work. It's not *just* about the identifier though, and in fact I've mostly tried to make it *not* about the identifier. I just defer to RFC7512 and obviously to filenames. For the system certificate stores I just say that if a convention exists, it should be supported =E2=80=94 and it so= unds like your draft would be the ideal solution to fill that gap. So while there is certainly an overlap with your draft, there's also a lot to cope with that *isn't* already the primary target of your draft. If you want, I'm happy to work with you to *make* your draft cover this. But I suspect there would be sufficient conflict in our use cases that it's best just to ensure that they complement each other to achieve their respective goals. What do you think? For reference, the current version of my nascent draft is at http://david.woodhou.se/draft-woodhouse-cert-best-practice.html=C2=A0and it's also at=C2=A0https://github.com/dwmw2/ietf-cert-best-practice > You can, of course, always refer to a private key indirectly, by > referencing an associated certificate. It is very plausible to > identify a certificate stored in a local file (that does not need to > be encrypted), and then to look up the associated private key on a > token that has a lot more protection around the key, by using the > certificate or its metadata as the dbkey/index. Yes, there is lots of fun to be had here. Lots of reasonable heuristics for how to find a key given the certificates =E2=80=94 and thus lots of sco= pe for applications to be inconsistent and for users to complain "it works in XXX, so why doesn't exactly the same cert work in YYY?". I've attempted to address this with the search algorithm for PKCS#11. For files there's not a lot you can do although I do mention that if the cert has extension '.crt' and doesn't actually contain the private key, you might look for a corresponding file with extension 'key'. There are probably more improvements that can be made in this area, especially when it comes to the system stores on Windows and OSX. > [The aforementioned paragraph is also responsive to Ted Lemon=E2=80=99s > concern: =E2=80=9Cone concern I have about it is that we actually really > don't want applications to have access to private keys.=E2=80=9D] Yes, we absolutely need to support and encourage that use case. That is part of my motivation for pushing to have PKCS#11 supported consistently across applications on platforms where that's the best answer. --=20 dwmw2 --=-OLXiXaPVXHHam9n3Gfbx Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTI2MDkxNzI4WjAvBgkqhkiG9w0BCQQxIgQgvCAszmscVHMTXribTsWp7JlIOmXpvjd3AQjF /2tYGaAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAF7R yop4jrnLzz1kQmPMBcok03z6D6UBVhalcxqnK1XSc4e6ILcrKZihY9QsJ2B4N7WovMvGx0/kj/Yo 7xxiv2ebj1ZPO8WPzQstlwlBBB5kvKjVc0sidWS+ww5NVoF3V0dpedztyNA6MJdlx8YyMqVS5sCN nm3eRP+vhJ/goBdHoTNHTBzX1s+PCqmJkW67lqmyprMlIVpFOjo6Qkrol98Ynv+P2udTUpVC6GyZ M+ynWsW533e5f3CAuT+2oyVx8D8nzcSln2VBppyNTDY81lzk6o8Q7MkQRcEHGAoTiNCOBuxzECWx fixrhdXq9+RuPCO0W4ZUSWV81abEzSz6k8XfIC3DaTeCMnzKZrGMdoZNC9+KjpldNt0zseIvj0d8 DuWOX1rteH4mdFnGtWm2l57Fn49eUrMg7TE2ylb9cH9cB0t1EnKDPBXNLIvsoFP9SSasqsLY1yIJ n2tv7iBZrIXTFKj0USzUm3P6/c+hHmS7+rSbERh11CIQ3nKuuPp5T2PAkDDiZggBEGTj4qsTB/Ui RVJK6QtQe2k89oJXri5yKigkzPqWEStFx+A7hW0Y3Y9ZaHdhoLFypHmlfGBWevQ6YqAADB0D30aL 3FzS7wCtYQLVG1FqxcRDRNgMAG+Ay91AQOyCa4cafMhdJ0oTcoSeyNF0fBmkxyW6EBM8+8VCAAAA AAAA --=-OLXiXaPVXHHam9n3Gfbx-- From nobody Mon Sep 26 07:52:29 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38E312B21E for ; Mon, 26 Sep 2016 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1E-ZPWBkqLES for ; Mon, 26 Sep 2016 07:52:24 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B1312B2AB for ; Mon, 26 Sep 2016 07:52:23 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id 11so82018943qtc.0 for ; Mon, 26 Sep 2016 07:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=VU9z1nA9tJp+JrTZ1Jd9oUZ96AI50pbrrHbF1d53KKk=; b=EJU2zaIIofR1XqkERxngoKYQeq7JhuQ/xWaSPGkQBaGaG9fTMNh5Tgo3cZ7F90Am3b 2c/psUxZ/K5gdtgdw6XiucnW/1XeDyCk0tnY4LvnnBrCgeQmHrME/KiyayOpa9hEpWP/ lcWcS0EtpuI1HPHJKrkkkH+G8+xVsCBOtMoAmY4jhaALaca2eTM0nxhxtRzyN1yM41m6 iGmKRuxR0IIzXEksGQs0zeKq3HOQq/YifcE5Dbqb1Ovt8Dxkm1T5twqWz9qmyT59J0T2 QGslHepv0t+pkYQlSEjilm5CQGGm1R4ntnTSciTuUSrQO8waDBxSM7Z9D3vR5EY9m4/l dpOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=VU9z1nA9tJp+JrTZ1Jd9oUZ96AI50pbrrHbF1d53KKk=; b=ahg78RnaAiBxutWJX69s9vUnH4YkBaeUqfwqSir+4g/pMINPVsHqZxZRyln0Ttnc51 M2qTDiqqgy2DBvOQcg8G43Xt82rPePBwutXyiuGwloKLhauXAfEavzIefdd6cio2wdNq p3I6ItH7ihwWHtodoZj849jIV0ebyi5L6GcZJFqLRIohdFShLrrvNaA3iXkoNjTWfjuy pvShw4CshfmlQWR2qPbdNtOI2EUuT1CIvILgwFs85KqYVBSDER5AVPFC6EmT9AwhWfN0 qdVHOyyD210lNcxmZxWAUWJgMk5waeVmgq/0pYV1IM/B1rBH9U97uvv+5ADYBXlA7UxJ XUsw== X-Gm-Message-State: AA6/9RlJixMlX+hesT6tknQeny+DvSnwu7TrKAlGUj5u1yWPB2gePknJhRsuc7BGXmOyocbjiXUQpp/vyWr4yQ== X-Received: by 10.200.54.106 with SMTP id n39mr21563674qtb.50.1474901542673; Mon, 26 Sep 2016 07:52:22 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Mon, 26 Sep 2016 07:52:22 -0700 (PDT) From: Phillip Hallam-Baker Date: Mon, 26 Sep 2016 10:52:22 -0400 X-Google-Sender-Auth: Wa8EGx7LMo4lWaKE-nk_6ttqhac Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary=001a1135a0e087a522053d6a4667 Archived-At: Subject: [saag] Need vendor support to address a malware vector X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 14:52:27 -0000 --001a1135a0e087a522053d6a4667 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BI have been doing some poking around this morning and I think I ha= ve uncovered a major vector for distribution of malware - Minecraft mods. This is a totally logical way to distribute malware. The kids don't know what to expect and will click on anything to get their skin, mod whatever. Most of the sites require the user to install a 'download assistant' of some sort. These are invariably larded with malware. In many cases so are the sites. We need to fix this. It is a problem. One short term fix is to blacklist the various modding sites but that is not going to do any good. Microsoft paid $2.5 billion for Minecraft. I think that means they can afford to give free hosting to the entire modding community to get rid of the problem in the Minecraft world. Oh and I am going to be at a policy forum lunch with a Microsoft SVP in a couple of weeks so consider this a heads up for the pressure I am about to create. But this is a problem that is bound to affect pretty much every similar community. So while we can make this particular problem the property of one vendor, Google, Facebook, Apple and the rest can't ignore the issue. We have to have a community effort on this. --001a1135a0e087a522053d6a4667 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2= =80=8BI have been doing some poking around this morning and I think I have = uncovered a major vector for distribution of malware - Minecraft mods.

This is a totally logical way= to distribute malware. The kids don't know what to expect and will cli= ck on anything to get their skin, mod whatever.

Most of the sites require the user to install a '= ;download assistant' of some sort. These are invariably larded with mal= ware. In many cases so are the sites.


We need to fix this. It is a problem.

One short term fix is to blacklist the various modding site= s but that is not going to do any good.

Microsoft paid $2.5 billion for Minecraft. I think that mean= s they can afford to give free hosting to the entire modding community to g= et rid of the problem in the Minecraft world. Oh and I am going to be at a = policy forum lunch with a Microsoft SVP in a couple of weeks so consider th= is a heads up for the pressure I am about to create.


But this is a problem that is bound to affect pretty much= every similar community. So while we can make this particular problem the = property of one vendor, Google, Facebook, Apple and the rest can't igno= re the issue.
<= br>
We have to = have a community effort on this.=C2=A0
--001a1135a0e087a522053d6a4667-- From nobody Mon Sep 26 08:22:41 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2543012B29F for ; Mon, 26 Sep 2016 08:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.215 X-Spam-Level: X-Spam-Status: No, score=-9.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAE9L7G5cC3p for ; Mon, 26 Sep 2016 08:22:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C0012B23A for ; Mon, 26 Sep 2016 08:22:38 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u8QFMD4B008130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Sep 2016 08:22:14 -0700 (PDT) To: Phillip Hallam-Baker , "saag@ietf.org" References: From: Joe Touch Message-ID: Date: Mon, 26 Sep 2016 08:22:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------446F01D610F71579FF6CF757" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [saag] Need vendor support to address a malware vector X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 15:22:40 -0000 This is a multi-part message in MIME format. --------------446F01D610F71579FF6CF757 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 9/26/2016 7:52 AM, Phillip Hallam-Baker wrote: > ​ I have been doing some poking around this morning and I think I have > uncovered a major vector for distribution of malware - Minecraft mods. ... > Microsoft paid $2.5 billion for Minecraft. ... > But this is a problem that is bound to affect pretty much every > similar community. So while we can make this particular problem the > property of one vendor, Google, Facebook, Apple and the rest can't > ignore the issue. > > We have to have a community effort on this. I disagree that the community needs to provide free resources to Microsoft to ensure the health and profitability of their product. Microsoft needs to ante-up. That's true for every vendor with a product that needs such a solution. I appreciate your goal of finding either a technology or community approach that helps vendors do this - and that we as users will benefit, but IMO any solution needs to start with "pay-for-support". Joe --------------446F01D610F71579FF6CF757 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit



On 9/26/2016 7:52 AM, Phillip Hallam-Baker wrote:
​ I have been doing some poking around this morning and I think I have uncovered a major vector for distribution of malware - Minecraft mods.
...
Microsoft paid $2.5 billion for Minecraft.
...
But this is a problem that is bound to affect pretty much every similar community. So while we can make this particular problem the property of one vendor, Google, Facebook, Apple and the rest can't ignore the issue.

We have to have a community effort on this.
I disagree that the community needs to provide free resources to Microsoft to ensure the health and profitability of their product. Microsoft needs to ante-up.

That's true for every vendor with a product that needs such a solution.

I appreciate your goal of finding either a technology or community approach that helps vendors do this - and that we as users will benefit, but IMO any solution needs to start with "pay-for-support".

Joe
--------------446F01D610F71579FF6CF757-- From nobody Mon Sep 26 11:59:21 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DC512B010 for ; Mon, 26 Sep 2016 11:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivb6IiZAu5bD for ; Mon, 26 Sep 2016 11:59:16 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4DF912B2E1 for ; Mon, 26 Sep 2016 11:59:14 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id g67so116209506qkd.0 for ; Mon, 26 Sep 2016 11:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=VdlyKL1FdXgTmzTRlGLV6WDTsRCqML/2O/uxVlNBeDI=; b=gbikc+rOv/v7AucMBeQ/VMrqqXOv0qnHIQW7qly4hLJTvOZeE9UkHnY7AL2DVEtOs6 5hSb2XQcqTN7YbYbtvtG30IzTTVqhTttk+osgd6hsTl2CXWgzfHx5PZvH9GPBXbfmKg3 DEpebSIMCAzLmIG5oxtpZamUuPiQhjGUQw5JooZ0Qlq7ya8lBq/j8LTyxiaI6gZTEIMU sXuClJj54NkFk8BtZxcU5jGSf6RWj7yBWaSaTtcQdnaBm3Ft/EUyJ33MZ1KDHEhZD8fh 77DPM/4dph0BwHm6FuL3L25cmTH+Vk9clK7SPLgfohwJelUi3D+7oKktdvDu6fSlviPZ DSoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VdlyKL1FdXgTmzTRlGLV6WDTsRCqML/2O/uxVlNBeDI=; b=QP75NtfoyjJfrlC7oY4q5AsrGTlTvBMsXvDXf9SHxWfQwV5mn15iz/p7EuGuILkCjS dYTJF2kH05SDQMPAKn4WoWXlLsuzR/VfNdixR/L53hVgsP15cUzH4be/yeQ1rxfnrxva 3R6afOH5kitUvbNomw82UmtyIR6m+/rZsXv/xMAjabagY4xphtZ7k8Cnkw1tRoaBUec7 6C8C7ZBe3s/slqlArHumhcgfFkn3zj7dkjFvvhdfPpfvtqcye0zRpwai/lfo/TMn/bOa H4mvy6lwrv5atVf/dueQxP6C4kHchw/LMOnaN9DK4BaLgRFGuCPLxQgKBa29Hf/3ro6q xXnw== X-Gm-Message-State: AE9vXwNflzrR9Tz7c+JO29zBEpY+lcTdGcDPFYks0BkWTsCoVYxWd84kHwBnOrraeTLocQ== X-Received: by 10.194.93.198 with SMTP id cw6mr19444798wjb.212.1474916353783; Mon, 26 Sep 2016 11:59:13 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n7sm23744784wjz.32.2016.09.26.11.59.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 Sep 2016 11:59:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5A54DCB8-8F6C-4EFD-A206-C85ADD099AAD" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Mon, 26 Sep 2016 21:59:11 +0300 Message-Id: <5CB2FFAD-76BB-4C59-9522-6E1D2B8E285C@gmail.com> References: To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] Need vendor support to address a malware vector X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 18:59:20 -0000 --Apple-Mail=_5A54DCB8-8F6C-4EFD-A206-C85ADD099AAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 26 Sep 2016, at 6:22 PM, Joe Touch wrote: > On 9/26/2016 7:52 AM, Phillip Hallam-Baker wrote: >> =E2=80=8B I have been doing some poking around this morning and I = think I have uncovered a major vector for distribution of malware - = Minecraft mods. > ... >> Microsoft paid $2.5 billion for Minecraft.=20 > ... >> But this is a problem that is bound to affect pretty much every = similar community. So while we can make this particular problem the = property of one vendor, Google, Facebook, Apple and the rest can't = ignore the issue. >>=20 >> We have to have a community effort on this. > I disagree that the community needs to provide free resources to = Microsoft to ensure the health and profitability of their product. = Microsoft needs to ante-up. >=20 > That's true for every vendor with a product that needs such a = solution. >=20 > I appreciate your goal of finding either a technology or community = approach that helps vendors do this - and that we as users will benefit, = but IMO any solution needs to start with "pay-for-support=E2=80=9D. IDK. There=E2=80=99s mods for games, and toolbars for browsers, and = YouTube downloaders for browsers, and a Siri-lookalike for Android, and = I remember some Windows add-on that made a sheep or a cat walk around = your Desktop. It was a hit in the 90s. Regardless of how they=E2=80=99re described, they=E2=80=99re all = software that the user is duped into downloading and installing. The = makers of Minecraft or the browsers or the phone OS don=E2=80=99t really = make these. Sure, they could make their product non-extendable, = non-moddable. They don=E2=80=99t. Because we like mods for games, = extensions/plug-ins for browsers and apps for phones. So people install = stuff they shouldn=E2=80=99t.=20 I=E2=80=99d be glad if we could do something about it. But malware is = hard to identify (except for very specific kinds) or even to define. So = I don=E2=80=99t know what we (for whatever interpretation of we) can do. To get back to Phil=E2=80=99s message, even if Microsoft hosted all the = mods, they might still include bad stuff. Just like every app store or = extension library. Yoav --Apple-Mail=_5A54DCB8-8F6C-4EFD-A206-C85ADD099AAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Sep 2016, at 6:22 = PM, Joe Touch <touch@isi.edu> wrote:

On 9/26/2016 7:52 AM, Phillip Hallam-Baker wrote:
=E2=80=8B= I have been doing some poking around this morning and I think I have uncovered a major vector for distribution of malware - Minecraft mods.
...
Microsoft paid $2.5 billion for = Minecraft.
...
But = this is a problem that is bound to affect pretty much every similar community. So while we can make this particular problem the property of one vendor, Google, Facebook, Apple and the rest can't ignore the issue.

We have = to have a community effort on this.
I disagree that the community needs to provide free resources to Microsoft to ensure the health and profitability of their product. Microsoft needs to ante-up.

That's true for every vendor with a product that needs such a solution.

I appreciate your goal of finding either a technology or community approach that helps vendors do this - and that we as users will benefit, but IMO any solution needs to start with = "pay-for-support=E2=80=9D.

IDK. There=E2=80=99s mods for games, and toolbars = for browsers, and YouTube downloaders for browsers, and a Siri-lookalike = for Android, and I remember some Windows add-on that made a sheep or a = cat walk around your Desktop. It was a hit in the 90s.

Regardless of how they=E2=80=99re described, = they=E2=80=99re all software that the user is duped into downloading and = installing. The makers of Minecraft or the browsers or the phone OS = don=E2=80=99t really make these. Sure, they could make their product = non-extendable, non-moddable. They don=E2=80=99t. Because we like mods = for games, extensions/plug-ins for browsers and apps for phones. =  So people install stuff they shouldn=E2=80=99t. 

I=E2=80=99d be glad if we could do something about = it. But malware is hard to identify (except for very specific kinds) or = even to define. So I don=E2=80=99t know what we (for whatever = interpretation of we) can do.

To get = back to Phil=E2=80=99s message, even if Microsoft hosted all the mods, = they might still include bad stuff. Just like every app store or = extension library.

Yoav

= --Apple-Mail=_5A54DCB8-8F6C-4EFD-A206-C85ADD099AAD-- From nobody Mon Sep 26 12:09:13 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B9912B2A7; Mon, 26 Sep 2016 12:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0NLQFzEs43s; Mon, 26 Sep 2016 12:09:02 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C8A12B26E; Mon, 26 Sep 2016 12:09:01 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1DE3950A84; Mon, 26 Sep 2016 15:08:59 -0400 (EDT) To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> From: Sean Leonard Message-ID: <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> Date: Mon, 26 Sep 2016 12:10:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474881447.45169.205.camel@infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:09:09 -0000 On 9/26/2016 2:17 AM, David Woodhouse wrote: > On Sun, 2016-09-25 at 18:48 -0700, Sean Leonard wrote: >> Hello David: >> >> draft-seantek-certspec =E2=80=9CTextual Specification for Certificates= =E2=80=9D is >> exactly what you=E2=80=99re looking for. >> >> https://tools.ietf.org/html/draft-seantek-certspec-09 > Thanks; that's very interesting. I'm not sure it covers exactly the > same use case, but it's very closely related. Great! > >> That is for certificates. And yes, it handles pkcs11 just like >> everything else. > ... but not like RFC7512 does, I note. Is it worth trying to achieve > some better consistency there? After all, I can *already* refer to the > certificate in my crypto token consistently as > > 'pkcs11:manufacturer=3Dpiv_II;id=3D%01' > > in a variety of applications using different crypto libraries. And in > fact on my operating system of choice I can file a bug for any > application which *doesn't* accept that string, when it would have > taken a filename. So I'd definitely like to see your draft make > explicit reference to RFC7512 in some form or other. I can do that...although the value of doing so may be a bit lost on me.=20 The general syntax would be: URI:pkcs11:manufacturer=3Dpiv_II;id=3D%01 The syntax of "URI:uri" (with URI: prepended) has a long and tumultuous=20 history. You can look at the draft history to see why. Applications for draft-seantek-certspec are hunting for certificates on=20 the order of sub-milliseconds: looking up a certificate could be done in = a blocking operation. This would be the case, for example, when a TLS=20 server (web server, IMAP server, etc.) or client boots up and needs the=20 certificate before starting its first TLS connection. As a general=20 matter, URIs strongly imply network access; therefore they are not as=20 important as the other types of specs. Any application that plans on using a certificate with its corresponding = private key should obviously have the certificate on-hand and=20 at-the-ready. Even if the private key is unavailable (e.g., the hardware = token is not in the slot), some pointer that shows that a private key is = known to be around, has to be immediately available. That way the UI can = prompt the user for the right device. A distinguishing feature of URIs is that it is limited in its repertoire = of characters to a strict subset of ASCII, with % percent-encoding. This = means that LDAP strings are going to look very convoluted, with a lot of = %20, %2F, %3B, etc. throughout. If you want to permit users to specify=20 strings without double or triple % encoding and \ escaping and whatnot,=20 then I can buy an argument to promote "p11:" or similar to the top of a=20 certspec, and not buried into the "URI:" spec type. There is precedent=20 for this because there are already BASE64 and HEX specs, which duplicate = URI:data: in functionality, but are demonstrably easier to use. By the way, RFC 7512 contains a serious bug: the | character is not=20 valid in URI [RFC3986]. I don't know how that character snuck through=20 the RFC process, but it's not a valid URI. RFC 7512 contains a second, less serious bug: "The URI scheme does not=20 use the fragment component." Well that may or may not be good advice. I=20 don't see why a PKCS #11 token can't return a blob that is plain text=20 (text/plain), in which case, fragment would be defined by RFC 5147.=20 Furthermore, PKCS #11 is actually Internet media type-aware: see=20 CKA_MIME_TYPES, for example, in that standard. > >> *** >> >> Private keys are another matter. The approach could easily be >> extended to handle private keys. They are just identifiers, after >> all. However, by definition secure private keys are a =E2=80=9Clocal m= atter=E2=80=9D. >> I do not see the value of standardizing an identifier for private >> keying materials when the implementations are all different and are >> not supposed to communicate with each other. > Ah, but that is *precisely* the matter I was most concerned about. It's= > not so much about implementations communicating with each other; it's > about consistency and (hence) usability. > > Not very long ago, in order to use that key in the crypto token I > mentioned above, I had to do something *different* for fairly much > every application: > > =E2=80=A2 for OpenVPN, I had to manually specifier the PKCS#11 provid= er > module and use one form of identifier string. > =E2=80=A2 for OpenConnect, RFC7512 identifiers Just Worked, and it us= ed > the PKCS#11 providers indicated by the system configuration. (Yay!)= > =E2=80=A2 for Curl (if built with NSS) I needed to manually edit conf= iguration > files to make it load the right module, and then refer to the > object by a *third* form of identifier string. > =E2=80=A2 for wpa_supplicant I had to manually configure it to use an= OpenSSL > "Engine", specify the provider in yet *another* different manner > because that also ignored the system configuration, and then give > the certificate ID in a *fourth* different form. > > And that was just for the applications which *could* use PKCS#11. Many > just couldn't do it at all. And for some, they needed to be configured > differently depending on which crypto library they'd been built > against. > > It made me kind of sad. FWIW I have all of the above just taking > PKCS#11 URIs according to RFC7512 now, without any of the additional > configuration nonsense like loading engines and specifying provider > modules. That is indeed a list of horribles. But for applications that are PKCS #11 based, one could easily write a=20 script that takes a pkcs11: URI as input and outputs the right flips,=20 switches, config files, and API calls to do what the pkcs11: URI is=20 saying to do. Probably would take less than a day. For applications that are *not* PKCS #11 based (macOS Keychain Services, = Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't know=20 of a better way to put it. > > Now, *part* of that is addressed by your draft (although it's already > addressed by RFC7512 in the case of PKCS#11, and the conflicts there > want resolving). But other parts are not =E2=80=94 and I'm not sure you= really > want to expand your scope to cover them. They include: > > =E2=80=A2 Using the system configuration for which PKCS#11 providers = to load. > =E2=80=A2 The search algorithm, identifying when to log in to a token= to > attempt to find a certificate with CKA_PRIVATE and how to locate > the key corresponding to a given certificate, etc. > =E2=80=A2 The requirement that opaque private keys without access to = the > corresponding public key SHALL work. > > That's just for PKCS#11. of course. For files there are a different set= > of issues =E2=80=94 mostly the fact that every application on the syste= m will > currently support a *different* subset of private key file formats. So > a user with a certificate+key provisioned through her organisation's > proprietary scripting will find that it works with *some* applications > and not others, for reasons which are entirely intractable, such as: > > =E2=80=A2 It uses the non-standard OpenSSL 'encrypted PEM' format. > =E2=80=A2 It uses a SHA256 HMAC which isn't universally supported. > =E2=80=A2 It is encrypted with DES-MD5, which isn't universally suppo= rted. > =E2=80=A2 It is in DER form, which applications need to jump through = hoops > to cope with loading because crypto libraries hate us all. > > The idea of my draft is to give a set of "best practice" guidelines for= > applications so that the user *can* just use the same certificate and > key with any well-behaved application, with exactly the same > identifier, and it will Just Work. > > It's not *just* about the identifier though, and in fact I've mostly > tried to make it *not* about the identifier. I just defer to RFC7512 > and obviously to filenames. For the system certificate stores I just > say that if a convention exists, it should be supported =E2=80=94 and i= t sounds > like your draft would be the ideal solution to fill that gap. > > So while there is certainly an overlap with your draft, there's also a > lot to cope with that *isn't* already the primary target of your draft.= Okay. Yes, the primary target of the draft is identifying certificates=20 (uniquely and unambiguously), and providing associated attributes with=20 the certspec. Interestingly, one of those "associated attributes" could=20 very well be: "hint or directive about where to find the private key".=20 So that is a point of extension that we could collaborate on, whether in = draft-seantek-certspec or in a related draft. For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo=20 (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are=20 standardized, widely-supported, and algorithm-agile. They are also=20 simple enough that even if a crypto stack doesn't support them directly, = "adapters" can be built that shoehorn the data into other container=20 formats, such as PKCS #12, OpenSSL's proprietary formats, and so on.=20 (Note that I worked on the registrations for both application/pkcs12 and = application/pkcs8-encrypted.) > If you want, I'm happy to work with you to *make* your draft cover > this. But I suspect there would be sufficient conflict in our use cases= > that it's best just to ensure that they complement each other to > achieve their respective goals. What do you think? I am happy to make draft-seantek-certspec more useful to different=20 constituents! The focus needs to remain on uniquely identifying cryptographic data=20 items, rather than as a generalized querying format. (Discussed in=20 draft.) However, I like the idea of a standardized attribute that points = to the location of a private key. Such an attribute could also be=20 conveniently serialized into other formats, e.g., as attributes in PKCS=20 #11 and PKCS #12, and as Certificate Properties in Microsoft CryptoAPI.=20 That is exactly how crypto stacks operate anyway: they tag a certificate = with a little pointer that points to where to find the private key, if=20 one exists. > > For reference, the current version of my nascent draft is at > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html and > it's also at https://github.com/dwmw2/ietf-cert-best-practice Thanks, I read it. > >> You can, of course, always refer to a private key indirectly, by >> referencing an associated certificate. It is very plausible to >> identify a certificate stored in a local file (that does not need to >> be encrypted), and then to look up the associated private key on a >> token that has a lot more protection around the key, by using the >> certificate or its metadata as the dbkey/index. > Yes, there is lots of fun to be had here. Lots of reasonable heuristics= > for how to find a key given the certificates =E2=80=94 and thus lots of= scope > for applications to be inconsistent and for users to complain "it works= > in XXX, so why doesn't exactly the same cert work in YYY?". > > I've attempted to address this with the search algorithm for PKCS#11. > For files there's not a lot you can do although I do mention that if > the cert has extension '.crt' and doesn't actually contain the private > key, you might look for a corresponding file with extension 'key'. > > There are probably more improvements that can be made in this area, > especially when it comes to the system stores on Windows and OSX. Okay. >> [The aforementioned paragraph is also responsive to Ted Lemon=E2=80=99= s >> concern: =E2=80=9Cone concern I have about it is that we actually real= ly >> don't want applications to have access to private keys.=E2=80=9D] > Yes, we absolutely need to support and encourage that use case. That is= > part of my motivation for pushing to have PKCS#11 supported > consistently across applications on platforms where that's the best > answer. Good. Regards, Sean From nobody Mon Sep 26 12:48:54 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540B812B29C; Mon, 26 Sep 2016 12:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGl_O_WykIln; Mon, 26 Sep 2016 12:48:50 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A94E12B249; Mon, 26 Sep 2016 12:48:50 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bobtR-00028W-4b; Mon, 26 Sep 2016 19:48:49 +0000 Message-ID: <1474919326.45169.305.camel@infradead.org> From: David Woodhouse To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group Date: Mon, 26 Sep 2016 20:48:46 +0100 In-Reply-To: <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-NDDM2SvdXvsnlz5v8HQb" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:48:52 -0000 --=-NDDM2SvdXvsnlz5v8HQb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-26 at 12:10 -0700, Sean Leonard wrote: > > > That is for certificates. And yes, it handles pkcs11 just like > > > everything else. > > ... but not like RFC7512 does, I note. Is it worth trying to achieve > > some better consistency there? After all, I can *already* refer to the > > certificate in my crypto token consistently as > >=20 > > 'pkcs11:manufacturer=3Dpiv_II;id=3D%01' > >=20 > > in a variety of applications using different crypto libraries. And in > > fact on my operating system of choice I can file a bug for any > > application which *doesn't* accept that string, when it would have > > taken a filename. So I'd definitely like to see your draft make > > explicit reference to RFC7512 in some form or other. >=20 > I can do that...although the value of doing so may be a bit lost on me.= =20 > The general syntax would be: >=20 > URI:pkcs11:manufacturer=3Dpiv_II;id=3D%01 >=20 > The syntax of "URI:uri" (with URI: prepended) has a long and tumultuous= =20 > history. You can look at the draft history to see why. >=20 > Applications for draft-seantek-certspec are hunting for certificates on= =20 > the order of sub-milliseconds: looking up a certificate could be done in= =20 > a blocking operation. This would be the case, for example, when a TLS=20 > server (web server, IMAP server, etc.) or client boots up and needs the= =20 > certificate before starting its first TLS connection. As a general=20 > matter, URIs strongly imply network access; therefore they are not as=20 > important as the other types of specs. As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of search terms, similar in many ways to the ones in your own draft =E2=80=94 except with a specific focus on what's searchable in the PKCS#11 API. It's just an identifier; it's not valid to make general inferences about it, along the lines of "URIs strongly imply network access". As such, I'd be inclined to suggest that the general syntax for it in your draft might be the PKCS#11 URI itself, starting with 'pkcs11:'. > Any application that plans on using a certificate with its corresponding= =20 > private key should obviously have the certificate on-hand and=20 > at-the-ready. Even if the private key is unavailable (e.g., the hardware= =20 > token is not in the slot), some pointer that shows that a private key is= =20 > known to be around, has to be immediately available. That way the UI can= =20 > prompt the user for the right device. >=20 > A distinguishing feature of URIs is that it is limited in its repertoire= =20 > of characters to a strict subset of ASCII, with % percent-encoding. This= =20 > means that LDAP strings are going to look very convoluted, with a lot of= =20 > %20, %2F, %3B, etc. throughout.=20 Who said anything about LDAP strings? I was *only* talking about the PKCS#11 identifiers as defined in RFC7512. Which aren't really URIs although that term is used there quite a lot :) > If you want to permit users to specify=20 > strings without double or triple % encoding and \ escaping and whatnot,= =20 > then I can buy an argument to promote "p11:" or similar to the top of a= =20 > certspec, and not buried into the "URI:" spec type.=20 No, I absolutely don't want *more* ways of referring to the same objects, and more things for the users to try, and discover are inconsistently supported across the set of applcatiions they use. > By the way, RFC 7512 contains a serious bug: the | character is not=20 > valid in URI [RFC3986]. I don't know how that character snuck through=20 > the RFC process, but it's not a valid URI. Fine, there are almost no circumstances when you might want to use the RFC7512 identifier as if it's *really* a URI. It looks like you *suggested* it above, but I think you're the first, and I just told you not to :) > RFC 7512 contains a second, less serious bug: "The URI scheme does not= =20 > use the fragment component." Well that may or may not be good advice. I= =20 > don't see why a PKCS #11 token can't return a blob that is plain text=20 > (text/plain), in which case, fragment would be defined by RFC 5147.=20 > Furthermore, PKCS #11 is actually Internet media type-aware: see=20 > CKA_MIME_TYPES, for example, in that standard. It's an identifier for an object. It is (deliberately AFAICT) not actually a real URI that you might for example put into the location bar of your web browser and expect it to do anything useful. > That is indeed a list of horribles. >=20 > But for applications that are PKCS #11 based, one could easily write a= =20 > script that takes a pkcs11: URI as input and outputs the right flips,=20 > switches, config files, and API calls to do what the pkcs11: URI is=20 > saying to do. Probably would take less than a day. You could do that. Not sure it would entirely meet my criteria for usability though. Better to fix the applications so that they all just accept the objects in the same form, than to have different 'wrappers' and 'config generators' for each application to work around their differences and convert keys between formats. > For applications that are *not* PKCS #11 based (macOS Keychain Services,= =20 > Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't know= =20 > of a better way to put it. Yes. Don't attempt to use a PKCS#11 identifier for something that's not PKCS#11; that would be strange. Having said that... =E2=88=83 PKCS#11 modules which expose the functionalit= y of the keychain and of CAPI/CNG: =C2=A0 =C2=A0 =C2=A0https://github.com/slushpupie/KeychainToken =C2=A0 =C2=A0 =C2=A0https://github.com/risacher/p11-capi .. and then I suppose you *do* end up referencing objects therein via PKCS#11 attributes :) > > So while there is certainly an overlap with your draft, there's also a > > lot to cope with that *isn't* already the primary target of your draft. >=20 > Okay. Yes, the primary target of the draft is identifying certificates= =20 > (uniquely and unambiguously), and providing associated attributes with= =20 > the certspec. Interestingly, one of those "associated attributes" could= =20 > very well be: "hint or directive about where to find the private key".= =20 > So that is a point of extension that we could collaborate on, whether in= =20 > draft-seantek-certspec or in a related draft. Yes, that definitely warrants a further look. > For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo=20 > (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are=20 > standardized, widely-supported, and algorithm-agile.=20 They are also non-portable, because even when RFC5958 was published in 2010, FFS, it didn't mandate the conversion of the password to UTF-8 (let alone any mention of Unicode normalisation) for the purpose of the key derivation. PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP). --=20 dwmw2 --=-NDDM2SvdXvsnlz5v8HQb Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTI2MTk0ODQ2WjAvBgkqhkiG9w0BCQQxIgQgv3ciyCODh4uAiXpTs2jlOFCdRCHX/bfo6KkI 5mNW38AwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAM+A 54eGxSrlXnpr0NzYNJPOASmnQcys2afNV/fL2m43mayptSZh69F0nmTaoE21JfQ8nH3Mu+dtr3Ge 9ItyKeHFejwewXpsls/CzxIgXqdkpGUuCJ1aaKTv5hxdHXIusPGhcWkbR2BhDR5et4sPVy308s7L USN5BTc1pKyM14HJ+MrUL3F+6IjdPE0x9i0Gi/xdr+6TVVxf8KWE1JRCHQiBTxexv6vP5L5Ulywx PNqdp2TCiPpa423MEOnYA7JIuc3myHLCsWUI+qKnkA/RFHokwb2v7SRQ3gGJUhv05XOEYJY+6YQB gWkWksYiWd16eY9LbpAiN0HssSbGFvNvcwThCqiX3pfPjxTRDIfxRUbqgEgpNHzMG8ZhrBn1grwQ CE7UDOz5wGRJWD4SQvGottTW57EK3mLBP8x6kex0PVpjG0yCHPhcXjS0uW8ypJn81RsG/f+kClSl V21SZGqGyBjIz4XeTdQCJYolk5tAGoxdM4ALty5CuktQYtURG5KS3T4yldC+oPdOZQd926ckI38C ZpM+qKeAmTug3wkZYXR7wTVqFZmLYJ3TGk7GD1tcfbt0BXrYWdPubmVlgAsC7ulgqYtCTfcRE88B Ga4+1nw6NNTucOqOGJiJjqx71ONtMt4Odo89KiXXZ4vy2InyF5Y9uBkr90XU9GKiBpOMGATsAAAA AAAA --=-NDDM2SvdXvsnlz5v8HQb-- From nobody Mon Sep 26 12:54:11 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74F312B249; Mon, 26 Sep 2016 12:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiZE5hz6zCz1; Mon, 26 Sep 2016 12:54:04 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88961127076; Mon, 26 Sep 2016 12:54:04 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2EBDF50A84; Mon, 26 Sep 2016 15:54:03 -0400 (EDT) To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> From: Sean Leonard Message-ID: Date: Mon, 26 Sep 2016 12:55:45 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474919326.45169.305.camel@infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 19:54:06 -0000 On 9/26/2016 12:48 PM, David Woodhouse wrote: > >> For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo >> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are >> standardized, widely-supported, and algorithm-agile. > They are also non-portable, because even when RFC5958 was published in > 2010, FFS, it didn't mandate the conversion of the password to UTF-8 > (let alone any mention of Unicode normalisation) for the purpose of the > key derivation. > > PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP). draft-seantek-pkcs8-encrypted-01 Glad to see someone else cares about password mapping. :) Sean From nobody Mon Sep 26 13:32:59 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5540D12B23C; Mon, 26 Sep 2016 13:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, T_MIME_MALF=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAyeZY4miY9H; Mon, 26 Sep 2016 13:32:53 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F7712B011; Mon, 26 Sep 2016 13:26:02 -0700 (PDT) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bocTR-00085W-Qi; Mon, 26 Sep 2016 20:26:02 +0000 Message-ID: <1474921558.45169.314.camel@infradead.org> From: David Woodhouse To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group Date: Mon, 26 Sep 2016 21:25:58 +0100 In-Reply-To: References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-RDHdfDJX+ViU75AAMyGb" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:32:54 -0000 --=-RDHdfDJX+ViU75AAMyGb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote: > On 9/26/2016 12:48 PM, David Woodhouse wrote: > > > >> For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo > >> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are > >> standardized, widely-supported, and algorithm-agile. > > They are also non-portable, because even when RFC5958 was published in > > 2010, FFS, it didn't mandate the conversion of the password to UTF-8 > > (let alone any mention of Unicode normalisation) for the purpose of the > > key derivation. > > > > PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP). >=20 > draft-seantek-pkcs8-encrypted-01 OK... so now we have can say Content-Type: application/pkcs8-encrypted; password-mapping=3DUTF-8 (Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?) But I've *never* seen an application make use of certs/files from any container where that Content-Type: header might be present. It's not even permitted to put it in PEM files, is it? So does this really buy me anything in practice?=C2=A0 And it still doesn't cover Unicode normalisation. :) > Glad to see someone else cares about password mapping. Mostly when it breaks :) --=20 dwmw2 --=-RDHdfDJX+ViU75AAMyGb Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYwOTI2MjAyNTU4WjAvBgkqhkiG9w0BCQQxIgQgGEEnwMMnnMDrfbkNynxOW3KkjszFgPRTnRbV PVV4AqgwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAABO 7Flm15FY8eR6I6fctFZ+jb3SuPRDeUPKx2RC9AXu8gIrJkDvDcwkKhilAZ3Jzu+oSTqsEsMQmR9A UjN2psln6XOaWfJsBGMZQMk4BDqPZ1kMnhDD187avveTDJJMru9vKNJfJT/CtW0GuMLDTkyAKXCr 3eggOhUqSdyIWVWSPGT2ImmSqVATySGpZuLAlASzmQQQiFR7/2SKqY1zGO8qjx0LnDW7GJR8r6k3 0cPYpPh/a8rBnwx9XHwsMjJrzxr6GQQ3yVNBjaIXY4lPkaZvypq58ffi1EnHof7EijcN7MZZOdrV pXhCFB41fKdk/IsVX058s8dP7BNyjPectW0GGAbhP0uC8K+6M+rBl2SKZ8H2diex2JA0JXPSdRFb vHfVUB2JFnQMor9wOVfVPW7P4YuCuigIDcu5zoKGnvHEpsMEwjgkvKAWLdZQ0U/4FDdnm3CsndI5 P7fgLgDG3DPHfmleaBV6KMtWC5S0DQsKopU2wYIdKmEOFgywosH8UlCm3sWWilCqexDF8PjQGfyo mq4jfnIhJyKwZGPX+VRuH639/CmEeQCnf6BkrglwYgfM/OmsEIMDejrNBlk908UmkMCar7LnHcfh ypGsPsWeARW6+Z3NFslzPVd3rzIIFGzZAC39DT2p5pqIysS3cl1Um4Igf8yW+YGsLDyjCe9xAAAA AAAA --=-RDHdfDJX+ViU75AAMyGb-- From nobody Mon Sep 26 14:00:03 2016 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2465612B01C; Mon, 26 Sep 2016 13:59:58 -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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRgKlOldfg0D; Mon, 26 Sep 2016 13:59:56 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DA312B016; Mon, 26 Sep 2016 13:59:55 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5872B50A87; Mon, 26 Sep 2016 16:59:54 -0400 (EDT) To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group References: <1474280601.144982.263.camel@infradead.org> <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca> <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <1474921558.45169.314.camel@infradead.org> From: Sean Leonard Message-ID: Date: Mon, 26 Sep 2016 14:01:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474921558.45169.314.camel@infradead.org> Content-Type: multipart/alternative; boundary="------------03FB81F1BBAC8E1DD532BC03" Archived-At: Cc: Michael Richardson Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2016 20:59:58 -0000 This is a multi-part message in MIME format. --------------03FB81F1BBAC8E1DD532BC03 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 9/26/2016 1:25 PM, David Woodhouse wrote: > On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote: >> On 9/26/2016 12:48 PM, David Woodhouse wrote: >>>> For interoperable private key formats, I favor PKCS #8 PrivateKeyInf= o >>>> (as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are >>>> standardized, widely-supported, and algorithm-agile. >>> They are also non-portable, because even when RFC5958 was published i= n >>> 2010, FFS, it didn't mandate the conversion of the password to UTF-8 >>> (let alone any mention of Unicode normalisation) for the purpose of t= he >>> key derivation. >>> >>> PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP= ). >> draft-seantek-pkcs8-encrypted-01 > OK... so now we have can say > > Content-Type: application/pkcs8-encrypted; password-mapping=3DUTF-8 > > (Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?)= Yes, I meant UTF-16BE. That was a typo. By the way, I've actually done quite a lot of tests on several crypto=20 stacks, and none of them enforce that the Unicode code point has to be=20 in the BMP. You can use surrogate pairs (which are in the BMP anyway)=20 just fine. > > But I've *never* seen an application make use of certs/files from any > container where that Content-Type: header might be present. It's not > even permitted to put it in PEM files, is it? So does this really buy > me anything in practice? As with any "new thing", people have to write code for the "new thing"=20 to use the "new thing". If you build it, they will come... The alternative would be to shoehorn the password mapping into some=20 attribute in ASN.1. But there's no practical place for that in PKCS #8=20 EncryptedPrivateKeyInfo, which is just: EncryptedPrivateKeyInfo ::=3D SEQUENCE { encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},= encryptedData EncryptedData } I mean, you *could* put it in the PBKDF2-params, with a new algorithm=20 identifier. But that will require writing new code to deal with the "new = thing". No way around it, sorry. > > And it still doesn't cover Unicode normalisation. :) Actually it does. PRECIS says NFC for password/OpaqueString. See Section = 6.2 of RFC 7613. There were much earlier draft registrations (see the media-types mailing = list, it's been kicking around for many months now; see also PRECIS=20 mailing list) that went into some detail about NFC and stuff like that.=20 The rough consensus was that it's best to let PRECIS handle that stuff:=20 doing it in the security space (aka PKCS #8 or similar container) is not = where the expertise lies. The other point is that there is only one party that cares about the=20 encoding: "you". You =3D the private key holder. Private keys aren't mean= t=20 to be shared. Frankly, who cares what the octets are, as long as you can = input the same ones into the decryption process. If you are creating the = private key and using it on the same computing device, the encoding=20 doesn't actually matter. You could record mouse clicks or voice samples=20 or raw key scan codes from the kernel, and it wouldn't affect the result.= Annex M.4 of IEEE 802.11-2012 has similar insights (which is why I cited = it). Adding the encoding parameter actually facilitates attacks, because it=20 tells an eavesdropper what bit patterns will *not* appear. Well-formed=20 UTF-8 can never have octets C0, C1, or F5-FF, for example; well-formed=20 UTF-8 will also bias the input to make certain bit patterns far more=20 likely than others. (The KDF is designed to mitigate against biased=20 input anyway, though.) The encoding parameter can also thwart attacks,=20 by intentionally mislabeling the encoding. It's not cryptographically=20 protected so it is subject to undetectable tampering. Best regards, Sean --------------03FB81F1BBAC8E1DD532BC03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/26/2016 1:25 PM, David Woodhouse wrote:
On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:

On 9/26/2016 12:48 PM, David Woodhouse wrote:


          

            
For interoperable private key formats, I favor PKCS #8 PrivateKeyInfo
(as .p8) and PKCS #8 EncryptedPrivateKeyInfo (as .p8e). They are
standardized, widely-supported, and algorithm-agile.


          

          
They are also non-portable, because even when RFC5958 was published in
2010, FFS, it didn't mandate the conversion of the password to UTF-8
(let alone any mention of Unicode normalisation) for the purpose of the
key derivation.

PKCS#12 at least gets *part* of that right, by mandating UTF16BE (BMP).


        

        
draft-seantek-pkcs8-encrypted-01


      

      
OK... so now we have can say

Content-Type: application/pkcs8-encrypted; password-mapping=UTF-8

(Did you intend '*pkcs12' to mean UTF16-BE which is BMP, not UTF-16LE?)

    

    Yes, I meant UTF-16BE. That was a typo.

    

    By the way, I've actually done quite a lot of tests on several
    crypto stacks, and none of them enforce that the Unicode code point
    has to be in the BMP. You can use surrogate pairs (which are in the
    BMP anyway) just fine.

    

    

      

But I've *never* seen an application make use of certs/files from any
container where that Content-Type: header might be present. It's not
even permitted to put it in PEM files, is it? So does this really buy
me anything in practice? 


    

    

    As with any "new thing", people have to write code for the "new
    thing" to use the "new thing". If you build it, they will come...

    

    The alternative would be to shoehorn the password mapping into some
    attribute in ASN.1. But there's no practical place for that in PKCS
    #8 EncryptedPrivateKeyInfo, which is just:

    

    
EncryptedPrivateKeyInfo ::= SEQUENCE {
    encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},
    encryptedData EncryptedData
}


    

    I mean, you *could* put it in the PBKDF2-params, with a new
    algorithm identifier. But that will require writing new code to deal
    with the "new thing". No way around it, sorry.

    

    

      

And it still doesn't cover Unicode normalisation. :)

    

    

    Actually it does. PRECIS says NFC for password/OpaqueString. See
    Section 6.2 of RFC 7613.

    

    There were much earlier draft registrations (see the media-types
    mailing list, it's been kicking around for many months now; see also
    PRECIS mailing list) that went into some detail about NFC and stuff
    like that. The rough consensus was that it's best to let PRECIS
    handle that stuff: doing it in the security space (aka PKCS #8 or
    similar container) is not where the expertise lies.

    

    The other point is that there is only one party that cares about the
    encoding: "you". You = the private key holder. Private keys aren't
    meant to be shared. Frankly, who cares what the octets are, as long
    as you can input the same ones into the decryption process. If you
    are creating the private key and using it on the same computing
    device, the encoding doesn't actually matter. You could record mouse
    clicks or voice samples or raw key scan codes from the kernel, and
    it wouldn't affect the result.

    

    Annex M.4 of IEEE 802.11-2012 has similar insights (which is why I
    cited it).

    

    Adding the encoding parameter actually facilitates attacks, because
    it tells an eavesdropper what bit patterns will *not* appear.
    Well-formed UTF-8 can never have octets C0, C1, or F5-FF, for
    example; well-formed UTF-8 will also bias the input to make certain
    bit patterns far more likely than others. (The KDF is designed to
    mitigate against biased input anyway, though.) The encoding
    parameter can also thwart attacks, by intentionally mislabeling the
    encoding. It's not cryptographically protected so it is subject to
    undetectable tampering.

    

    Best regards,

    

    Sean
  


--------------03FB81F1BBAC8E1DD532BC03--


From nobody Mon Sep 26 14:15:46 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6512312B0A3; Mon, 26 Sep 2016 14:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnsBTokkkZOY; Mon, 26 Sep 2016 14:15:39 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A259212B027; Mon, 26 Sep 2016 14:15:39 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bodFR-0006H4-Ef; Mon, 26 Sep 2016 21:15:37 +0000
Message-ID: <1474924534.45169.325.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group 
Date: Mon, 26 Sep 2016 22:15:34 +0100
In-Reply-To: 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org> 
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-OyKiTFKL7rG+ghtMPcZg"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: Michael Richardson 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:15:41 -0000

--=-OyKiTFKL7rG+ghtMPcZg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:01 -0700, Sean Leonard wrote:
> On 9/26/2016 1:25 PM, David Woodhouse wrote:
> > But I've *never* seen an application make use of certs/files from any
> > container where that Content-Type: header might be present. It's not
> > even permitted to put it in PEM files, is it? So does this really buy
> > me anything in practice?=20
> =C2=A0
> As with any "new thing", people have to write code for the "new
> thing" to use the "new thing". If you build it, they will come...

Sure, But with this you might as well say "write it on a Post-it note
and stick it to the monitor". Because that MIME header doesn't actually
live anywhere near the key when it's stored.

If I *wanted* to fix my OpenConnect VPN client to support this, for
example, how would I go about doing so? If I've got a PKCS#8 DER
file... where do I look for this header? If I have a PEM file, do I
look for it after the '-----BEGIN ENCRYPTED PRIVATE KEY-----' line?=C2=A0

> The alternative would be to shoehorn the password mapping into some
> attribute in ASN.1. But there's no practical place for that in PKCS
> #8 EncryptedPrivateKeyInfo, which is just:
>=20
> EncryptedPrivateKeyInfo ::=3D SEQUENCE {
>     encryptionAlgorithm AlgorithmIdentifier {{KeyEncryptionAlgorithms}},
>     encryptedData EncryptedData
> }
>=20
> I mean, you *could* put it in the PBKDF2-params, with a new algorithm
> identifier. But that will require writing new code to deal with the
> "new thing". No way around it, sorry.

Agreed. Or just observe that actually, PKCS#5 got it right all along:
Use ASCII or UTF-8. Which are actually the same thing, since one is a
superset of the other: use UTF-8.

> The other point is that there is only one party that cares about the
> encoding: "you". You =3D the private key holder. Private keys aren't
> meant to be shared. Frankly, who cares what the octets are, as long
> as you can input the same ones into the decryption process. If you
> are creating the private key and using it on the same computing
> device, the encoding doesn't actually matter. You could record mouse
> clicks or voice samples or raw key scan codes from the kernel, and it
> wouldn't affect the result.

Generally true, and that's the only reason why things even work as well
as they do. Also why my draft can get away with saying you should *try*
the locale charset, and also try UTF-8, etc.

But it's not *universally* true. Users operate with different locales.
Sometimes a user provisions a certificate for e.g. 802.1x
authentication, then installs it in a location where the *system* can
use it... and suddenly the locale might be different when the key is
being used. And people *do* move files between machines, perhaps as
backups or perhaps on upgrading hardware. And *sometimes* the user's
locale in the two environments might be different.

On the whole though, I'm mostly content to say that anyone who isn't
using UTF-8 consistently, this far into the 21st century, deserves
everything they get. Especially if they try using non-ASCII in their
passwords :)

--=20
dwmw2
--=-OyKiTFKL7rG+ghtMPcZg
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjExNTM0WjAvBgkqhkiG9w0BCQQxIgQgAPPdliE/CWMqkssj0JCxHCC7zCNSYerfM7Dq
qlHfJngwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAKVo
BQ4bZ+tHmjsq6rtXR61EWpgx91fi7eTKWeq5WHwzwNddDOFDUT5VVfi9zDjVx+teb7XcHLPd1WNp
EiAKwBSZXcAgPt0UsKsjzLn8Mg9RWzV91dsGWBkGiiIBNShDhhyiT78RHM/fDG561N7hv4IvyV3g
sybjGbgkizYaqif8bFrNkAHo02W42/3Sbg0FAnbpu+neheEZjvxwqEXMQpoPwZWdjx5DvKmJ3nyF
9adhWQWYmexOwUJchjRf+DK7jJzpu5LPzIpHzeUqc+yRKlcXjbdsx2rXKkmpeBkKL51oPB8fFHJv
x1/dbiUwvSmbOYKRe5XeWO+LeSU2tm+TMJsgpCRk3fKsWmNQsQG/3+vOxL6sk8YSQDhhiEUeKXhs
AVCa1AbMbCIGUzZdBjTgW6RV2nqyIJKKCc204LqZ4JMZHcLoYmva7C6cElaHNRLHbqX1sJrTaDTS
eQyGnN2p22OGQ00p0vLmYI1rOyOITy/x0RLXfEs6CEy+qkhn6Rix+/xfpAKIN5daq/jMmRFnkcW6
Jq+aewFz9/lCrhY6YTGvKGGrh0ISfIU6DdhDDEqi9HFhkESxZLydcP85HEMhYVRht5R+BZoYnzpw
aRY+E5T/yDkAMR2NSeaHR6ghQoPauGEWEPXKX3/5ihVu/I74nFEvHnjzyl72n6QSaGUaN8s9AAAA
AAAA


--=-OyKiTFKL7rG+ghtMPcZg--


From nobody Mon Sep 26 14:18:33 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8646E12B09C; Mon, 26 Sep 2016 14:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POS7QdxlAXwL; Mon, 26 Sep 2016 14:18:31 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BD012B01C; Mon, 26 Sep 2016 14:18:30 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0B79150A73; Mon, 26 Sep 2016 17:18:28 -0400 (EDT)
To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>
From: Sean Leonard 
Message-ID: <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com>
Date: Mon, 26 Sep 2016 14:20:10 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <1474919326.45169.305.camel@infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: Michael Richardson 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:18:32 -0000

On 9/26/2016 12:48 PM, David Woodhouse wrote:
> On Mon, 2016-09-26 at 12:10 -0700, Sean Leonard wrote:
>>>> That is for certificates. And yes, it handles pkcs11 just like
>>>> everything else.
>>> ... but not like RFC7512 does, I note. Is it worth trying to achieve
>>> some better consistency there? After all, I can *already* refer to th=
e
>>> certificate in my crypto token consistently as
>>>
>>> 	'pkcs11:manufacturer=3Dpiv_II;id=3D%01'
>>>
>>> in a variety of applications using different crypto libraries. And in=

>>> fact on my operating system of choice I can file a bug for any
>>> application which *doesn't* accept that string, when it would have
>>> taken a filename. So I'd definitely like to see your draft make
>>> explicit reference to RFC7512 in some form or other.
>> I can do that...although the value of doing so may be a bit lost on me=
=2E
>> The general syntax would be:
>>
>> URI:pkcs11:manufacturer=3Dpiv_II;id=3D%01
>>
>> The syntax of "URI:uri" (with URI: prepended) has a long and tumultuou=
s
>> history. You can look at the draft history to see why.
>>
>> Applications for draft-seantek-certspec are hunting for certificates o=
n
>> the order of sub-milliseconds: looking up a certificate could be done =
in
>> a blocking operation. This would be the case, for example, when a TLS
>> server (web server, IMAP server, etc.) or client boots up and needs th=
e
>> certificate before starting its first TLS connection. As a general
>> matter, URIs strongly imply network access; therefore they are not as
>> important as the other types of specs.
> As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of
> search terms, similar in many ways to the ones in your own draft =E2=80=
=94
> except with a specific focus on what's searchable in the PKCS#11 API.

This is surprising, because RFC 7512 Section 4.1. registers it as a=20
permanent URI scheme in the Permanent URI Schemes Registry. =3D:-O

I thought that the whole point of a document called "The PKCS #11 URI=20
Scheme" would be to make PKCS #11 items accessible in URI protocol=20
slots, and conversely, to make URI protocol slots useful to PKCS=20
#11-consuming applications (in addition to other URI items such as http: =

, ldap: , data: , etc.).

>
> It's just an identifier; it's not valid to make general inferences
> about it, along the lines of "URIs strongly imply network access".
>
> As such, I'd be inclined to suggest that the general syntax for it in
> your draft might be the PKCS#11 URI itself, starting with 'pkcs11:'.

URIs are meant for Internet-accessing things. The specific URI scheme=20
itself may not actually do any network access, such as data: or file:.=20
(Or for that matter, http://localhost/ .) But a robust=20
"URI-dereferencer" is going to have to have Internet access to be of=20
much use. In contrast, a file path API does not have to have Internet=20
access per-se to be of use to a broad class of applications.


>
>> Any application that plans on using a certificate with its correspondi=
ng
>> private key should obviously have the certificate on-hand and
>> at-the-ready. Even if the private key is unavailable (e.g., the hardwa=
re
>> token is not in the slot), some pointer that shows that a private key =
is
>> known to be around, has to be immediately available. That way the UI c=
an
>> prompt the user for the right device.
>>
>> A distinguishing feature of URIs is that it is limited in its repertoi=
re
>> of characters to a strict subset of ASCII, with % percent-encoding. Th=
is
>> means that LDAP strings are going to look very convoluted, with a lot =
of
>> %20, %2F, %3B, etc. throughout.
> Who said anything about LDAP strings? I was *only* talking about the
> PKCS#11 identifiers as defined in RFC7512. Which aren't really URIs
> although that term is used there quite a lot :)

Maybe because they are trying to be URIs. :)

LDAP Strings are used by ISSUERSN: in draft-seantek-certspec to identify =

a certificate. It's natural, readable, and widely supported.

Notably, PKCS #11 also uses distinguished names, e.g., in CKA_SUBJECT.=20
But that is a digression so we need not go there too much.

>
>> If you want to permit users to specify
>> strings without double or triple % encoding and \ escaping and whatnot=
,
>> then I can buy an argument to promote "p11:" or similar to the top of =
a
>> certspec, and not buried into the "URI:" spec type.
> No, I absolutely don't want *more* ways of referring to the same
> objects, and more things for the users to try, and discover are
> inconsistently supported across the set of applcatiions they use.
>
>> By the way, RFC 7512 contains a serious bug: the | character is not
>> valid in URI [RFC3986]. I don't know how that character snuck through
>> the RFC process, but it's not a valid URI.
> Fine, there are almost no circumstances when you might want to use the
> RFC7512 identifier as if it's *really* a URI. It looks like you
> *suggested* it above, but I think you're the first, and I just told you=

> not to :)

I think RFC 7512 itself suggests it :)


>> RFC 7512 contains a second, less serious bug: "The URI scheme does not=

>> use the fragment component." Well that may or may not be good advice. =
I
>> don't see why a PKCS #11 token can't return a blob that is plain text
>> (text/plain), in which case, fragment would be defined by RFC 5147.
>> Furthermore, PKCS #11 is actually Internet media type-aware: see
>> CKA_MIME_TYPES, for example, in that standard.
> It's an identifier for an object. It is (deliberately AFAICT) not
> actually a real URI that you might for example put into the location
> bar of your web browser and expect it to do anything useful.

A general-purpose URI dereferencer should be able to work just fine with =

pkcs11: the same way it works with any other URI.

>
>> That is indeed a list of horribles.
>>
>> But for applications that are PKCS #11 based, one could easily write a=

>> script that takes a pkcs11: URI as input and outputs the right flips,
>> switches, config files, and API calls to do what the pkcs11: URI is
>> saying to do. Probably would take less than a day.
> You could do that. Not sure it would entirely meet my criteria for
> usability though. Better to fix the applications so that they all just
> accept the objects in the same form, than to have different 'wrappers'
> and 'config generators' for each application to work around their
> differences and convert keys between formats.

OK.

I believe, in some circles, it is called "vendor lock-in".

Budget, please. :)


>
>> For applications that are *not* PKCS #11 based (macOS Keychain Service=
s,
>> Windows CNG), using a PKCS #11 URI would be..."grotesque". I don't kno=
w
>> of a better way to put it.
> Yes. Don't attempt to use a PKCS#11 identifier for something that's not=

> PKCS#11; that would be strange.
>
> Having said that... =E2=88=83 PKCS#11 modules which expose the function=
ality of
> the keychain and of CAPI/CNG:
>       https://github.com/slushpupie/KeychainToken
>       https://github.com/risacher/p11-capi
> .. and then I suppose you *do* end up referencing objects therein via
> PKCS#11 attributes :)

ok
>
>>> So while there is certainly an overlap with your draft, there's also =
a
>>> lot to cope with that *isn't* already the primary target of your draf=
t.
>> Okay. Yes, the primary target of the draft is identifying certificates=

>> (uniquely and unambiguously), and providing associated attributes with=

>> the certspec. Interestingly, one of those "associated attributes" coul=
d
>> very well be: "hint or directive about where to find the private key".=

>> So that is a point of extension that we could collaborate on, whether =
in
>> draft-seantek-certspec or in a related draft.
> Yes, that definitely warrants a further look.

Great! Let's take a look at that angle.

Sean


From nobody Mon Sep 26 14:30:56 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2312B2D2; Mon, 26 Sep 2016 14:30:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HT8MMWnJCM0g; Mon, 26 Sep 2016 14:30:53 -0700 (PDT)
Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E75612B247; Mon, 26 Sep 2016 14:30:53 -0700 (PDT)
Received: by mail-ua0-x244.google.com with SMTP id i25so95924uab.0; Mon, 26 Sep 2016 14:30:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2YhyLF1ZkVQi5h/o5WAdnJ6hIjJofMvBt/Wz49cw6qY=; b=V+9iZWdIBCAW1xjPx9qyKn+MAQ9uj62EySbPpkx16QJHpMw6LVZPVdepk1iwmeO9Tk r6Z0p5ZT/28vOa3fYOx76ahLVBIk3PLELkZYA6pX5J9XjFRpOjVy1eLJAKCTVJsV9yF1 Ef99rwdZzeYPy6EqE2wikuq+2prjJLcgxIhWAB060icTNa+AjMZaGpnO+koJ4uV3+eQZ swRKUpe4/NMYCnjuXx38NpF6+8aQ8vlPdF8djvaAZrtHPT4loR44qLXoT6yGyEyKAuST WORGjjTGYi0ZSX3g91vctin+SEc4bhnlz1XJX8cze0wN7CLV7WsRdpMry62+AIuPEUT4 XR8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2YhyLF1ZkVQi5h/o5WAdnJ6hIjJofMvBt/Wz49cw6qY=; b=G8lMH/uKlfZeoHu9XTLNvG3sxiKo/DAUpHd8f5i/IpC4vUUIlRkUY5d/fgnocB22oP mHGxpj8cTZ5hx9hrlnLEYnL7wLr926eWyJEuEMolC2WDMeoYpIiNUy6EDWJLHCCkk30M I0uC0KEshzpL5PJ2EEk9d+R8+CxC1qUraTaHTYnB5KhsErHJUBZpgSGUh3J93G00gbnv 2WQdqqjzk9hJFaSLb7r6qvHW4kjP2NeE6fFg0vlVjwhci+/jSFxsLauTHNJ3edddt77c ZSuN864R0hN1gTqquVh/9Aa4d1q2/392lHzXYdNEfxEJVZ7I1T07tkekLetmPkyJykXU 3vxw==
X-Gm-Message-State: AA6/9RkyP8YILltSpkxDCx/LZVtVMJhzGeb5j8F7mYxloOPS9MZZh6b8orJF/ZkuQTM2w+SoDrtyx3HDS4tr4A==
X-Received: by 10.159.53.12 with SMTP id o12mr483838uao.81.1474925452417; Mon, 26 Sep 2016 14:30:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Mon, 26 Sep 2016 14:30:51 -0700 (PDT)
In-Reply-To: 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org> 
From: Watson Ladd 
Date: Mon, 26 Sep 2016 14:30:51 -0700
Message-ID: 
To: Sean Leonard 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:30:55 -0000

On Mon, Sep 26, 2016 at 2:01 PM, Sean Leonard  wrote:
> On 9/26/2016 1:25 PM, David Woodhouse wrote:
>
> On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:
>
> On 9/26/2016 12:48 PM, David Woodhouse wrote:
>

>
> The other point is that there is only one party that cares about the
> encoding: "you". You = the private key holder. Private keys aren't meant to
> be shared. Frankly, who cares what the octets are, as long as you can input
> the same ones into the decryption process. If you are creating the private
> key and using it on the same computing device, the encoding doesn't actually
> matter. You could record mouse clicks or voice samples or raw key scan codes
> from the kernel, and it wouldn't affect the result.

Explain to me how you make a certificate and install it in your
favorite web server without sharing the private key between two
different programs. For extra points try changing mail clients both
with S/MIME set up, and assume you want to read all your own emails
without moving keys. That's the problem we are trying to solve.

Sincerely,
Watson Ladd


From nobody Mon Sep 26 14:32:09 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E07F12B2FC; Mon, 26 Sep 2016 14:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cxiod8Sxnqso; Mon, 26 Sep 2016 14:32:05 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB12512B2AE; Mon, 26 Sep 2016 14:32:05 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1bodVN-0003Rj-Cx; Mon, 26 Sep 2016 21:32:05 +0000
Message-ID: <1474925522.45169.337.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group 
Date: Mon, 26 Sep 2016 22:32:02 +0100
In-Reply-To: <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-1HgdSsD+Hq5kHU2oIEgT"
X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: Michael Richardson 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:32:07 -0000

--=-1HgdSsD+Hq5kHU2oIEgT
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:20 -0700, Sean Leonard wrote:
> > As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of
> > search terms, similar in many ways to the ones in your own draft =E2=80=
=94
> > except with a specific focus on what's searchable in the PKCS#11 API.
>=20
> This is surprising, because RFC 7512 Section 4.1. registers it as a=20
> permanent URI scheme in the Permanent URI Schemes Registry. =3D:-O
>=20
> I thought that the whole point of a document called "The PKCS #11 URI=20
> Scheme" would be to make PKCS #11 items accessible in URI protocol=20
> slots, and conversely, to make URI protocol slots useful to PKCS=20
> #11-consuming applications (in addition to other URI items such as http:=
=20
> , ldap: , data: , etc.).

Perhaps that was the intent; we would have to ask its authors. I cannot
tell. But it doesn't seem stunningly useful in that form to me.,

> > It's an identifier for an object. It is (deliberately AFAICT) not
> > actually a real URI that you might for example put into the location
> > bar of your web browser and expect it to do anything useful.
>=20
> A general-purpose URI dereferencer should be able to work just fine with=
=20
> pkcs11: the same way it works with any other URI.

Yes, but I thought you just raised a bunch of reasons why you *didn't*
want to have generic URI support :)

--=20
dwmw2
--=-1HgdSsD+Hq5kHU2oIEgT
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjEzMjAyWjAvBgkqhkiG9w0BCQQxIgQg4WXEDyHd86pNjpcjuvUhydSI91s+NMYTm1GI
9e2ERLswgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAE8a
uYHgVKmn1QZVuwjf9dC8l2zakKJlsnku+0hCUzFQu6afiKafryzm81Ke3YclgozXZ54EqIPrEyDN
EpeK9tFt3za3QsFtiWnEyzIN7hcw2Yy4Mme5mzXfek2D9MT+tqLMPYunRFjR/Cgd0gA0qgWFmuRP
h1lXfW4yXSBh9k+8U8EAPUaKJl0IxN9ljY+y673wNDSn0QgS6hlrfipVsVOn0OealJeQNreU6XKg
cBJuDw52F5PZ0RL8p+evuU63QLUna5g65YkBekzR19Ei8zsKB5z/qbBNHE9z3u5HU7Jhi5Rgwf0L
f9DWdgyxJxgPaGFf9KSS7E1hzdam+XLQ/THdlmAJsRtjN9Irac3qOHRWGhHVZyTrrD6Wwki8LLoq
cssWeL9IVd7+bGiUqIitn0nKr4TuRSi3O6O9bCNwSCqWFFv4g6AwaWr7B9dnsx/2qRQgMZBVsBEq
tbXj5ZFhbn7QyliEx/+ekX0NoiDZlbQ2senhiwmlxlSkRSVGhs70byLiBluzRS68XG2Iv+i604ky
ziFqx/5xTipBk79sYTOypW9yzUZmXukjv5csIPXmfWHuV2TrL1kCz4r0Gn0Hnwvz8GtS0uFMushq
CtfrZ8x+TkKRx57pWWfShxwSdPlCQO9DEI+6qowRo5JNEc6HIlwcsIsZ+kyngpwAA4QMv0GqAAAA
AAAA


--=-1HgdSsD+Hq5kHU2oIEgT--


From nobody Mon Sep 26 14:53:33 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D80D12B02C; Mon, 26 Sep 2016 14:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlynG0M9pq28; Mon, 26 Sep 2016 14:53:30 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C22112B343; Mon, 26 Sep 2016 14:53:30 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4917E50A86; Mon, 26 Sep 2016 17:53:29 -0400 (EDT)
To: Watson Ladd 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org>  
From: Sean Leonard 
Message-ID: <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com>
Date: Mon, 26 Sep 2016 14:55:11 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:53:32 -0000

On 9/26/2016 2:30 PM, Watson Ladd wrote:
> On Mon, Sep 26, 2016 at 2:01 PM, Sean Leonard  wr=
ote:
>> On 9/26/2016 1:25 PM, David Woodhouse wrote:
>>
>> On Mon, 2016-09-26 at 12:55 -0700, Sean Leonard wrote:
>>
>> On 9/26/2016 12:48 PM, David Woodhouse wrote:
>>
> 
>> The other point is that there is only one party that cares about the
>> encoding: "you". You =3D the private key holder. Private keys aren't m=
eant to
>> be shared. Frankly, who cares what the octets are, as long as you can =
input
>> the same ones into the decryption process. If you are creating the pri=
vate
>> key and using it on the same computing device, the encoding doesn't ac=
tually
>> matter. You could record mouse clicks or voice samples or raw key scan=
 codes
>> from the kernel, and it wouldn't affect the result.
> Explain to me how you make a certificate and install it in your
> favorite web server without sharing the private key between two
> different programs. For extra points try changing mail clients both
> with S/MIME set up, and assume you want to read all your own emails
> without moving keys. That's the problem we are trying to solve.

I am not entirely sure what you're trying to get at...

Having just refreshed my web server's certificate and private key=20
today...first of all, I don't "make a certificate". I generated a=20
private key, and created a Certificate Signing Request. Then I uploaded=20
the CSR to a commercial CA. Then I downloaded the certificate that the=20
*CA* made for me.

Then I copied-and-pasted the certificate into a web form for my web=20
server's control panel. I also copied-and-pasted the private key into=20
the same web form. The private key was not password protected, so it has =

nothing to do with PKCS #8 EncryptedPrivateKeyInfo. There is no point in =

password-protecting the private key, because the web service (taken a=20
whole) needs to see the private key anyway, and the connection to the=20
web-based control panel was protected with TLS.

With S/MIME, I just use PKCS #12 like everyone else. And that workflow=20
specifies the password mapping as UTF-16BE with NULL. :)

When I use cryptographic tokens such as smart cards, the private key=20
never leaves the token. So, there is no password: it's irrelevant.=20
Sometimes the token is configured with a PIN, but the PIN is not the=20
subject of this PKCS #8 EncryptedPrivateKeyInfo discussion.

Sincerely,

Sean


From nobody Mon Sep 26 14:54:42 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8178C12B2AC; Mon, 26 Sep 2016 14:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7ztKX7ipCXP; Mon, 26 Sep 2016 14:54:33 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038E712B2FF; Mon, 26 Sep 2016 14:54:33 -0700 (PDT)
Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C2F7950A73; Mon, 26 Sep 2016 17:54:31 -0400 (EDT)
To: David Woodhouse , spasm@ietf.org, Security Area Advisory Group 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org>
From: Sean Leonard 
Message-ID: 
Date: Mon, 26 Sep 2016 14:56:13 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <1474925522.45169.337.camel@infradead.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Michael Richardson 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 21:54:35 -0000

On 9/26/2016 2:32 PM, David Woodhouse wrote:
> On Mon, 2016-09-26 at 14:20 -0700, Sean Leonard wrote:
>>> As far as I can tell, the PKCS#11 URI is not a URI. It's just a set of
>>> search terms, similar in many ways to the ones in your own draft —
>>> except with a specific focus on what's searchable in the PKCS#11 API.
>> This is surprising, because RFC 7512 Section 4.1. registers it as a
>> permanent URI scheme in the Permanent URI Schemes Registry. =:-O
>>
>> I thought that the whole point of a document called "The PKCS #11 URI
>> Scheme" would be to make PKCS #11 items accessible in URI protocol
>> slots, and conversely, to make URI protocol slots useful to PKCS
>> #11-consuming applications (in addition to other URI items such as http:
>> , ldap: , data: , etc.).
> Perhaps that was the intent; we would have to ask its authors. I cannot
> tell. But it doesn't seem stunningly useful in that form to me.,
>
>>> It's an identifier for an object. It is (deliberately AFAICT) not
>>> actually a real URI that you might for example put into the location
>>> bar of your web browser and expect it to do anything useful.
>> A general-purpose URI dereferencer should be able to work just fine with
>> pkcs11: the same way it works with any other URI.
> Yes, but I thought you just raised a bunch of reasons why you *didn't*
> want to have generic URI support :)

In certspec, identifying a certificate by URI is sensible for a broad 
range of applications. Identifying a certificate by file path is also 
sensible for a broad range of applications. But it's not the only way. 
And URI (and file path) require formatting all strings in particular 
ways, which may not actually be sensible. The draft discusses 
cut-and-paste-ability.

If someone implements certspec URI specs, the easiest way to deal with 
it is to pass the URI to the system's general-purpose URI-dereferencing 
API so it "does the right thing and gives back a blob of bytes (possibly 
with media type information)".

Sean


From nobody Mon Sep 26 15:37:00 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AC812B01C; Mon, 26 Sep 2016 15:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgrXR3Rah4X3; Mon, 26 Sep 2016 15:36:51 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5ED12B02E; Mon, 26 Sep 2016 15:36:51 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1boeW1-0002M2-9d; Mon, 26 Sep 2016 22:36:49 +0000
Message-ID: <1474929405.11690.59.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , spasm@ietf.org, Security Area Advisory Group 
Date: Mon, 26 Sep 2016 23:36:45 +0100
In-Reply-To: 
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org> 
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-VCORYkEUiI8tyoef4rnk"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: Michael Richardson 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 22:36:59 -0000

--=-VCORYkEUiI8tyoef4rnk
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:56 -0700, Sean Leonard wrote:
>=20
> In certspec, identifying a certificate by URI is sensible for a broad=C2=
=A0
> range of applications. Identifying a certificate by file path is also=C2=
=A0
> sensible for a broad range of applications. But it's not the only way.=C2=
=A0
> And URI (and file path) require formatting all strings in particular=C2=
=A0
> ways, which may not actually be sensible. The draft discusses=C2=A0
> cut-and-paste-ability.
>=20
> If someone implements certspec URI specs, the easiest way to deal with=C2=
=A0
> it is to pass the URI to the system's general-purpose URI-dereferencing=
=C2=A0
> API so it "does the right thing and gives back a blob of bytes (possibly=
=C2=A0
> with media type information)".

Except that there is no "blob of bytes" that can be returned for a
private key in a PKCS#11 token.

For certificates, sure. But not keys.

--=20
dwmw2



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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjIzNjQ1WjAvBgkqhkiG9w0BCQQxIgQgjtTsf1q4Znm4TJyBfUdYQE9alLmsbEZNAOtS
HGgS7fcwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAGPP
qaXdjC9a+HN97oeqqZTD5vv+hT9B7U5FaMMwZejF1BMO3JV4opmsLAV+4wndiduvvdSqVGnxgcgh
rkOGZvnA/cUyz4L0yEjg8GYf3pNbsktl9SCH/wlMwBeGaFgzoZiXoUwyFdQiPMGbG75Xi0uqk3pV
+Q1MKmviKcwQX1rSXIpvL8ErRCgOn+d4vkRjZ/xwOCxAZGT8dwdoIyGhyUQlxO44VooMiDyrnTxr
nq8d2JrGNNXXdE7Lz1DX/L6yEviiiCgfYXVSLM6kq5maPMGCsaVde6/R5Qz1lKDW+Xqagni0qmiW
cbZXzMXmnsT8v2xWc1NXBFABQikDnrVJBMJ0eZE34W+HKzJo9CZ46sApQPvkM9jHgt9YC0EZmwW8
2Y5bZx5xeUopUQ0OgRsSTzy8Oe8xepoJtvG5V5n8NBrUFc/o6mKRp5TVqI8pQyBYureN8ky5DcdQ
t+mktactEdLUe8dp7ieEH2WvEgACHfQfZTUlTm+2UJkm/kgNNjsI5fL/uxUqal34/cGGzZgc+L69
cV+bUQa/q2A6zjY6YyS6VdAo6aNwH4xQlLX6VOH0hemucYEaeNQhJJCc1q+CiZ3digZJogxNEep5
Gyl7Xab2nhE9XehjsxP6lcJg/TNPMfpbEXV0jBUW2/r22aTwd1X3P1tr2cIhZ5PH3Ul8BZApAAAA
AAAA


--=-VCORYkEUiI8tyoef4rnk--


From nobody Mon Sep 26 15:43:52 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E6912B244; Mon, 26 Sep 2016 15:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.516
X-Spam-Level: 
X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXasDBvvUbuG; Mon, 26 Sep 2016 15:43:45 -0700 (PDT)
Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2AA12B041; Mon, 26 Sep 2016 15:43:45 -0700 (PDT)
Received: from [2001:8b0:10b:1:841b:5eff:0:f69] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1boeci-00050G-29; Mon, 26 Sep 2016 22:43:44 +0000
Message-ID: <1474929821.11690.66.camel@infradead.org>
From: David Woodhouse 
To: Sean Leonard , Watson Ladd 
Date: Mon, 26 Sep 2016 23:43:41 +0100
In-Reply-To: <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org>  <1474921558.45169.314.camel@infradead.org>   <1c555d80-991c-cca7-4018-be220cdddcdf@seantek.com>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-iw78fHFEfYACz2SE5vAy"
X-Mailer: Evolution 3.18.5.2 (3.18.5.2-1.fc23) 
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from  by bombadil.infradead.org. See http://www.infradead.org/rpr.html
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2016 22:43:47 -0000

--=-iw78fHFEfYACz2SE5vAy
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-09-26 at 14:55 -0700, Sean Leonard wrote:
> With S/MIME, I just use PKCS #12 like everyone else. And that workflow=C2=
=A0
> specifies the password mapping as UTF-16BE with NULL. :)

Right. PKCS#12 is preferable to PKCS#8 in this regard. (And thanks,
OpenSSL, for screwing that up for us.=C2=B9)

> When I use cryptographic tokens such as smart cards, the private key=C2=
=A0
> never leaves the token. So, there is no password: it's irrelevant.=C2=A0
> Sometimes the token is configured with a PIN, but the PIN is not the=C2=
=A0
> subject of this PKCS #8 EncryptedPrivateKeyInfo discussion.

Well... looking a bit further back in the thread (or indeed at
$SUBJECT), this was about application best practice. And I probably
*do* need to look at what to do with non-ASCII PINs and C_Login().

And again, I think the recommendation there needs to be the same as
PKCs#8: By all means *try* the local character set of the current
system, but make sure you also try UTF-8. I'll update my draft.

And perhaps I should make it abundantly clear that anyone who sets a
PIN in a legacy 8-bit character set, just like anyone who sets a PKCS#8
password in a legacy 8-bit character set, had better expect it to break
if they ever fall through a timewarp into the 21st century. Or travel a
few hundred miles.

You're right that it's a different problem, but it's actually *really*
similar.

--=20
dwmw2

=C2=B9 And yes, that time I *am* complaining, Viktor :)



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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw
ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT
AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0
aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK
Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0
eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO
bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q
n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS
slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO
AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI
MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu
Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O
BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y
MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh
2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw
5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07
v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y
klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy
CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD
o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2
B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6
jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p
eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve
JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp
MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc
MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk
ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z
x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+
tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m
liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO
2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f
wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t
w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR
Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK
FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU
IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV
HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD
VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn
SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j
cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu
Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V
kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL
cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo
WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8
edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc
CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq
hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE
CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE
AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y
ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU
I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw
s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK
ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4
h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW
9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M
MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk
x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1
KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm
2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E
BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE
FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G
CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD
VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G
A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy
dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov
L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK
AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A
YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs
IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh
zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj
TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg
hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTYwOTI2MjI0MzQxWjAvBgkqhkiG9w0BCQQxIgQgRV/kt0v3am0Zeju/NjHdXT7A+S3ltg2FHVK0
LqGKkoAwgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV
BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG
9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t
IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAIa4
BdZbo1OE5G9dhqeBj3mNlAq3z7eFxQZz/NQKaYtVe8c6tywHeOfI1b7FtF/suK8Igut2ue+JHuUq
KI9YXF+7B/jQfrk49ZhGuPF99CHJhWLwS+DLKp4MSYkwVgu7V2+G0gDBMefTULquetYDFFMW98/C
6HIwFhvSTmn9P2/wQ0EIDwD6fG7mTDq8zVFUkhBnyYr1tjvCdFDcDAELCq1Vfm3qMDDEVf2CBvJD
RpsVQQaljgPyjHa7c25GUFvkQvI+J3KNXbe3u+YcD4a6prUM9QeMjWdK7YyVdXw/mkrgL3MzFQUl
wNQr1CQFwbDaZBlYfDiw+BBMcMMx2TLlSyW7Qfc0kv22S3341C9P2OMOSZ1CFnHPBtx24KRtOLHc
GmBaEh0Fd7QOkqbIU4bj7cGCvmTGAEcAHjFdsY+ZwrnXzCDsaMUjwT6XD2dsSNn1lH8q6zjJsJCb
mZqCBAEm8ov1h3m5/WL0egnV3hPQ1F+Lb/dp4paXrf+KLoQz45wGM2OkvfqoBkqQhI6Dcrbd7Ij+
wcXGeCu6OmtsA/t8/quscfTq5SP3FZ0y5dOlPJavvdbG5rHX4JB0+0yTauLQFTn2277JT1oJEw6l
k5LW8saUiV87VONM9OM4LTZRw9hBmaBgPpjx1FNEpv8WSOqKgOc1h9ErVYfgVK9wdVatFOyRAAAA
AAAA


--=-iw78fHFEfYACz2SE5vAy--


From nobody Tue Sep 27 01:17:42 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D02612B40A; Tue, 27 Sep 2016 01:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level: 
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxivlYUR0Q3s; Tue, 27 Sep 2016 01:17:39 -0700 (PDT)
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C9812B409; Tue, 27 Sep 2016 01:17:38 -0700 (PDT)
Received: by mail-ua0-f181.google.com with SMTP id i25so4816810uab.0; Tue, 27 Sep 2016 01:17:38 -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:from:date:message-id :subject:to:cc; bh=YSaR4scVL21z9XbcN38L2vZaoXAH9re+ogqL0Ne97ZA=; b=O1ePBm47DIEICd6E8II+UsMx0iNCi8EEpY2N2/DSSzoUPyNZazPfMsKxGWG497ngM1 A+rdUf2a0FfiPDMaxYmvnbPYmsvmOkKMP8i3a5s76fJxs2yD05vXigdhr/MUXeEoKBOm GV7qMoXR4c0wrPKGVm02n923Dg/jFnXrb7TEUmcnu5YPVHtkLldcN7NJCxbI0hd/OLzO JZN9HX0/B75xRfywdFUYtt8BuCLELsAzPrenwx3Yrbp1IdSeBvJf23B1hE8pEMUsMZTX ETPLsTXGydoOH3c1kisVNTgCPDtFOtf2h4CMN6x7acDjNIPLyCH1UNCqgxd9hgHj3SC3 C6+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=YSaR4scVL21z9XbcN38L2vZaoXAH9re+ogqL0Ne97ZA=; b=WQnmOj3+4P0lMbmCP0GCU2Gv5E7Ps+7yNQptWsInCSuMgJ67CxYqpunVHkHnDmy8kT cGo4KPsFChUdugh9LWp96v7Oio/DN0lHere+fI3PBdVyIcUOV85wbZlvXPPjhKdoiAFD 2fPaUT/DPyz+urOK1+/ATy5zoPJZ1XTesaDNV2TGdEFWJpVciyibYBm1XQ2SMuXpVTxl 9kXCmcjOcSGcI7/ZMD1jrvVor8wqRcThiArjD63EXVyMn0nEL1sMbAN847Rmd6R60Yu3 bc6iuherWTmE7qYHKVpbkv6V1YBLcOdZL5XWSIzg5IdcfbE83yK6i4pisYo9bJK3u5Yc UyaQ==
X-Gm-Message-State: AA6/9RmoWBGBYzqNYTnlsLe5lrR7A4V7sqegugc6d6bATGFJU+G0+nHANSqjQQKBMyNZaLWMJQUVzCeaUbjBSQ==
X-Received: by 10.176.86.129 with SMTP id a1mr1803397uab.125.1474964197734; Tue, 27 Sep 2016 01:16:37 -0700 (PDT)
MIME-Version: 1.0
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.103.118.4 with HTTP; Tue, 27 Sep 2016 01:15:56 -0700 (PDT)
In-Reply-To: <1474925522.45169.337.camel@infradead.org>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org>
From: Nikos Mavrogiannopoulos 
Date: Tue, 27 Sep 2016 10:15:56 +0200
X-Google-Sender-Auth: JUTD0KCXt6cExuhv2EXEwdPAYek
Message-ID: 
To: David Woodhouse 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: spasm@ietf.org, Michael Richardson , Security Area Advisory Group , Sean Leonard 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2016 08:17:40 -0000

On Mon, Sep 26, 2016 at 11:32 PM, David Woodhouse  wrote:

>> This is surprising, because RFC 7512 Section 4.1. registers it as a
>> permanent URI scheme in the Permanent URI Schemes Registry. =:-O
>>
>> I thought that the whole point of a document called "The PKCS #11 URI
>> Scheme" would be to make PKCS #11 items accessible in URI protocol
>> slots, and conversely, to make URI protocol slots useful to PKCS
>> #11-consuming applications (in addition to other URI items such as http:
>> , ldap: , data: , etc.).
> Perhaps that was the intent; we would have to ask its authors. I cannot
> tell. But it doesn't seem stunningly useful in that form to me.,

I am not one of the authors, but I participated in the drafting of
that document. The intent was to provide a consistent way for
applications to access objects stored in PKCS#11 tokens. A URI (a
string of characters identifying a resource) seemed the appropriate
way to do it.

>>URIs are meant for Internet-accessing things

Not the PKCS#11 URI.

regards,
Nikos


From nobody Tue Sep 27 03:52:48 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264A412B0DE; Tue, 27 Sep 2016 03:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pk5KiVzFSBsd; Tue, 27 Sep 2016 03:52:38 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ECC12B0DD; Tue, 27 Sep 2016 03:52:37 -0700 (PDT)
Received: from [10.100.100.215] (unknown [195.149.146.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 537F56C05; Tue, 27 Sep 2016 12:52:29 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Tue, 27 Sep 2016 12:52:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <73F3E0AD-762D-4911-ACD6-4F513E51DD4C@edvina.net>
References: <1474280601.144982.263.camel@infradead.org>     <1474314996.144982.391.camel@infradead.org> <22611.1474382971@obiwan.sandelman.ca>  <1474387598.144982.452.camel@infradead.org> <6A89750D-EAF8-45A0-97AD-0137A2CB8352@seantek.com> <1474881447.45169.205.camel@infradead.org> <1eb84be4-1c5a-066e-f82d-1cd98c2dddd0@seantek.com> <1474919326.45169.305.camel@infradead.org> <6a3feeee-c575-8763-6e2a-ed9d07dbdfc0@seantek.com> <1474925522.45169.337.camel@infradead.org> 
To: Nikos Mavrogiannopoulos 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Michael Richardson , spasm@ietf.org, Security Area Advisory Group , Sean Leonard 
Subject: Re: [saag] [Spasm] Best practices for applications using X.509 client certificates
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2016 10:52:41 -0000

> On 27 Sep 2016, at 10:15, Nikos Mavrogiannopoulos  =
wrote:
>=20
> On Mon, Sep 26, 2016 at 11:32 PM, David Woodhouse =
 wrote:
>=20
>>> This is surprising, because RFC 7512 Section 4.1. registers it as a
>>> permanent URI scheme in the Permanent URI Schemes Registry. =3D:-O
>>>=20
>>> I thought that the whole point of a document called "The PKCS #11 =
URI
>>> Scheme" would be to make PKCS #11 items accessible in URI protocol
>>> slots, and conversely, to make URI protocol slots useful to PKCS
>>> #11-consuming applications (in addition to other URI items such as =
http:
>>> , ldap: , data: , etc.).
>> Perhaps that was the intent; we would have to ask its authors. I =
cannot
>> tell. But it doesn't seem stunningly useful in that form to me.,
>=20
> I am not one of the authors, but I participated in the drafting of
> that document. The intent was to provide a consistent way for
> applications to access objects stored in PKCS#11 tokens. A URI (a
> string of characters identifying a resource) seemed the appropriate
> way to do it.
>=20
>>> URIs are meant for Internet-accessing things
>=20
> Not the PKCS#11 URI.


RFC 3986 states:=20
"A Uniform Resource Identifier (URI) is a compact sequence of
   characters that identifies an abstract or physical resource.=E2=80=9D

In definition of a =E2=80=9Cresource=E2=80=9D it clearly says:
" A resource is not necessarily
      accessible via the Internet; e.g., human beings, corporations, and
      bound books in a library can also be resources.  Likewise,
      abstract concepts can be resources, such as the operators and
      operands of a mathematical equation, the types of a relationship
      (e.g., "parent" or "employee"), or numeric values (e.g., zero,
      one, and infinity).=E2=80=9D

/O=


From nobody Tue Sep 27 14:01:00 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4712B226 for ; Tue, 27 Sep 2016 14:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlT3WAOHC00k for ; Tue, 27 Sep 2016 14:00:56 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE1B12B4D2 for ; Tue, 27 Sep 2016 14:00:56 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id q42so21881726uaq.2 for ; Tue, 27 Sep 2016 14:00:55 -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:cc; bh=QLaMcdeOX1HmI11tP+hfs/KY0y+4h44vSLWfGIjgEDM=; b=hINGdS24uHYqo33UWWKNd42YkYMyqFratWH6tl57sQPcO1dJE7n5zLrlIUZwX0/fOT sgriBVMuBPDpvTr/8FvQ63dVReMqKRo59ByNaqG7SIkj/W96zzJUvikMViX5abgGwXFf TW44QB43OipQHqWux4pR/fmG+qZ4s26WNcYT3IqIw3dy8UmP1hrURgJy3XJk/9E6zBnT zndFQR2ckr9wCEtVQ5yFA+9AqaS0qRT3B0D5xF/oeZW1O+Re7iDohClQluhTLkn54DQw a0Z0edGVRRhiIU6GRM//VFMdxlayh217ro+/BwfjCQNn6uxSNFv0EvLmMMm3rjJrkw5f 3EMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=QLaMcdeOX1HmI11tP+hfs/KY0y+4h44vSLWfGIjgEDM=; b=Amwbu6JNltuwL0fxgrij4aSqZm57CftaQsMfj6/NCuwZ6dUcowN46AOzH0z6ROh92w jqtm2vq07VRV0yR+nUSKKnz0d1JJw+lJ2ukzlpuAdzfrX1mV7qCoUPtHEQgraJzui5dw jCoJmOIgDcmnbaWovKHAWCTzstuXfYgYR/BnxjW05OyKI2ZKDWqyqxEWYvVukHe95vyl JQE30YgQmC864oj7z1oNMTSEtqbC7swc85iRbBJz6UZ0DlewbWDzK6/A70VNahl/piqK /KR7DPutWWPpGhTWgSFZxJHpVIrvJYJht+6p9DPnTIenlwKD5J64eswlEphTYpba6e4Y sy0w==
X-Gm-Message-State: AA6/9RmfbsC8Q7MYpwwaibgd2SajXpHfeqkxjVLCfbvAQWkUtF5uOKux9JGa7UYRG0m1QorE9ZwblimyRoAE8g==
X-Received: by 10.176.84.65 with SMTP id o1mr4159230uaa.122.1475010055163; Tue, 27 Sep 2016 14:00:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.65.8 with HTTP; Tue, 27 Sep 2016 14:00:54 -0700 (PDT)
From: Kathleen Moriarty 
Date: Tue, 27 Sep 2016 17:00:54 -0400
Message-ID: 
To: "saag@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Alexey Melnikov 
Subject: [saag] SecEvent Charter
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2016 21:00:58 -0000

Hello,

A new working group has been proposed, SecEvent, that crosses between
the ART and security areas.  This builds off of SCIM work, also
leveraging OAuth, and will incorporate use of JWT from JOSE.  The
working group, if approved, will go into the security area and I've
agreed to AD it.  Please take a look at the charter under review:

https://datatracker.ietf.org/doc/charter-ietf-secevent/

And join the mailing list for discussion:
https://mailarchive.ietf.org/arch/search/?email_list=id-event

-- 

Best regards,
Kathleen


From nobody Tue Sep 27 17:38:48 2016
Return-Path: 
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEE912B0A9 for ; Tue, 27 Sep 2016 17:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-Cbn_k0A-xe for ; Tue, 27 Sep 2016 17:38:45 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0102.outbound.protection.outlook.com [104.47.34.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4F512B049 for ; Tue, 27 Sep 2016 17:38:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BsF9NBaE3dZGZZQ4DQd+VdNocQs7s/pni1tkmvxwvMo=; b=JHgTajDVCcF8m9ODL75h34hMz82x2phIR+O68OvGhMAcGM/ghc4YgpmeaYISOy89lh8tvAy/pko2vl4nQ3xQpnFD1Rk2GPt6NveRNEOcIr9Y2A6OsTNZUoGoGKS7m9hyeVbZ/SEDIdcWdk5D+DLtYxfE1g3OxFG6ofnqJPHN2Mo=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.6; Wed, 28 Sep 2016 00:38:44 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0649.013; Wed, 28 Sep 2016 00:38:44 +0000
From: Kent Watsen 
To: Kathleen Moriarty , "saag@ietf.org" 
Thread-Topic: [saag] SecEvent Charter
Thread-Index: AQHSGQJDO3rZz0eZYkqbuIjB7bxNjqCNzEIA
Date: Wed, 28 Sep 2016 00:38:44 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.1.160916
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: ba9639d9-5126-4b3b-040a-08d3e737cd3c
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 7:PlpOjIHFGlhX1mf3oLCoXl7TFJ2+P/yGElF+8Bl8sKNQtG/ngKUw/OeY6x6Y2Sh9pI9IqhfU3rIPVyY+fFPAMshVAJEA8ltg1E9DnpB09rCW4Y7yoCDt6q3Dq57NNTPD+wajjnZcw1kO8nMQLA42AVU+Z+hMzIQ77brkIprMcM5tW2rLfIXQN4tcOrm4v09rejgtahwcmu9tUbMXY6mc9jYHKYn/gUvkPiQp401pQyga4ed6rSuDDsoKsc9VULWDwtRYN6MbLS7aqvjeOGiKheXMldlKFvq/R21lSsnqto4CPhffXSMqx1O2WzYemBFMl1Yq3xYXjak+vd09WdA6gQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; 
x-forefront-prvs: 0079056367
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(189002)(199003)(83716003)(10400500002)(586003)(2501003)(122556002)(66066001)(19580395003)(305945005)(82746002)(7736002)(2950100002)(83506001)(11100500001)(7846002)(189998001)(87936001)(8666005)(36756003)(2906002)(4326007)(5660300001)(86362001)(50986999)(8936002)(106356001)(3660700001)(3280700002)(81166006)(3846002)(6116002)(8676002)(81156014)(102836003)(19580405001)(15975445007)(2900100001)(76176999)(54356999)(77096005)(5002640100001)(101416001)(106116001)(105586002)(5001770100001)(99286002)(68736007)(33656002)(4001350100001)(97736004)(92566002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <56C656ED2A652D4C94A258B4506F3E63@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2016 00:38:44.0510 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450
Archived-At: 
Cc: Alexey Melnikov 
Subject: Re: [saag] SecEvent Charter
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2016 00:38:48 -0000

DQpEaWQgYW55b25lIGNvbnNpZGVyIHRoZSBvdmVybGFwIGJldHdlZW4gdGhpcyBhbmQgZXZlbnQg
bm90aWZpY2F0aW9ucyBlZmZvcnQgaW4gdGhlIE5FVENPTkYgd29ya2luZyBncm91cD8NCg0KICBk
cmFmdC1pZXRmLW5ldGNvbmYtcmZjNTI3N2Jpcw0KICBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29u
Zi1ldmVudC1ub3RpZmljYXRpb25zDQogIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3Rp
Zg0KICBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoDQoNCkl0IG1heSBub3QgaGF2ZSB0aGUg
c2FtZSBmb2N1cywgYnV0IGl0IGNhbiBnZXQgdGhlIGpvYiBkb25lLCByaWdodD8NCg0KVGhhbmtz
LA0KS2VudA0KDQoNCk9uIDkvMjcvMTYsIDU6MDAgUE0sICJzYWFnIG9uIGJlaGFsZiBvZiBLYXRo
bGVlbiBNb3JpYXJ0eSIgPHNhYWctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga2F0aGxl
ZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgSGVsbG8sDQogICAgDQog
ICAgQSBuZXcgd29ya2luZyBncm91cCBoYXMgYmVlbiBwcm9wb3NlZCwgU2VjRXZlbnQsIHRoYXQg
Y3Jvc3NlcyBiZXR3ZWVuDQogICAgdGhlIEFSVCBhbmQgc2VjdXJpdHkgYXJlYXMuICBUaGlzIGJ1
aWxkcyBvZmYgb2YgU0NJTSB3b3JrLCBhbHNvDQogICAgbGV2ZXJhZ2luZyBPQXV0aCwgYW5kIHdp
bGwgaW5jb3Jwb3JhdGUgdXNlIG9mIEpXVCBmcm9tIEpPU0UuICBUaGUNCiAgICB3b3JraW5nIGdy
b3VwLCBpZiBhcHByb3ZlZCwgd2lsbCBnbyBpbnRvIHRoZSBzZWN1cml0eSBhcmVhIGFuZCBJJ3Zl
DQogICAgYWdyZWVkIHRvIEFEIGl0LiAgUGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBjaGFydGVy
IHVuZGVyIHJldmlldzoNCiAgICANCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9jaGFydGVyLWlldGYtc2VjZXZlbnQvDQogICAgDQogICAgQW5kIGpvaW4gdGhlIG1haWxpbmcg
bGlzdCBmb3IgZGlzY3Vzc2lvbjoNCiAgICBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy
Y2gvc2VhcmNoLz9lbWFpbF9saXN0PWlkLWV2ZW50DQogICAgDQogICAgLS0gDQogICAgDQogICAg
QmVzdCByZWdhcmRzLA0KICAgIEthdGhsZWVuDQogICAgDQogICAgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzYWFnIG1haWxpbmcgbGlzdA0KICAg
IHNhYWdAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3NhYWcNCiAgICANCg0K