From jbonneau@gmail.com Wed Feb 13 08:36:00 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C136321F8996 for ; Wed, 13 Feb 2013 08:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CavrSNJaqCxh for ; Wed, 13 Feb 2013 08:35:59 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5821F894E for ; Wed, 13 Feb 2013 08:35:56 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id o13so2215353qaj.19 for ; Wed, 13 Feb 2013 08:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=8mn3WdIclSCcec63Fme+3e603OGzim0dGitZUD70jKc=; b=MVQP8ONlLKyaRD/DWsiTrEgFiOQTkWG9/fBDzA+PF5ci13ZJeBpUCc0WKhmjill5a0 aOvO49Eh3YQ4uKFI/3Us6z4MxMRTzjRz/qwFels0I47Y/1my6dPm9yktxLdb28TEbs+n VETEmI/cnKEZPoAV523tnYeNT2i3haQHGPGEOj6lHFcERpicI7ZGwh1mPkY5UzSHsYUr WVj01cq3zX8v3cfsbaGNX8KUKasdoLNcCWujZaBxd4My+aT2Md+/ZfmLIPXLF7Q6J3T3 RmWEAWXGJAB3LaS9O1nQqTg2TT7WiHNbfP+GMISPSeTL4K/A/zE4lK/6T7vV8jnzn0Be 7Xcg== X-Received: by 10.229.111.205 with SMTP id t13mr1794689qcp.152.1360773355667; Wed, 13 Feb 2013 08:35:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Wed, 13 Feb 2013 08:35:35 -0800 (PST) From: Joseph Bonneau Date: Wed, 13 Feb 2013 08:35:35 -0800 Message-ID: To: therightkey@ietf.org Content-Type: multipart/alternative; boundary=0023544717a87bffd904d59dbca6 Subject: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:36:00 -0000 --0023544717a87bffd904d59dbca6 Content-Type: text/plain; charset=UTF-8 Greetings all, I'd like to share a proposal with this list that I've been working on: http://www.secure-links.org/ My goal is to enable a lightweight, incrementally deployable way to distribute security policies for servers users have never visited. I think that links in HTML are a natural place to do this, because the act of clicking a link is a de facto statement that the user trusts the enclosing to send them to a new destination. S-links can be part of an "end-to-end" key pinning solution as follows: (a) Browsers ship with some hard-coded key pins for the the largest sites on the web. This pins connections to popular "hub" sites like search engines, social networks, link shorteners, etc. (b) These sites can observe sites asserting key pins around the web (ie through HPKP records, DANE, or other mechanisms) and serve s-links to such sites. Users find the majority of new sites to visit through these hubs, and their initial connections to them are secured through s-links. (c) After the (s-link protected) initial connection to a new site, browsers can negotiate persistent key pins through HPKP or another continuity-based protocol. Without something like s-links, preloaded pins can't scale to the web, and continuity-based protocols suffer from a vulnerable initial connection. I think that building a mechanism to deliver pins "in-band" through web linking can close the gap in the common case. I'd also like to point out that this is a flexible mechanism with a similar end-to-end story for other protocols (I mentioned other possible directives besides key pins). For example, to achieve incremental deployment for Certificate Transparency (ie, start hard-failing before every CA has opted in) we could start with browsers pre-loading a list of "CT mandatory" sites. If these sites are major web hubs, they can use s-links to indicate other "CT mandatory" sites. If we then bolted on a "CT mandatory" bit into a continuity-based protocol, many sites could get CT protection before CT is universally deployed. I'd very much like feedback on the proposal and how it can fit in with others. There are a number of tricky issues here with the browser's same-origin policy that I've gotten some feedback from the Chromium project on, and I've tried to keep an extensive FAQ on the web page with issues that have come up. Cheers, Joe --0023544717a87bffd904d59dbca6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Greetings all,

I'd like to share a proposal with thi= s list that I've been working on:=C2=A0http://www.secure-links.org/

My goal = is to enable a lightweight, incrementally deployable way to distribute secu= rity policies for servers users have never visited. I think that links in H= TML are a natural place to do this, because the act of clicking a link is a= de facto statement that the user trusts the enclosing to send them to a ne= w destination.

S-links can be part of an "end-to-end" key pi= nning solution as follows:=C2=A0
(a) Browsers ship with some hard= -coded key pins for the the largest sites on the web. This pins connections= to popular "hub" sites like search engines, social networks, lin= k shorteners, etc.
(b) These sites can observe sites asserting key pins around the web (i= e through HPKP records, DANE, or other mechanisms) and serve s-links to suc= h sites. Users find the majority of new sites to visit through these hubs, = and their initial connections to them are secured through s-links.
(c) After the (s-link protected) initial connection to a new site, bro= wsers can negotiate persistent key pins through HPKP or another continuity-= based protocol.

Without something like s-links, pr= eloaded pins can't scale to the web, and continuity-based protocols suf= fer from a vulnerable initial connection. I think that building a mechanism= to deliver pins "in-band" through web linking can close the gap = in the common case.

I'd also like to point out that this is a flexible = mechanism with a similar end-to-end story for other protocols (I mentioned = other possible directives besides key pins). For example, to achieve increm= ental deployment for Certificate Transparency (ie, start hard-failing befor= e every CA has opted in) we could start with browsers pre-loading a list of= "CT mandatory" sites. If these sites are major web hubs, they ca= n use s-links to indicate other "CT mandatory" sites. If we then = bolted on a "CT mandatory" bit into a continuity-based protocol, = many sites could get CT protection before CT is universally deployed.

I'd very much like feedback on the proposal and how= it can fit in with others. There are a number of tricky issues here with t= he browser's same-origin policy that I've gotten some feedback from= the Chromium project on, and I've tried to keep an extensive FAQ on th= e web page with issues that have come up.

Cheers,

Joe
--0023544717a87bffd904d59dbca6-- From stephen.farrell@cs.tcd.ie Wed Feb 13 17:53:41 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4C221E80C6 for ; Wed, 13 Feb 2013 17:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dejlxr1VffT2 for ; Wed, 13 Feb 2013 17:53:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 55B1D21F86AB for ; Wed, 13 Feb 2013 17:53:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 36920BE32; Thu, 14 Feb 2013 01:53:15 +0000 (GMT) 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 jhZnJ0+IzPPy; Thu, 14 Feb 2013 01:53:13 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.45.52.203]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F121BE2F; Thu, 14 Feb 2013 01:53:13 +0000 (GMT) Message-ID: <511C4389.3060904@cs.tcd.ie> Date: Thu, 14 Feb 2013 01:53:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joseph Bonneau References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 01:53:41 -0000 Hi Joe, Ok I'll bite:-) I think I see what you're trying to do and agree its worth exploring. But I'm not convinced yet. Can you explain more about why you think that closing this particular gap is useful? For example, ISTM that a lot of bad URLs that are de-referenced are received in spam that won't contain this, or are in hrefs on pages loaded from sites that won't use this, or that attacks are trying to trick users into accepting a bogus version of a site that they have already visited (e.g. a bank). One way to answer this would be to show how this'd usefully mitigate some real current risk, but there may be other or better ways to answer too. (FWIW, I hope the answer ins't to the effect that UAs need to go through some gatekeeper site before going anywhere else, but I expect that'll not be your answer.) I'd also have some questions about how, e.g. re-directs etc but the above probably comes first. Cheers, S. PS: Your site has a mailing list/google group. Be great if an archive of that were visible, since maybe you've answered the above question already, but I don't have enough google-foo to know how to find that;-) On 02/13/2013 04:35 PM, Joseph Bonneau wrote: > Greetings all, > > I'd like to share a proposal with this list that I've been working on: > http://www.secure-links.org/ > > My goal is to enable a lightweight, incrementally deployable way to > distribute security policies for servers users have never visited. I think > that links in HTML are a natural place to do this, because the act of > clicking a link is a de facto statement that the user trusts the enclosing > to send them to a new destination. > > S-links can be part of an "end-to-end" key pinning solution as follows: > (a) Browsers ship with some hard-coded key pins for the the largest sites > on the web. This pins connections to popular "hub" sites like search > engines, social networks, link shorteners, etc. > (b) These sites can observe sites asserting key pins around the web (ie > through HPKP records, DANE, or other mechanisms) and serve s-links to such > sites. Users find the majority of new sites to visit through these hubs, > and their initial connections to them are secured through s-links. > (c) After the (s-link protected) initial connection to a new site, browsers > can negotiate persistent key pins through HPKP or another continuity-based > protocol. > > Without something like s-links, preloaded pins can't scale to the web, and > continuity-based protocols suffer from a vulnerable initial connection. I > think that building a mechanism to deliver pins "in-band" through web > linking can close the gap in the common case. > > I'd also like to point out that this is a flexible mechanism with a similar > end-to-end story for other protocols (I mentioned other possible directives > besides key pins). For example, to achieve incremental deployment for > Certificate Transparency (ie, start hard-failing before every CA has opted > in) we could start with browsers pre-loading a list of "CT mandatory" > sites. If these sites are major web hubs, they can use s-links to indicate > other "CT mandatory" sites. If we then bolted on a "CT mandatory" bit into > a continuity-based protocol, many sites could get CT protection before CT > is universally deployed. > > I'd very much like feedback on the proposal and how it can fit in with > others. There are a number of tricky issues here with the browser's > same-origin policy that I've gotten some feedback from the Chromium project > on, and I've tried to keep an extensive FAQ on the web page with issues > that have come up. > > Cheers, > > Joe > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From jbonneau@gmail.com Wed Feb 13 18:55:52 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5341821F842B for ; Wed, 13 Feb 2013 18:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fAtPRic2uzL for ; Wed, 13 Feb 2013 18:55:51 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1452121E80C8 for ; Wed, 13 Feb 2013 18:55:50 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id 1so867766qee.12 for ; Wed, 13 Feb 2013 18:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YHahOur/STxT5jHYSqF2DDKgP08ixkUF/qidJ0KyEW0=; b=yA77mmKUMZTXXudQchI6Hyrl3sdtoCcESTKenDgXeJ/F8HQUxZasHl6kUsxi9Aqxy0 a8Cw/X4toYZtSNJweEP3vUBgHaOBRpB0MXyD+TRemAbJcgpXfuu85pZih7rLIIglnwJl FdaaDp0QezPY6WmoZn+/3phcxw+IwXic4p7YpMMnLwyqJhno7xtoSrvfd1d0lmRITqVT Gkou4tExHD0aqXHzKEAXySFH5B45abwQvwY3eA+Vkys8FZkKnOJVkw9JaDmiYM8DoIgZ OPas5WJ6KPGB5OrjlA/hUrHyj4q9k0CQk7faZLZXiNrMlc7eZc/wKtzP5VbknhPpAACe VuiQ== X-Received: by 10.224.39.210 with SMTP id h18mr9312315qae.15.1360810550443; Wed, 13 Feb 2013 18:55:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Wed, 13 Feb 2013 18:55:29 -0800 (PST) In-Reply-To: <511C4389.3060904@cs.tcd.ie> References: <511C4389.3060904@cs.tcd.ie> From: Joseph Bonneau Date: Wed, 13 Feb 2013 21:55:29 -0500 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf306f796c77409804d5a6651a Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 02:55:52 -0000 --20cf306f796c77409804d5a6651a Content-Type: text/plain; charset=UTF-8 Hi Stephen, Thanks for biting :-) > For example, ISTM that a lot of bad URLs that are de-referenced are > received in spam that won't contain this, or are in hrefs on pages > loaded from sites that won't use this, or that attacks are trying > to trick users into accepting a bogus version of a site that they > have already visited (e.g. a bank). > Not attempting to deal with spam or phishing. Phishy sites will probably not use TLS anyways. I also agree that there will be tons of insecure links all over the web and that this is not a complete solution but an incrementally deployable measure that I claim can protect many connections. The claim is based on the hunch that a large percentage of *initial* connections to new sites happen via hyperlinks served by small number of hubs: namely webmail, search engines, social networks, link shorteners. If you can secure these initial connections relatively cheaply it's a win. > I hope the answer ins't to the effect that UAs > need to go through some gatekeeper site before going anywhere else, > but I expect that'll not be your answer.) > This is exactly the motivation for this proposal: I don't want UAs to go through any *new* gatekeeper or add a blocking lookup to a trusted authority to get to the right destination securely. I want to leverage the fact that the vast majority of users already go through gatekeepers from a small set before going anywhere else. Perhaps this isn't everybody's ideal of how the web should work, but since that's the reality I think it's useful to use these gatekeepers to distribute security information. Websites are also far more agile as trust anchors than almost anything else under consideration. Some users know how to change search engines but virtually zero have any idea what a CA is. I grant that s-links on their own won't solve things so I'd encourage the proposal not to be considered in isolation. S-links are fundamentally dependent on some other protocol gaining non-trivial deployment (where non-triivial means that the list of supporting sites can't be hard-coded into the browser). But thinking ahead, s-links make the deployment story for HPKP, CT, or lots of other proposals much more believable to me so I think there's value in developing it alongside them. S-links will always be useful in an HPKP world, and for CT until 100% deployment (at CAs) is achieved. As for the mailing list-I'll enable the archive when there are substantive posts to the mailing list. It's only 3 weeks old though and is content-less so far :-) Cheers, Joe --20cf306f796c77409804d5a6651a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen,

Thanks for biting :-)
=C2=A0
For example, ISTM that a lot of bad URLs that are de-referenced are
received in spam that won't contain this, or are in hrefs on pages
loaded from sites that won't use this, or that attacks are trying
to trick users into accepting a bogus version of a site that they
have already visited (e.g. a bank).

Not= attempting to deal with spam or phishing. Phishy sites will probably not u= se TLS anyways.

I also agree that there will be to= ns of insecure links all over the web and that this is not a complete solut= ion but an incrementally deployable measure that I claim can protect many c= onnections. The claim is based on the hunch that a large percentage of *ini= tial* connections to new sites happen via hyperlinks served by small number= of hubs: namely webmail, search engines, social networks, link shorteners.= If you can secure these initial connections relatively cheaply it's a = win.
=C2=A0
I hope the answer ins't= to the effect that UAs
need to go through some gatekeeper site before going anywhere else,
but I expect that'll not be your answer.)

This is exactly the motivation for this proposal: I don't want U= As to go through any *new* gatekeeper or add a blocking lookup to a trusted= authority to get to the right destination securely. I want to leverage the= fact that the vast majority of users already go through gatekeepers from a= small set before going anywhere else. Perhaps this isn't everybody'= ;s ideal of how the web should work, but since that's the reality I thi= nk it's useful to use these gatekeepers to distribute security informat= ion. Websites are also far more agile as trust anchors than almost anything= else under consideration. Some users know how to change search engines but= virtually zero have any idea what a CA is.

I grant that s-links on their own won't solve thing= s so I'd encourage the proposal not to be considered in isolation. S-li= nks are fundamentally dependent on some other protocol gaining non-trivial = deployment (where non-triivial means that the list of supporting sites can&= #39;t be hard-coded into the browser). But thinking ahead, s-links make the= deployment story for HPKP, CT, or lots of other proposals much more believ= able to me so I think there's value in developing it alongside them. S-= links will always be useful in an HPKP world, and for CT until 100% deploym= ent (at CAs) is achieved.=C2=A0

As for the mailing list-I'll enable the archive whe= n there are substantive posts to the mailing list. It's only 3 weeks ol= d though and is content-less so far :-)

Cheers,

Joe
--20cf306f796c77409804d5a6651a-- From rlb@ipv.sx Wed Feb 13 19:03:45 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925D521F86BE for ; Wed, 13 Feb 2013 19:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEPYQZlCDUrS for ; Wed, 13 Feb 2013 19:03:44 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9409321F86BC for ; Wed, 13 Feb 2013 19:03:44 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wd20so1953955obb.23 for ; Wed, 13 Feb 2013 19:03:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ikW/gNdruGyBpmCHwle8QfSKwpB6bcmhUhW1ETektvU=; b=W+Ml6VBE2uJp3Zp0faPPFXseXT2w/gbJVabsuplAhHAHvKYqDMKcqxiVV9LItlY+st CVM0AMyxGxItrLzyknCCGXmggEJpD0UqZZUM9RiOUKM1p3+V7P4jGiiePB8E0pM4xeua 3ZjaQTPAdJ2QKmwfvcazTMkIMnAuQPYC9NEg742dc1P1CY4/LAcF7JOtwcaCAuCdOSo0 eAOIfwzoWjvwsrX+Qm2+P5zPgnzcm8ZfagVT7eUjsx/5R6d8/HIuVK2NOniuWlLUG92K 0mJ+U++YqgakqXL0Tg40Qa4se+a0psDE1Vnnn0JobkMujn2jiGT2VVwP7SXQh9HHoAo9 jIWg== MIME-Version: 1.0 X-Received: by 10.60.171.175 with SMTP id av15mr18191488oec.75.1360811023920; Wed, 13 Feb 2013 19:03:43 -0800 (PST) Received: by 10.60.59.163 with HTTP; Wed, 13 Feb 2013 19:03:43 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <511C4389.3060904@cs.tcd.ie> Date: Wed, 13 Feb 2013 22:03:43 -0500 Message-ID: From: Richard Barnes To: Joseph Bonneau Content-Type: multipart/alternative; boundary=bcaec54d43eaafee2804d5a681ee X-Gm-Message-State: ALoCoQmNOid9wOK1btPdqOM8kYG4G8N/Zy/Jw5bvr2kjzmB5qAjkLc+Mi6MaC8wAD0LharTe01TF Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 03:03:45 -0000 --bcaec54d43eaafee2804d5a681ee Content-Type: text/plain; charset=ISO-8859-1 Hi Joseph, I believe some ideas of this character have been discussed in the W3C WebAppSec WG. http://www.w3.org/2011/webappsec/ Cheers, --Richard On Wednesday, February 13, 2013, Joseph Bonneau wrote: > Hi Stephen, > > Thanks for biting :-) > > >> For example, ISTM that a lot of bad URLs that are de-referenced are >> received in spam that won't contain this, or are in hrefs on pages >> loaded from sites that won't use this, or that attacks are trying >> to trick users into accepting a bogus version of a site that they >> have already visited (e.g. a bank). >> > > Not attempting to deal with spam or phishing. Phishy sites will probably > not use TLS anyways. > > I also agree that there will be tons of insecure links all over the web > and that this is not a complete solution but an incrementally deployable > measure that I claim can protect many connections. The claim is based on > the hunch that a large percentage of *initial* connections to new sites > happen via hyperlinks served by small number of hubs: namely webmail, > search engines, social networks, link shorteners. If you can secure these > initial connections relatively cheaply it's a win. > > >> I hope the answer ins't to the effect that UAs >> need to go through some gatekeeper site before going anywhere else, >> but I expect that'll not be your answer.) >> > > This is exactly the motivation for this proposal: I don't want UAs to go > through any *new* gatekeeper or add a blocking lookup to a trusted > authority to get to the right destination securely. I want to leverage the > fact that the vast majority of users already go through gatekeepers from a > small set before going anywhere else. Perhaps this isn't everybody's ideal > of how the web should work, but since that's the reality I think it's > useful to use these gatekeepers to distribute security information. > Websites are also far more agile as trust anchors than almost anything else > under consideration. Some users know how to change search engines but > virtually zero have any idea what a CA is. > > I grant that s-links on their own won't solve things so I'd encourage the > proposal not to be considered in isolation. S-links are fundamentally > dependent on some other protocol gaining non-trivial deployment (where > non-triivial means that the list of supporting sites can't be hard-coded > into the browser). But thinking ahead, s-links make the deployment story > for HPKP, CT, or lots of other proposals much more believable to me so I > think there's value in developing it alongside them. S-links will always be > useful in an HPKP world, and for CT until 100% deployment (at CAs) is > achieved. > > As for the mailing list-I'll enable the archive when there are substantive > posts to the mailing list. It's only 3 weeks old though and is content-less > so far :-) > > Cheers, > > Joe > --bcaec54d43eaafee2804d5a681ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Joseph,

I believe some ideas of this character have b= een discussed in the W3C WebAppSec WG. =A0
http://www.w3.org/2011/webappsec/

Cheers,
--Richard

On Wednesday, February 13, = 2013, Joseph Bonneau wrote:
Hi Stephen,<= div>
Thanks for biting :-)
=A0=
For example, ISTM that a lot of bad URLs that are de-referenced are
received in spam that won't contain this, or are in hrefs on pages
loaded from sites that won't use this, or that attacks are trying
to trick users into accepting a bogus version of a site that they
have already visited (e.g. a bank).

Not= attempting to deal with spam or phishing. Phishy sites will probably not u= se TLS anyways.

I also agree that there will be to= ns of insecure links all over the web and that this is not a complete solut= ion but an incrementally deployable measure that I claim can protect many c= onnections. The claim is based on the hunch that a large percentage of *ini= tial* connections to new sites happen via hyperlinks served by small number= of hubs: namely webmail, search engines, social networks, link shorteners.= If you can secure these initial connections relatively cheaply it's a = win.
=A0
I hope the answer ins't to= the effect that UAs
need to go through some gatekeeper site before going anywhere else,
but I expect that'll not be your answer.)

This is exactly the motivation for this proposal: I don't want U= As to go through any *new* gatekeeper or add a blocking lookup to a trusted= authority to get to the right destination securely. I want to leverage the= fact that the vast majority of users already go through gatekeepers from a= small set before going anywhere else. Perhaps this isn't everybody'= ;s ideal of how the web should work, but since that's the reality I thi= nk it's useful to use these gatekeepers to distribute security informat= ion. Websites are also far more agile as trust anchors than almost anything= else under consideration. Some users know how to change search engines but= virtually zero have any idea what a CA is.

I grant that s-links on their own won't solve thing= s so I'd encourage the proposal not to be considered in isolation. S-li= nks are fundamentally dependent on some other protocol gaining non-trivial = deployment (where non-triivial means that the list of supporting sites can&= #39;t be hard-coded into the browser). But thinking ahead, s-links make the= deployment story for HPKP, CT, or lots of other proposals much more believ= able to me so I think there's value in developing it alongside them. S-= links will always be useful in an HPKP world, and for CT until 100% deploym= ent (at CAs) is achieved.=A0

As for the mailing list-I'll enable the archive whe= n there are substantive posts to the mailing list. It's only 3 weeks ol= d though and is content-less so far :-)

Cheers,

Joe
--bcaec54d43eaafee2804d5a681ee-- From jbonneau@gmail.com Wed Feb 13 19:17:09 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8EF21F8886 for ; Wed, 13 Feb 2013 19:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlWvurKn0dC8 for ; Wed, 13 Feb 2013 19:17:08 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 500FB21F8788 for ; Wed, 13 Feb 2013 19:17:08 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id j34so699498qco.23 for ; Wed, 13 Feb 2013 19:17:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xkty3VK4LZECA613KCC2U4NqtPciFDvHdchBasb7v4E=; b=BaDuMRYw+pttxRb7zHlxW0AgeofEzpbSP6L9CbOaXonY6vJJZGuFBNvPItJOLhoQmI ETpu2fNuLjSk5e78I7AXddkolKlx6EEfbLpZ0awTNyHf9kYzSYjWxuAkTetqCY3MLZ8Y svaWz4HN/fSvNpNCSURXz4AmKUKSl5Ofj77LOBbXJ6mIFJsGiRttQVrf76x0cU+VOxI4 kw9yUg7VgwWeogTm11oIDYzWLHjzRL/esr6i9koEi3e3ijvyHz3/mzcP4x8yIcqVnNtr nOpQru1a8vwOkMHtbVHc+zv7WAKFs0O3VaUAWYCFLs0ju50Sbp/6FV7PH3Ebya19AXZ3 DcMw== X-Received: by 10.224.39.210 with SMTP id h18mr9331207qae.15.1360811827674; Wed, 13 Feb 2013 19:17:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Wed, 13 Feb 2013 19:16:47 -0800 (PST) In-Reply-To: References: <511C4389.3060904@cs.tcd.ie> From: Joseph Bonneau Date: Wed, 13 Feb 2013 22:16:47 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=20cf306f796c983c9004d5a6b182 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 03:17:09 -0000 --20cf306f796c983c9004d5a6b182 Content-Type: text/plain; charset=UTF-8 > I believe some ideas of this character have been discussed in the W3C > WebAppSec WG. > http://www.w3.org/2011/webappsec/ Can you point to anything more specific? I discussed s-links via email with Adam Barth who's a CSP editor and it didn't seem that this has been extensively discussed by the WebAppSec WG... The only thing I can think of is discussion about enabling CSP to require that the same cert is presented for all page resources, which I believe didn't make the spec due to origin contamination problems. S-links, by the way, has the same issue unless a persistent key pin (or other persistent security upgrade) is immediately received, as discussed on the s-links site-this is a very important subtlety. Cheers, Joe --20cf306f796c983c9004d5a6b182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believ= e some ideas of this character have been discussed in the W3C WebAppSec WG.= =C2=A0
http://www.= w3.org/2011/webappsec/
=C2=A0
Can you point = to anything more specific? I discussed s-links via email with Adam Barth wh= o's a CSP editor and it didn't seem that this has been extensively = discussed by the WebAppSec WG...

The only thing I can think of is discussion about enabl= ing CSP to require that the same cert is presented for all page resources, = which I believe didn't make the spec due to origin contamination proble= ms. S-links, by the way, has the same issue unless a persistent key pin (or= other persistent security upgrade) is immediately received, as discussed o= n the s-links site-this is a very important subtlety.

Cheers,

Joe

--20cf306f796c983c9004d5a6b182-- From rlb@ipv.sx Wed Feb 13 19:30:23 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBF821E80D2 for ; Wed, 13 Feb 2013 19:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouk7mlB24w8U for ; Wed, 13 Feb 2013 19:30:22 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5C221E80D0 for ; Wed, 13 Feb 2013 19:30:21 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id o6so2101240oag.32 for ; Wed, 13 Feb 2013 19:30:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7IeizL2bXsJsVVCRBj7iXcJoI4vGsjogiHn/qXgQaas=; b=Mw1OPbIUNFyS/FE+PWxa94MyWDBtZhqQdBnNuUVABzRGbP+yZi58t2GG8A8SvH1P+K UjI9Rjy/CvZhQE9/5R8gIhPNFJYbQjgABWbybcVci00j8fWj98LrjqtY2zin8vc05Y+T DcCZlmAmgoQcdjP9bhqwgrE7h9Uq8l7CAqEAfg8PxaZv6Wn/qNKbnAsNIfusUUxFEl7z yxroH9cFKHopR49wk5KW23fJJPNz+Oo4gv8PQgiqrSsA/082rFe4+v4MX7lsj8xhDLVj Zk9a9DerBvogovtqeJc3QpiP6+vR8sBu03IUVbi7oJfQwBSS874hS9Gexne4ijrzfGlN Cy0A== MIME-Version: 1.0 X-Received: by 10.182.146.13 with SMTP id sy13mr18378769obb.45.1360812621354; Wed, 13 Feb 2013 19:30:21 -0800 (PST) Received: by 10.60.59.163 with HTTP; Wed, 13 Feb 2013 19:30:21 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <511C4389.3060904@cs.tcd.ie> Date: Wed, 13 Feb 2013 22:30:21 -0500 Message-ID: From: Richard Barnes To: Joseph Bonneau Content-Type: multipart/alternative; boundary=f46d04462b6ee6d5e404d5a6e075 X-Gm-Message-State: ALoCoQk8K7emTacm2rzmue6gtWxEk/Ws7zh0z1fAw6ZC3ByQ6quHdUuCfPkUWF23PrtUnsdz+BZR Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 03:30:23 -0000 --f46d04462b6ee6d5e404d5a6e075 Content-Type: text/plain; charset=ISO-8859-1 Well, I may be mistaken, or I may have mis-skimmed your proposal. To be more concrete: At the WebAppSec / WebCrypto meeting in November, it was mentioned (by Brad Hill IIRC) that one of the things that WebAppSec might be looking into after CSP would be link-based assertions. The example I remember is to attach a digest of the destination resource to a link, so that, e.g., if a third-party script were compromised, it could be recognized. Seems slightly different, but still related. In any case, might not hurt to ping the WebAppSec list as well as this one. Cheers, --Richard On Wednesday, February 13, 2013, Joseph Bonneau wrote: > > I believe some ideas of this character have been discussed in the W3C >> WebAppSec WG. >> http://www.w3.org/2011/webappsec/ > > > Can you point to anything more specific? I discussed s-links via email > with Adam Barth who's a CSP editor and it didn't seem that this has been > extensively discussed by the WebAppSec WG... > > The only thing I can think of is discussion about enabling CSP to require > that the same cert is presented for all page resources, which I believe > didn't make the spec due to origin contamination problems. S-links, by the > way, has the same issue unless a persistent key pin (or other persistent > security upgrade) is immediately received, as discussed on the s-links > site-this is a very important subtlety. > > Cheers, > > Joe > > --f46d04462b6ee6d5e404d5a6e075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I may be mistaken, or I may have mis-skimmed your proposal.=A0
To be more concrete: At the WebAppSec / WebCrypto meeting in N= ovember, it was mentioned (by Brad Hill IIRC) that one of the things that= =A0WebAppSec might be looking into a= fter CSP would be link-based assertions. The example I remember is to attac= h a digest of the destination resource to a link, so that, e.g., if a third= -party script were compromised, it could be recognized. Seems slightly diff= erent, but still related. =A0=A0

In any case, might not hurt to ping the=A0WebAppSec list as well as this o= ne.=A0

<= div>Cheers,
--Richard

On Wednesday, February 13, 2013, Joseph Bonneau wrote:

I believe some ideas of this character have been discussed in the W3C = WebAppSec WG. =A0
http://www.= w3.org/2011/webappsec/
=A0
Can you point to = anything more specific? I discussed s-links via email with Adam Barth who&#= 39;s a CSP editor and it didn't seem that this has been extensively dis= cussed by the WebAppSec WG...

The only thing I can think of is discussion about enabl= ing CSP to require that the same cert is presented for all page resources, = which I believe didn't make the spec due to origin contamination proble= ms. S-links, by the way, has the same issue unless a persistent key pin (or= other persistent security upgrade) is immediately received, as discussed o= n the s-links site-this is a very important subtlety.

Cheers,

Joe

--f46d04462b6ee6d5e404d5a6e075-- From jbonneau@gmail.com Wed Feb 13 19:40:08 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE40A21E80CD for ; Wed, 13 Feb 2013 19:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb5zx7vw2tIj for ; Wed, 13 Feb 2013 19:40:08 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 589A721F85D2 for ; Wed, 13 Feb 2013 19:40:07 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id hg5so852064qab.6 for ; Wed, 13 Feb 2013 19:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=YOO+1Jb3LLNwPHxy++bfMWq/pXowJiHBwZ7i8TGwKIg=; b=x+/5A85SZdQo+N9dJ6tWAV3pZfuuc28zZrG6PC9jXS+hvnKXcjF6I4qFXxnkgkaLhF FHB5Ciyd4yMmCbrp3dH9wRjuNrYF5AByvfwbHeHULzMQ+U6N/FjlL3IyTwgwEa6Wmak8 PVjH9n4ZUnHMCgWJeZdhDzr6yD2Yjwc9QttDwLl7HL0/L1nxjKUHoz6UAYAzaDWH1abu hvuqM4ERuPWBzEMLXdoO4joVka+Gz7PO5AEUWQaVt0XaeoO0boQpRPAP3Uudy10awnOr Or1iKbyItFep9zukQ5A5InmKjX7pwuf8Rzb85Ik0xGcPiVrqQtoHlQxBTiExY7C92/u0 viKQ== X-Received: by 10.49.59.131 with SMTP id z3mr11009565qeq.1.1360813206518; Wed, 13 Feb 2013 19:40:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Wed, 13 Feb 2013 19:39:46 -0800 (PST) In-Reply-To: References: <511C4389.3060904@cs.tcd.ie> From: Joseph Bonneau Date: Wed, 13 Feb 2013 22:39:46 -0500 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b677bf4c7bc6f04d5a703a4 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 03:40:08 -0000 --047d7b677bf4c7bc6f04d5a703a4 Content-Type: text/plain; charset=UTF-8 > > To be more concrete: At the WebAppSec / WebCrypto meeting in November, it > was mentioned (by Brad Hill IIRC) that one of the things that WebAppSec > might be looking into after CSP would be link-based assertions. The example > I remember is to attach a digest of the destination resource to a link, so > that, e.g., if a third-party script were compromised, it could be > recognized. Seems slightly different, but still related. > Ah, I see where you were going now. I mentioned this on the s-links FAQ-including content hashes in links has indeed been proposed many times. This solves a completely different problem-including content from an untrusted mirror, compared to of securely getting TLS security info for a new domain that you'll have some future interaction with. I left it out of s-links (though it could certainly be added as an additional directives) because I think it is such a different problem. In any case, might not hurt to ping the WebAppSec list as well as this one. > Will do. My thinking is though, there are lots of web security details to get right here (and hopefully the trickiest ones came out of the Chromium mailing list) but I'd like to get higher-level feedback from people interested in bigger-picture TLS issues about whether or not s-links are a desirable building block before diving into that level of detail. Cheers, Joe --047d7b677bf4c7bc6f04d5a703a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To be more c= oncrete: At the WebAppSec / WebCrypto meeting in November, it was mentioned= (by Brad Hill IIRC) that one of the things that=C2=A0WebAppSec might be lo= oking into after CSP would be link-based assertions. The example I remember= is to attach a digest of the destination resource to a link, so that, e.g.= , if a third-party script were compromised, it could be recognized. Seems s= lightly different, but still related. =C2=A0=C2=A0

Ah, I see where you were going now. I ment= ioned this on the s-links FAQ-including content hashes in links has indeed = been proposed many times. This solves a completely different problem-includ= ing content from an untrusted mirror, compared to of securely getting TLS s= ecurity info for a new domain that you'll have some future interaction = with. I left it out of s-links (though it could certainly be added as an ad= ditional directives) because I think it is such a different problem.

= In any case, might not hurt to ping the=C2=A0WebAppSec l= ist as well as this one.=C2=A0

Will do. My thinking is though, there are = lots of web security details to get right here (and hopefully the trickiest= ones came out of the Chromium mailing list) but I'd like to get higher= -level feedback from people interested in bigger-picture TLS issues about w= hether or not s-links are a desirable building block before diving into tha= t level of detail.

Cheers,

Joe
--047d7b677bf4c7bc6f04d5a703a4-- From leifj@mnt.se Thu Feb 14 00:54:27 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE97C21F8488 for ; Thu, 14 Feb 2013 00:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwIjsrtOWJ6J for ; Thu, 14 Feb 2013 00:54:23 -0800 (PST) Received: from mail-la0-x230.google.com (la-in-x0230.1e100.net [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 094B521F8682 for ; Thu, 14 Feb 2013 00:54:21 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id fq13so2079143lab.35 for ; Thu, 14 Feb 2013 00:54:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ATYkTHtB623ixRSQaIVoRI3zNAzJId54zAr+FrzJ1NY=; b=VHfJglHxazIkJQAqKVHro80/GgKFzeFY8puwOrzr5ISlzNb3DaAwee88TtNk7HGcgX feE9p+M986NaSL57PGFhkXo0rML0bMwNbUpvmMJ85RnRxJJeKKG0R1lmkmal7aQxm/c3 KpocBIIi5jPaH25awsYDYamZFLALbY/erItq3grLi+Fq8rPdx5bCntMXh1VbpoCFCTPt Ow885ya1FB+/sqwZWCVV2xl1x2tcbmlykkgB3+r4x8BpnojUG1x2BICGH18pMV1G9mBd qxY1fw3cmDOPdTtUrwzUbiJQ/WyD9i8A5JXVWjtEDGEL+zx3gUxvhgTuylFE9w/bssPW buFg== X-Received: by 10.152.134.164 with SMTP id pl4mr13684982lab.54.1360832060291; Thu, 14 Feb 2013 00:54:20 -0800 (PST) Received: from ?IPv6:2001:6b0:7:0:d81e:ac59:49b2:3ab2? ([2001:6b0:7:0:d81e:ac59:49b2:3ab2]) by mx.google.com with ESMTPS id oy10sm27218174lab.8.2013.02.14.00.54.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 00:54:19 -0800 (PST) Message-ID: <511CA639.6010704@mnt.se> Date: Thu, 14 Feb 2013 09:54:17 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: therightkey@ietf.org References: <511C4389.3060904@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmjs9Vr3IUU5xpHiMpCm0Gcp1hON9CjIP+mSoevqEjYWxxqYsdX6nTiuXsck8CXQKvjbkcb Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:54:28 -0000 > > As for the mailing list-I'll enable the archive when there are > substantive posts to the mailing list. It's only 3 weeks old though > and is content-less so far :-) > > Cheers, > > Why not simply put it in the form of an I-D and have the conversation here? Cheers Leif From stephen.farrell@cs.tcd.ie Thu Feb 14 04:17:52 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD0021F870A for ; Thu, 14 Feb 2013 04:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YrT9Mh1de8O for ; Thu, 14 Feb 2013 04:17:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7121F86F6 for ; Thu, 14 Feb 2013 04:17:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6613BE32; Thu, 14 Feb 2013 12:17:29 +0000 (GMT) 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 yNA8zITrlDt2; Thu, 14 Feb 2013 12:17:29 +0000 (GMT) Received: from [IPv6:2001:770:10:203:58cf:363f:461d:b9e1] (unknown [IPv6:2001:770:10:203:58cf:363f:461d:b9e1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90AB1BE24; Thu, 14 Feb 2013 12:17:29 +0000 (GMT) Message-ID: <511CD5D9.7050208@cs.tcd.ie> Date: Thu, 14 Feb 2013 12:17:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joseph Bonneau References: <511C4389.3060904@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 12:17:52 -0000 Hiya, On 02/14/2013 02:55 AM, Joseph Bonneau wrote: >> For example, ISTM that a lot of bad URLs that are de-referenced are >> received in spam that won't contain this, or are in hrefs on pages >> loaded from sites that won't use this, or that attacks are trying >> to trick users into accepting a bogus version of a site that they >> have already visited (e.g. a bank). >> > > Not attempting to deal with spam or phishing. Phishy sites will probably > not use TLS anyways. Fair enough, but my question is: what does this deal with? Can you give a walk-through of a bad thing that does happen, and how that bad thing is less likely to happen or be exploitable if this mechanism is deployed? Honestly, I'm not seeing it. > I also agree that there will be tons of insecure links all over the web and > that this is not a complete solution but an incrementally deployable > measure that I claim can protect many connections. The claim is based on > the hunch that a large percentage of *initial* connections to new sites > happen via hyperlinks served by small number of hubs: namely webmail, > search engines, social networks, link shorteners. If you can secure these > initial connections relatively cheaply it's a win. Just to try clarify why I'm not seeing it... For webmail and social networks there's an account setup phase where I'm not sure this helps and after that HPKP or whatever can kick in. Link shorteners maybe, but I'm not sure what's proposed for that (the hash of who's key is where and checked when?). And for search engines, I don't see how my browser will know that duckduckgo use this and do that well enough to block something without creating a possible DoS from any bit of HTML that convinces my browser to believe in the link-security attribute. So maybe I'm just slow, but a walkthrough of just how this is an effective mitigation for some real threat would help me a lot. (Sorry if that's on the site and I missed it.) >> I hope the answer ins't to the effect that UAs >> need to go through some gatekeeper site before going anywhere else, >> but I expect that'll not be your answer.) > > This is exactly the motivation for this proposal: I don't want UAs to go > through any *new* gatekeeper or add a blocking lookup to a trusted > authority to get to the right destination securely. I want to leverage the > fact that the vast majority of users already go through gatekeepers from a > small set before going anywhere else. Perhaps this isn't everybody's ideal > of how the web should work, but since that's the reality I think it's > useful to use these gatekeepers to distribute security information. Well, today's reality is not what was reality a decade ago. And I firmly believe we're likely to see as much or more change in the next decade, so I'm uncomfortable with solutions that depend on today's top-10 sites or anything similar to be honest. There can be a place for such things of course, but I think its very reasonable to be wary of all such solutions. (But that's all jumping ahead, I'd rather talk about the walkthrough thing, so fee free to ignore me on this for now:-) > Websites are also far more agile as trust anchors than almost anything else > under consideration. Some users know how to change search engines but > virtually zero have any idea what a CA is. > > I grant that s-links on their own won't solve things so I'd encourage the > proposal not to be considered in isolation. S-links are fundamentally > dependent on some other protocol gaining non-trivial deployment (where > non-triivial means that the list of supporting sites can't be hard-coded > into the browser). But thinking ahead, s-links make the deployment story > for HPKP, CT, or lots of other proposals much more believable to me so I > think there's value in developing it alongside them. S-links will always be > useful in an HPKP world, and for CT until 100% deployment (at CAs) is > achieved. > > As for the mailing list-I'll enable the archive when there are substantive > posts to the mailing list. It's only 3 weeks old though and is content-less > so far :-) That can be one of the most useful things to know about an archive:-) But fair enough and thanks for bringing this up here, I do think its worth discussing. Cheers, S. > > Cheers, > > Joe > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From stephen.farrell@cs.tcd.ie Thu Feb 14 04:20:47 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37521F8512 for ; Thu, 14 Feb 2013 04:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpYJ639FouDH for ; Thu, 14 Feb 2013 04:20:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1D321F8501 for ; Thu, 14 Feb 2013 04:20:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CF799BE38; Thu, 14 Feb 2013 12:20:23 +0000 (GMT) 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 rQLWCf4+bCZE; Thu, 14 Feb 2013 12:20:23 +0000 (GMT) Received: from [IPv6:2001:770:10:203:58cf:363f:461d:b9e1] (unknown [IPv6:2001:770:10:203:58cf:363f:461d:b9e1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 84745BE32; Thu, 14 Feb 2013 12:20:23 +0000 (GMT) Message-ID: <511CD687.5070907@cs.tcd.ie> Date: Thu, 14 Feb 2013 12:20:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joseph Bonneau References: <511C4389.3060904@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , "therightkey@ietf.org" Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 12:20:47 -0000 On 02/14/2013 03:39 AM, Joseph Bonneau wrote: >> >> To be more concrete: At the WebAppSec / WebCrypto meeting in November, it >> was mentioned (by Brad Hill IIRC) that one of the things that WebAppSec >> might be looking into after CSP would be link-based assertions. The example >> I remember is to attach a digest of the destination resource to a link, so >> that, e.g., if a third-party script were compromised, it could be >> recognized. Seems slightly different, but still related. >> > > Ah, I see where you were going now. I mentioned this on the s-links > FAQ-including content hashes in links has indeed been proposed many times. > This solves a completely different problem-including content from an > untrusted mirror, compared to of securely getting TLS security info for a > new domain that you'll have some future interaction with. I left it out of > s-links (though it could certainly be added as an additional directives) > because I think it is such a different problem. I agree that's a totally different problem (I even know one bozo who wrote up an I-D for naming things with hashes:-) I'm not sure whether mixing naming and html-level TLS key pinning in the same mechanism would make sense though. S. > > In any case, might not hurt to ping the WebAppSec list as well as this one. >> > > Will do. My thinking is though, there are lots of web security details to > get right here (and hopefully the trickiest ones came out of the Chromium > mailing list) but I'd like to get higher-level feedback from people > interested in bigger-picture TLS issues about whether or not s-links are a > desirable building block before diving into that level of detail. > > Cheers, > > Joe > From jbonneau@gmail.com Thu Feb 14 09:47:32 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054721F882E for ; Thu, 14 Feb 2013 09:47:30 -0800 (PST) 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=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_STOP=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lDPZ7Act-tZ for ; Thu, 14 Feb 2013 09:47:29 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5C21F871F for ; Thu, 14 Feb 2013 09:47:28 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id dx4so71572qab.2 for ; Thu, 14 Feb 2013 09:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=PafztQ1Chu+o+uNW8DC5j5JEkrsMHRVzsMWKKq+8tjc=; b=l+iBb+mRdwMA1h5FpY1BX+gEifUvEckYxg5YtMR3tj2sk3IZCZySZaKmygyPWPacN0 YryBxQxYLxFkUrYE1741E4sM7zZzL7e8/gfr7h7FuQDvgtSS57OqeSyPe10ee8BPFGNZ Z4E8spds2MGq3xi5KpNA02D1iGOiEQ0qNYlSjOk/7D6pjB5R/vKI28UFv9TtO/3g7U4+ Ip0oEaz4Y/MiCk8COnS0rERLhiBSg+poVlzED/Np3AiJIijTH1N6blxf6/EJsPkfYO+4 t0eeWhcbV3GEaa3lYUQnQIjgkOE6tmxpxxuAts8vn/yRGeEZDxza97sDb8ADbp2ICgQG FBrQ== X-Received: by 10.49.48.113 with SMTP id k17mr12077201qen.51.1360864047774; Thu, 14 Feb 2013 09:47:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Thu, 14 Feb 2013 09:47:07 -0800 (PST) In-Reply-To: <511CD5D9.7050208@cs.tcd.ie> References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> From: Joseph Bonneau Date: Thu, 14 Feb 2013 12:47:07 -0500 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b6da46027bc3404d5b2daac Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:47:33 -0000 --047d7b6da46027bc3404d5b2daac Content-Type: text/plain; charset=UTF-8 > Fair enough, but my question is: what does this deal with? Can you > give a walk-through of a bad thing that does happen, and how that > bad thing is less likely to happen or be exploitable if this > mechanism is deployed? Honestly, I'm not seeing it. Sure, the parable would be this: Brian wants to visit the Judaean People's Front website but his local ISP is run by the Romans, who also control the RomeTrust CA. The JPF website is wisely using HPKP to pin clients to their correct key. However, they're too small of an organization for the browser to pre-load this. Brian does have a genuine browser, which has key pins for the connection to his search engine which is outside of Roman control. Without S-links, Brian has no easy way to navigate to the JPF website and confirm that there isn't a centurion-in-the-middle attack which blocks the HPKP pins from ever being delivered. With s-links, his search engine can include the JPF's key pins (which they observed when crawling and indexing the site), allowing Brian to get there safely. He can then access that website directly (through history, bookmarks, recently-closed tabs, etc.), without needing the search engine anymore, as the HPKP pins will protect future connections. Similar story for CT... > For webmail and social networks there's an account setup phase > where I'm not sure this helps and after that HPKP or whatever can > kick in. Link shorteners maybe, but I'm not sure what's proposed > for that (the hash of who's key is where and checked when?). And > for search engines, I don't see how my browser will know that > duckduckgo use this and do that well enough to block something > without creating a possible DoS from any bit of HTML that > convinces my browser to believe in the link-security attribute. > There's no DoS possibility because s-links have no persistent effects. All a "malicious" s-link can do is cause a broken link. Broken links already exist, this is not exciting. > Well, today's reality is not what was reality a decade ago. And I > firmly believe we're likely to see as much or more change in the next > decade, so I'm uncomfortable with solutions that depend on today's > top-10 sites or anything similar to be honest. > Browsers now update at least monthly (and this update itself is pinned and assumed secure). So it's easy to change the list of pre-loaded sites. If the structure of the web graph changes dramatically and there isn't a small central hub of introducer websites, then this solution would change. But this structure hasn't changed much, the web has only become more concentrated. Hope that helps explain my motivation? Joe --047d7b6da46027bc3404d5b2daac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fair enough, = but my question is: what does this deal with? Can you
give a walk-through of a bad thing that does happen, and how that
bad thing is less likely to happen or be exploitable if this
mechanism is deployed? Honestly, I'm not seeing it.
Sure, the parable would be this: Brian wants to visit the Juda= ean People's Front website but his local ISP is run by the Romans, who = also control the RomeTrust CA. The JPF website is wisely using HPKP to pin = clients to their correct key. However, they're too small of an organiza= tion for the browser to pre-load this. Brian does have a genuine browser, w= hich has key pins for the connection to his search engine which is outside = of Roman control. Without S-links, Brian has no easy way to navigate to the= JPF website and confirm that there isn't a centurion-in-the-middle att= ack which blocks the HPKP pins from ever being delivered. With s-links, his= search engine can include the JPF's key pins (which they observed when= crawling and indexing the site), allowing Brian to get there safely. He ca= n then access that website directly (through history, bookmarks, recently-c= losed tabs, etc.), without needing the search engine anymore, as the HPKP p= ins will protect future connections.

Similar story for CT...
=C2=A0
For webmail and social networks there's an account setup phase
where I'm not sure this helps and after that HPKP or whatever can
kick in. Link shorteners maybe, but I'm not sure what's proposed for that (the hash of who's key is where and checked when?). And
for search engines, I don't see how my browser will know that
duckduckgo use this and do that well enough to block something
without creating a possible DoS from any bit of HTML that
convinces my browser to believe in the link-security attribute.

There's no DoS possibility because s-links hav= e no persistent effects. All a "malicious" s-link can do is cause= a broken link. Broken links already exist, this is not exciting.
=C2=A0
Well, today's reality i= s not what was reality a decade ago. And I
firmly believe we're likely to see as much or more change in the next decade, so I'm uncomfortable with solutions that depend on today's<= br> top-10 sites or anything similar to be honest.=C2=A0
<= br>
Browsers now update at least monthly (and this update itself = is pinned and assumed secure). So it's easy to change the list of pre-l= oaded sites. If the structure of the web graph changes dramatically and the= re isn't a small central hub of introducer websites, then this solution= would change. But this structure hasn't changed much, the web has only= become more concentrated.
=C2=A0
Hope that helps explain my motivation?

<= div>Joe
--047d7b6da46027bc3404d5b2daac-- From bhill@paypal-inc.com Thu Feb 14 10:34:59 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C298B21F854C for ; Thu, 14 Feb 2013 10:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp8ZtN1YHz3S for ; Thu, 14 Feb 2013 10:34:58 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id DA99A21F8534 for ; Thu, 14 Feb 2013 10:34:57 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=Py4D8vao8dmQpz1Q3qNQVjevzRb9agA7V1ATTXmLm1vkg9txnaYSPLjo E38S1fybYLjpADu7qa0WmxpiNAEwfuoV8Pk9UdiD4Gqr1MlHn+1gPoHSA mmW6OL7ypWOOTJO0uzYesgT4imcWU7dRro9wquuCVxiztFpo5H20RUDJp 4=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1360866898; x=1392402898; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NsO21sAB63F2O06VpVLNx2EdWIr0iTITwzJUA7WASZI=; b=URlAkIhlD9zyoM00/+5cn4W1qDoOp/SgDDyZEIK4lZJ9Hr02N8H4IKnK lUGjiPlFukzsNBLKlF3njMeyxc8vJrqcz1q1w0OLn8Hg9V8r4pY3Z1VO3 mB+I2/OBwQ5MmCGo5q0p88NnlDOkzFSbTzNOQuhvZherIK8MP2ikpu/cA k=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,666,1355126400"; d="scan'208";a="12913101" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 14 Feb 2013 10:34:57 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-004.corp.ebay.com ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 11:34:57 -0700 From: "Hill, Brad" To: Richard Barnes , Joseph Bonneau Thread-Topic: [therightkey] New proposal: S-links (secure links) Thread-Index: AQHOCghJT3sxCxCZckG5I5JkvBrqt5h5DWCAgAARZoCAAAJNgIAAA6aAgAADy4CAAIM/4A== Date: Thu, 14 Feb 2013 18:34:55 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E2791B58E@DEN-EXDDA-S12.corp.ebay.com> References: <511C4389.3060904@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: [10.245.27.242] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:35:00 -0000 Hi. Regarding what WebAppSec at the W3C is doing: Our proposed new charter in the WebAppSec WG, (http://lists.w3.org/Archiv= es/Public/public-webappsec/2012Nov/att-0112/Web_Application_Security_Workin= g_Group.htm) currently under W3C team review, has a deliverable that we've = currently titled "Sub-Resource Integrity". It is intended to address secur= ity properties of Web Applications, specifically, to allow an application i= nstance (DOM) created over an HTTPS connection to load other resources (ima= ges, javascript, etc.) over insecure transports or across administrative bo= undaries with a guarantee of integrity. It's closest relation is Gerv Markham's Link Fingerprints (http://www.ger= v.net/security/link-fingerprints/), although that focuses on integrity of l= inked content to be handled as disposition: attachment. We may or may not = take on that as a "bonus feature" in WebAppSec, but it is not necessarily i= mplied by the new proposed charter scope. Anyway - this all is to say that we are explicitly *not* addressing the s= ame problem space as S-links. We are narrowly interested in protecting the= integrity of a Web Application with components distributed across multiple= administrative domains and/or insecure network links, but all trust would = still bootstrapped initially over HTTPS. There is no intent to address pro= blems of identity, trust bootstrapping, secure introduction, key pinning, e= tc.=20 I think this list is a great place to start that conversation. Thanks, J= oe! Brad Hill Co-Chair, W3C WebAppSec WG From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On= Behalf Of Richard Barnes Sent: Wednesday, February 13, 2013 7:30 PM To: Joseph Bonneau Cc: therightkey@ietf.org; Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) Well, I may be mistaken, or I may have mis-skimmed your proposal.=A0 To be more concrete: At the WebAppSec / WebCrypto meeting in November, it w= as mentioned (by Brad Hill IIRC) that one of the things that=A0WebAppSec mi= ght be looking into after CSP would be link-based assertions. The example I= remember is to attach a digest of the destination resource to a link, so t= hat, e.g., if a third-party script were compromised, it could be recognized= . Seems slightly different, but still related. =A0=A0 In any case, might not hurt to ping the=A0WebAppSec list as well as this on= e.=A0 Cheers, --Richard On Wednesday, February 13, 2013, Joseph Bonneau wrote: I believe some ideas of this character have been discussed in the W3C WebAp= pSec WG. =A0 http://www.w3.org/2011/webappsec/ =A0 Can you point to anything more specific? I discussed s-links via email with= Adam Barth who's a CSP editor and it didn't seem that this has been extens= ively discussed by the WebAppSec WG... The only thing I can think of is discussion about enabling CSP to require t= hat the same cert is presented for all page resources, which I believe didn= 't make the spec due to origin contamination problems. S-links, by the way,= has the same issue unless a persistent key pin (or other persistent securi= ty upgrade) is immediately received, as discussed on the s-links site-this = is a very important subtlety. Cheers, Joe From stephen.farrell@cs.tcd.ie Thu Feb 14 10:43:00 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498B021F888E for ; Thu, 14 Feb 2013 10:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_STOP=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66hcW0TZVLNT for ; Thu, 14 Feb 2013 10:42:59 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6940121F888A for ; Thu, 14 Feb 2013 10:42:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D9C7EBE24; Thu, 14 Feb 2013 18:42:35 +0000 (GMT) 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 psXh6iE+1FfY; Thu, 14 Feb 2013 18:42:34 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.45.49.182]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 434CCBDDC; Thu, 14 Feb 2013 18:42:34 +0000 (GMT) Message-ID: <511D301A.4060608@cs.tcd.ie> Date: Thu, 14 Feb 2013 18:42:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joseph Bonneau References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:43:00 -0000 Hiya, On 02/14/2013 05:47 PM, Joseph Bonneau wrote: >> Fair enough, but my question is: what does this deal with? Can you >> give a walk-through of a bad thing that does happen, and how that >> bad thing is less likely to happen or be exploitable if this >> mechanism is deployed? Honestly, I'm not seeing it. > > > Sure, the parable would be this: Brian wants to visit the Judaean People's > Front website but his local ISP is run by the Romans, who also control the > RomeTrust CA. The JPF website is wisely using HPKP to pin clients to their > correct key. However, they're too small of an organization for the browser > to pre-load this. Brian does have a genuine browser, which has key pins for > the connection to his search engine which is outside of Roman control. > Without S-links, Brian has no easy way to navigate to the JPF website and > confirm that there isn't a centurion-in-the-middle attack which blocks the > HPKP pins from ever being delivered. With s-links, his search engine can > include the JPF's key pins (which they observed when crawling and indexing > the site), allowing Brian to get there safely. He can then access that > website directly (through history, bookmarks, recently-closed tabs, etc.), > without needing the search engine anymore, as the HPKP pins will protect > future connections. Ok, so that needs Brian's browser to know about all possible search engines Brian might use, that all of those scrape the JPF site (and not the Roman fake:-) for keys and that Brian does go to the JPF site for the first time by clicking on a search result. If the centurions don't specifically care who they MITM then spam works for them, if they do care, the spear-phising will likely work anyway since Brian's a bit naive. In terms of detecting that MITM attacks are being attempted, I guess this gives much less of a signal than HPKP and/or CT as its only producing a different signal for that 1st time ever. (I don't think that the centurions can avoid being spotted by already pinned JPF clients in general but still attempt MITM against 1st time connectors can they? If they could we should consider that as a flaw in HPKP maybe.) That just seems like a lot of pre-arranged stuff being required and overhead for all search engines when Brian is as likely as not to go straight to the site, or be tricked into doing so by the centurions. > Similar story for CT... > > >> For webmail and social networks there's an account setup phase >> where I'm not sure this helps and after that HPKP or whatever can >> kick in. Link shorteners maybe, but I'm not sure what's proposed >> for that (the hash of who's key is where and checked when?). And >> for search engines, I don't see how my browser will know that >> duckduckgo use this and do that well enough to block something >> without creating a possible DoS from any bit of HTML that >> convinces my browser to believe in the link-security attribute. > > There's no DoS possibility because s-links have no persistent effects. All > a "malicious" s-link can do is cause a broken link. Broken links already > exist, this is not exciting. You might be right, I guess it depends on how browsers decide when to believe link-security or not. If they only believe the pin when its presented via a live TLS server authenticated connection from an already pinned search engine that might be ok, but then wouldn't that make any cut'n'pasted links liable to barf? (When Brian sends the link he got to the JPF site via email to Reg, then if the PIN is ignored then the centurions could get Reg, but if its not ignored then Brian or anyone maybe can DoS Reg.) >> Well, today's reality is not what was reality a decade ago. And I >> firmly believe we're likely to see as much or more change in the next >> decade, so I'm uncomfortable with solutions that depend on today's >> top-10 sites or anything similar to be honest. >> > > Browsers now update at least monthly (and this update itself is pinned and > assumed secure). That is a change that's positive when arguing for mechanisms like this I agree. > So it's easy to change the list of pre-loaded sites. If > the structure of the web graph changes dramatically and there isn't a small > central hub of introducer websites, then this solution would change. But > this structure hasn't changed much, the web has only become more > concentrated. Nonetheless, mechanisms like this aren't ideal esp. if they don't quite work well enough security-wise, but do clearly further increase all of our dependencies on fewer and fewer point of real control. But again, I'm more interested in the former aspect now (whether this has enough security pay-off). > Hope that helps explain my motivation? Sure, I got the motivation all along. Its whether or not the mechanism is useful enough that puzzles me. I'm still not convinced, but would be interested in seeing it further worked out. Cheers, S. > > Joe > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From leifj@mnt.se Thu Feb 14 10:52:51 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A252D21F8802 for ; Thu, 14 Feb 2013 10:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGOvHEHqx1k6 for ; Thu, 14 Feb 2013 10:52:49 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1A21F86DD for ; Thu, 14 Feb 2013 10:52:49 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id s4so2061655lbc.35 for ; Thu, 14 Feb 2013 10:52:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=YuxOajga1i/6wkD2KRXVgNCCK/i8dg08fsJYr+NVCNM=; b=bVhPuA1OeM6WfB07f/Kzx+DycpK7cjfnq7mh4MpMkxXxuX4iRYt8FXMq1zFccMBmev K/d9HYUNA26uLrcyfiBtvuksVQqMYevSoPXo2jp9NHyHbXiNddtlcZgg8Bj92OH6DUG8 N/QI5oQ09+2NFzqlj+A1TSPCcMelkp+1iDrgwt5AAjdXioHPxBNaHhmnX1mCfVOuRjdr 1J9OLtQnY5geTPmB2TKikqEG4wajAnV+Jvc3DvW73pF+Xjsd3CoejjXlyR6ZD3nPE0cx Qbks2dDtZMPtyVNkBLj1EmC5p2USdHfHmta1EBPIAY5BJdTw5ddenIxytOk/FYCX3T+7 EXnA== X-Received: by 10.112.98.105 with SMTP id eh9mr1022711lbb.131.1360867968144; Thu, 14 Feb 2013 10:52:48 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id fz16sm8965394lab.5.2013.02.14.10.52.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 10:52:47 -0800 (PST) Message-ID: <511D327D.5060605@mnt.se> Date: Thu, 14 Feb 2013 19:52:45 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: therightkey@ietf.org References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> In-Reply-To: <511D301A.4060608@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmBm0lWMNjwp1osy2jh248VoJviTz3LsyD/4UMJIMfA/mjQRM6qazDYiZFI3I7m0bTX/s8o Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 18:52:51 -0000 On 02/14/2013 07:42 PM, Stephen Farrell wrote: > > Ok, so that needs Brian's browser to know about all possible > search engines Brian might use, that all of those scrape the JPF > site (and not the Roman fake:-) for keys and that Brian does go > to the JPF site for the first time by clicking on a search > result. I don't get that. Isn't it enough if Brians browser processes s-link attributes as he is clicking away, populating his pinning database as he goes? From stephen.farrell@cs.tcd.ie Thu Feb 14 11:00:39 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB9221F8840 for ; Thu, 14 Feb 2013 11:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfTwxf8mUFj8 for ; Thu, 14 Feb 2013 11:00:39 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 47CC221F8570 for ; Thu, 14 Feb 2013 11:00:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8979DBE2F; Thu, 14 Feb 2013 19:00:17 +0000 (GMT) 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 aQEnlY3XGslh; Thu, 14 Feb 2013 19:00:16 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.45.49.182]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2E66BE1E; Thu, 14 Feb 2013 19:00:16 +0000 (GMT) Message-ID: <511D3440.90307@cs.tcd.ie> Date: Thu, 14 Feb 2013 19:00:16 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Leif Johansson References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> In-Reply-To: <511D327D.5060605@mnt.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:00:39 -0000 On 02/14/2013 06:52 PM, Leif Johansson wrote: > On 02/14/2013 07:42 PM, Stephen Farrell wrote: >> >> Ok, so that needs Brian's browser to know about all possible >> search engines Brian might use, that all of those scrape the JPF >> site (and not the Roman fake:-) for keys and that Brian does go >> to the JPF site for the first time by clicking on a search >> result. > I don't get that. Isn't it enough if Brians browser processes > s-link attributes as he is clicking away, populating his pinning > database as he goes? I don't know but didn't get the concept that Brian is populating as he goes when I looked at the description. I thought he'd only believe pins on the href he's about to follow when those had just been delivered direct from one of a browser-chosen list of sources that are explicitly trusted (by the browser, not Brian) for this. But I guess it might be that if he searched for "front for the liberation of..." on Thursday and then on Friday typed in the JPF URL that could work if the browser has kept the info. ('course those paranoid JPF guys might change their key late on Thursday which'd be bad) so maybe not. Not sure it changes the overall effectiveness much though, does it? S From leifj@mnt.se Thu Feb 14 11:09:25 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2FA21F8413 for ; Thu, 14 Feb 2013 11:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTmByJkTd-Zz for ; Thu, 14 Feb 2013 11:09:24 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id C174421F8886 for ; Thu, 14 Feb 2013 11:09:13 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so2054253lbo.0 for ; Thu, 14 Feb 2013 11:09:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=GMDzAIibBmHukRurvrqHaQ9uTBJTMnaGSTbjhczHMzE=; b=pEuQqff4bwMr84c7Ru07G5947660Ew4hhU1QHP6dVhexKhBP0/91VxJS4Pt5jRjTq/ yHTFmbOZHWP0MAIZet4YM5oqfGLx7finsrvQQOL9QgMJURAK204rgY1yyE3i+hzJON5s MIS8/q7XoIZqnHIIQ2cb4kr/smsXM2pb0R/hZsgKPl6Rg3mkTFZAYOmAcpSROx8BDukx ozJdA7tJC4lAagWHHpkKC0RDtlQC1M84slNRAwZ8gfHVBRMX5WknEkMwFFry853csU7b 67x1178O9IYquAeRaIPKcKxIIiQ/RxYwoC4InSUZlXTxg3i2wjX+thT6qWY88VjDt5D1 tSzQ== X-Received: by 10.112.26.106 with SMTP id k10mr1066567lbg.5.1360868952671; Thu, 14 Feb 2013 11:09:12 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPS id oy10sm28177908lab.8.2013.02.14.11.09.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 11:09:11 -0800 (PST) Message-ID: <511D3655.6030109@mnt.se> Date: Thu, 14 Feb 2013 20:09:09 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> In-Reply-To: <511D3440.90307@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlnU/2RiFaA/GYpTnjQZVSn2bXF9+fGL+MZMP8PmnL5Y8QGEX0obxZOnGorpXfqpbgl9/UH Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:09:25 -0000 On 02/14/2013 08:00 PM, Stephen Farrell wrote: > > On 02/14/2013 06:52 PM, Leif Johansson wrote: >> On 02/14/2013 07:42 PM, Stephen Farrell wrote: >>> Ok, so that needs Brian's browser to know about all possible >>> search engines Brian might use, that all of those scrape the JPF >>> site (and not the Roman fake:-) for keys and that Brian does go >>> to the JPF site for the first time by clicking on a search >>> result. >> I don't get that. Isn't it enough if Brians browser processes >> s-link attributes as he is clicking away, populating his pinning >> database as he goes? > I don't know but didn't get the concept that Brian is > populating as he goes when I looked at the description. > > I thought he'd only believe pins on the href he's about > to follow when those had just been delivered direct from > one of a browser-chosen list of sources that are > explicitly trusted (by the browser, not Brian) for this. I guess there could be some policy setting that allows Brian to decide if he trusts the page to transit trust for him or just to update the pin db for that URL. I must say I am attracted to the notion as such because it affords a way to tie trust with branding (which is what social trust is mostly about anyway). > > But I guess it might be that if he searched for "front > for the liberation of..." on Thursday and then on Friday > typed in the JPF URL that could work if the browser has > kept the info. ('course those paranoid JPF guys might > change their key late on Thursday which'd be bad) so > maybe not. > > Not sure it changes the overall effectiveness much though, > does it? > > S From jbonneau@gmail.com Thu Feb 14 11:22:28 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDF121F8681 for ; Thu, 14 Feb 2013 11:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6-z-XbMQIfZ for ; Thu, 14 Feb 2013 11:22:27 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id A25E021F8610 for ; Thu, 14 Feb 2013 11:22:26 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id b12so1005066qca.18 for ; Thu, 14 Feb 2013 11:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=KXb9HP8dZ9XJSsLJP3lCJtwELTR7SD4FrOBAfAMRDZs=; b=HZz/ooTK8C9HKMEBX4oGTblFWJMzywa5m4rppplV85wS7w6wtA/70Gn9/fIOHhF22u g9smjMz9DRxe9p2SKGNBhgmp9CIL9x9lOLopka8WnyeCq6cLfyklFV8eRqCw+qa3R/Qo Yxb3uc/ip9SR+Wrt8zF22/J09GQhOusq9R7di+rdAVxkikH0cchCT99NQB3gwJd5rzIK K/XNZ+GZugBsNUef+M3KFKfzLy9jd2x9GjJt3f1vhDZS47Wxn3m5ne9AkHBmsX1YJSop 6RMxXAVCgNOqGRJi+Oq3AKIkFnSnv4lxd+HXIep8h+9Qw77tL3bG2qwBLWTRr5WYdPk8 hS+A== X-Received: by 10.224.207.72 with SMTP id fx8mr1065655qab.66.1360869742687; Thu, 14 Feb 2013 11:22:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Thu, 14 Feb 2013 11:22:02 -0800 (PST) In-Reply-To: <511D3655.6030109@mnt.se> References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> From: Joseph Bonneau Date: Thu, 14 Feb 2013 14:22:02 -0500 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=20cf300fb4cd99364804d5b42d50 Cc: therightkey@ietf.org, Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:22:28 -0000 --20cf300fb4cd99364804d5b42d50 Content-Type: text/plain; charset=UTF-8 > > I thought he'd only believe pins on the href he's about > > to follow when those had just been delivered direct from > > one of a browser-chosen list of sources that are > > explicitly trusted (by the browser, not Brian) for this. > This is not correct. S-links can come from any site, not just pre-trusted sites, and the browser will honor them if the user clicks them. Once Brian gets to the JPF site, they can link him to the People's Front of Judea website via s-link and do a secure introduction. The general idea behind HPKP is that the browser is caching pins for sites the user has been to recently. S-links enables any of these sites securely introduce the user to new sites. This came up earlier with the question "what if I use a fringe search engine that isn't pre-loaded?" You need to securely get to your chosen search engine securely at some point, and then you're okay. One way to think about s-links is a mechanism to opportunistically reduce the number of untrusted initial connections. You might ask, why should the browser trust an s-link if it's from a dodgy site? This doesn't actually lead to any new attacks though, because s-links can only make security policy stricter. A bad site has no incentive to serve bad s-links, they could just serve regular links or links to different domains. > I guess there could be some policy setting that allows > Brian to decide if he trusts the page to transit trust > for him or just to update the pin db for that URL. > No such policy since no origin can update the persistent pin DB for another origin. And as mentioned above, any site can tighten the security via s-links for a connection caused by its own links only. > I must say I am attracted to the notion as such because > it affords a way to tie trust with branding (which is what > social trust is mostly about anyway). Yes, I think this is a major selling point. > > But I guess it might be that if he searched for "front > > for the liberation of..." on Thursday and then on Friday > > typed in the JPF URL that could work if the browser has > > kept the info. ('course those paranoid JPF guys might > > change their key late on Thursday which'd be bad) so > > maybe not. > The assumption is that the correct JPF website delivers persistent key pins, so Brian can go direct to their site Friday after a secure introduction on Thursday. If he goes via s-link on Thursday and doesn't get any persistent key pins, the s-link won't affect his direct visit on Friday, but this is by design. If the site isn't declaring key pins, it means they're reserving the right to change their mind Thursday night. If they are setting their own pins, they shouldn't change Thursday night or else they'll be bricking some users, independently of s-links . Joe --20cf300fb4cd99364804d5b42d50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I thought he'd only believe pins on the href he's about
> to follow when those had just been delivered direct from
> one of a browser-chosen list of sources that are
> explicitly trusted (by the browser, not Brian) for this.

This is not correct. S-links can come fro= m any site, not just pre-trusted sites, and the browser will honor them if = the user clicks them. Once Brian gets to the JPF site, they can link him to= the People's Front of Judea website via s-link and do a secure introdu= ction. The general idea behind HPKP is that the browser is caching pins for= sites the user has been to recently. S-links enables any of these sites se= curely introduce the user to new sites. This came up earlier with the quest= ion "what if I use a fringe search engine that isn't pre-loaded?&q= uot; You need to securely get to your chosen search engine securely at some= point, and then you're okay.=C2=A0

One way to think about s-links is a mechanism to opport= unistically reduce the number of untrusted initial connections.
<= br>
You might ask, why should the browser trust an s-link if it&#= 39;s from a dodgy site? This doesn't actually lead to any new attacks t= hough, because s-links can only make security policy stricter. A bad site h= as no incentive to serve bad s-links, they could just serve regular links o= r links to different domains.
=C2=A0
I guess there could be some policy setting that allows
Brian to decide if he trusts the page to transit trust
for him or just to update the pin db for that URL.
No such policy since no origin can update the persistent pin DB= for another origin. And as mentioned above, any site can tighten the secur= ity via s-links for a connection caused by its own links only.
=C2=A0
I must say I am attracted to the notion as such because
it affords a way to tie trust with branding (which is what
social trust is mostly about anyway).

Yes, = I think this is a major selling point.=C2=A0
=C2=A0
> But I guess it might be that if he searched for "front
> for the liberation of..." on Thursday and then on Friday
> typed in the JPF URL that could work if the browser has
> kept the info. ('course those paranoid JPF guys might
> change their key late on Thursday which'd be bad) so
> maybe not.

The assumpt= ion is that the correct JPF website delivers persistent key pins, so Brian = can go direct to their site Friday after a secure introduction on Thursday.= If he goes via s-link on Thursday and doesn't get any persistent key p= ins, the s-link won't affect his direct visit on Friday, but this is by= design. If the site isn't declaring key pins, it means they're res= erving the right to change their mind Thursday night. If they are setting t= heir own pins, they shouldn't change Thursday night or else they'll= be bricking some users, independently of s-links .=C2=A0

Joe
--20cf300fb4cd99364804d5b42d50-- From stephen.farrell@cs.tcd.ie Thu Feb 14 11:30:19 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099E921F8462 for ; Thu, 14 Feb 2013 11:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAUhiLmxd60y for ; Thu, 14 Feb 2013 11:30:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0684E21F8459 for ; Thu, 14 Feb 2013 11:30:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34C3DBE2F; Thu, 14 Feb 2013 19:29:56 +0000 (GMT) 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 fqovLNwomN9g; Thu, 14 Feb 2013 19:29:55 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.45.49.182]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C13CBE1E; Thu, 14 Feb 2013 19:29:55 +0000 (GMT) Message-ID: <511D3B33.40908@cs.tcd.ie> Date: Thu, 14 Feb 2013 19:29:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joseph Bonneau References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Leif Johansson , therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:30:19 -0000 On 02/14/2013 07:22 PM, Joseph Bonneau wrote: >>> I thought he'd only believe pins on the href he's about >>> to follow when those had just been delivered direct from >>> one of a browser-chosen list of sources that are >>> explicitly trusted (by the browser, not Brian) for this. >> > > This is not correct. S-links can come from any site, not just pre-trusted > sites, and the browser will honor them if the user clicks them. Ah, I hadn't got that aspect at all. I probably need to think out the consequences. >> > But I guess it might be that if he searched for "front >>> for the liberation of..." on Thursday and then on Friday >>> typed in the JPF URL that could work if the browser has >>> kept the info. ('course those paranoid JPF guys might >>> change their key late on Thursday which'd be bad) so >>> maybe not. >> > > The assumption is that the correct JPF website delivers persistent key > pins, so Brian can go direct to their site Friday after a secure > introduction on Thursday. If he goes via s-link on Thursday and doesn't get > any persistent key pins, the s-link won't affect his direct visit on > Friday, but this is by design. If the site isn't declaring key pins, it > means they're reserving the right to change their mind Thursday night. If > they are setting their own pins, they shouldn't change Thursday night or > else they'll be bricking some users, independently of s-links . I don't get that sorry. Brian searches for "front for the ..." at noon Thu. and gets a href for JPF with PIN1 valid until Saturday. JPF rekey late Thursday. Let's say it was an emergency. Brian visits JPF Friday morning and PIN1 no longer matches the JPF TLS server cert. What happens then? Ta, S. From jbonneau@gmail.com Thu Feb 14 11:39:58 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABED21F8726 for ; Thu, 14 Feb 2013 11:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcrOha1xrvI7 for ; Thu, 14 Feb 2013 11:39:57 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 933C421F8639 for ; Thu, 14 Feb 2013 11:39:57 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id d42so1027620qca.15 for ; Thu, 14 Feb 2013 11:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=d5USlHn3WGPeWxNXZjWu/c9O0j76iawhsESDn8NCrto=; b=UcDOtd4+N0WeoP+LIR8Ks6HgN+hL0dOAIP1mtry2ssbBdriQ4SqmoHZamz1Y5VdzmB aPcDq2EkB/n/mej7w6/++sO+xtZDU/xAZKtTFDiQTSUyGv/l/Az9qMXFNj1pb00Ctdtn 9AfYtzAiRWkbCkH7zXqomvfRA3m3FThx2av8gsV1osBQJlc+OOYJtGzUILp4bbHZvRye tkCQtT1ZXiV59CYEWxRHb1xHpVdMfT3ZKyusC52j3+XvA+xSwuLoW4IbDuLbYaKza7ik 3fKeqS6Cb9M5p5mdjy15hjE5B4i5+HcaGEhXOGOfNAJz/XUZfBrAuzptl0n+gDoDOX9f yHEg== X-Received: by 10.229.69.24 with SMTP id x24mr2512496qci.16.1360870797069; Thu, 14 Feb 2013 11:39:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Thu, 14 Feb 2013 11:39:37 -0800 (PST) In-Reply-To: <511D3B33.40908@cs.tcd.ie> References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> <511D3B33.40908@cs.tcd.ie> From: Joseph Bonneau Date: Thu, 14 Feb 2013 14:39:37 -0500 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=00032557f3ae71ce1f04d5b46c72 Cc: Leif Johansson , therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:39:58 -0000 --00032557f3ae71ce1f04d5b46c72 Content-Type: text/plain; charset=UTF-8 > Brian searches for "front for the ..." at noon Thu. and gets > a href for JPF with PIN1 valid until Saturday. > > JPF rekey late Thursday. Let's say it was an emergency. > > Brian visits JPF Friday morning and PIN1 no longer matches > the JPF TLS server cert. > > What happens then? > If Brian kept the search results page open and re-clicked it on Saturday, it would look like a broken link. In practice, search engines are very conservative about serving broken links, so they wouldn't have served the s-link with a validity until Saturday unless they saw JPF.org setting HPKP pins with validity through Saturday (in which case JPF couldn't re-key without bricking users, independently of s-links). Even if the search engines were serving "inferred pins" though which weren't based on HPKP or some other commitment, Brian could access the site after Thursday If he typed in the URL, refreshed his existing page, or looked in his history, since none of these would be affected by the s-link seen on Thursday. Joe --00032557f3ae71ce1f04d5b46c72 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian searches for "front for the ..." at noon Thu. and gets
a href for JPF with PIN1 valid until Saturday.

JPF rekey late Thursday. Let's say it was an emergency.

Brian visits JPF Friday morning and PIN1 no longer matches
the JPF TLS server cert.

What happens then?

If Brian kept the se= arch results page open and re-clicked it on Saturday, it would look like a = broken link. In practice, search engines are very conservative about servin= g broken links, so they wouldn't have served the s-link with a validity= until Saturday unless they saw JPF.org setting HPKP pins with validity thr= ough Saturday (in which case JPF couldn't re-key without bricking users= , independently of s-links).

Even if the search engines were serving "inferred = pins" though which weren't based on HPKP or some other commitment,= Brian could access the site after Thursday If he typed in the URL, refresh= ed his existing page, or looked in his history, since none of these would b= e affected by the s-link seen on Thursday.

Joe
--00032557f3ae71ce1f04d5b46c72-- From dkg@fifthhorseman.net Thu Feb 14 11:41:29 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46821F885C for ; Thu, 14 Feb 2013 11:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8cP9lPNFKbO for ; Thu, 14 Feb 2013 11:41:28 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDA321F87CE for ; Thu, 14 Feb 2013 11:41:28 -0800 (PST) Received: from [192.168.13.130] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 85674F970 for ; Thu, 14 Feb 2013 14:41:26 -0500 (EST) Message-ID: <511D3DE3.5050601@fifthhorseman.net> Date: Thu, 14 Feb 2013 14:41:23 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: therightkey@ietf.org CC: "therightkey@ietf.org" References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> <511D3B33.40908@cs.tcd.ie> In-Reply-To: <511D3B33.40908@cs.tcd.ie> X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2KURLKXRIAGRUQWVWUVIS" Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:41:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KURLKXRIAGRUQWVWUVIS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/14/2013 02:29 PM, Stephen Farrell wrote: > Brian searches for "front for the ..." at noon Thu. and gets > a href for JPF with PIN1 valid until Saturday. >=20 > JPF rekey late Thursday. Let's say it was an emergency. according to the HPKP draft, they switch to their backup pin, right? https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-4.1 I'm assuming Brian hasn't followed the link to the JPF yet. > Brian visits JPF Friday morning and PIN1 no longer matches > the JPF TLS server cert. in this worst-case scenario, this is the first time Brian has visited the JPF, and he is still following the link he received on thursday. > What happens then? It sounds to me like an S-link-compatible browser would refuse to follow the link. so then Brian could still decide to search again, i guess, and hope for an updated S-link? Maybe this suggests that any S-link should embed a backup pin as well, and that an S-link-compatible user agent should require the backup pin to be present. Thinking about this stuff makes me worry that we're heading down a path of making a particularly ephemeral variant of a URL, though; and ephemerality violates some long-standing guiding principles behind URLs, e.g. http://www.w3.org/Provider/Style/URI It might be worth trying to think through what the bigger-picture consequences of that change would be if S-links were widely adopted. --dkg ------enig2KURLKXRIAGRUQWVWUVIS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRHT3jXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpmZEP/3FvjnYrJlc3pipHqI0Juqyk HXybhmkX2fCafwuY0N8W6M2BSMwYMqUCrN2cndcCvWRm/Q8hFnprE57+JvyeEZOq mjPZaKcR0XqWbMLMvfy2HIsGqEj9JqpIyqCxIPdAbh5WKmsey4s9RIIWoR8ZkzuR x/bbZ2X8QPgzxFhPr6DV1Ovb/HgCILfiqWPIVvu0+iGBhxpcYQLM9uPPCK69cint 8a99H8LSUz9mdtrdKa7tSY0PCIa+ZQFdsN1X4iotwnrSmLisHp70Bv9d24ikSSXB tWP6BJ4BHK4BJhgjXZ0gtdzX8TxN5cVqxJ2mkXfMD0NLMxuRJFII/va/whz3ditm llBXRcX/57M8DzL/OOIBO8FHpbkyr9EvSa7hB26u0eDfxwgZ1uK17sdNf3kN+oJJ N757aFoKT0sN0MPWouzB4LTcWgCJh54MKrbT66+c0upFuDpqzEIGtRyfk+7CFZDW cy3H5gIS5ogpr/3Mvp4OsUxYZUwFeIFcsU1/HNKC3jkdwPwL8ZT8vt4fmdSvBAiR AcXAWMHzUdtmhELzKY5VExZ5WKtMvkEEx9BT92Bqtq51WyU0C5TfNo6KblO9MaBZ oLHcvGgbmINcEyTUZhaXbzxJe1Ab0UxP66lJORwpugkGpAZTq+uK024bje/I0CdU fj97cmEYvDeZGCd37gPs =sU5J -----END PGP SIGNATURE----- ------enig2KURLKXRIAGRUQWVWUVIS-- From jbonneau@gmail.com Thu Feb 14 11:45:43 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F671F0CB7 for ; Thu, 14 Feb 2013 11:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na-Lj7TPBqA3 for ; Thu, 14 Feb 2013 11:45:40 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 948B121F8ADF for ; Thu, 14 Feb 2013 11:45:40 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so1027709qcs.13 for ; Thu, 14 Feb 2013 11:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uPd1ubewiUzRCrr7EOLAiGPJ7d1cPYizg9zSIv4tMwk=; b=ZGe2CWhngPWZQg66FLYNFwzbFneCkDJvZaemR1/vENUlhIz2F/maA1JmhKOCoE3aFx s3p8vXfghc1uqEG7Pfp4FdqHZowMkgExjuur458GaFq3OlExb0m1+cpcpQE7uNMKFLEI ut3ZdS+YcUx0Gu8CMWe/Wr9idQdWSFipZmpQ5iSnleEkP2Jfp9cZ7D1CG9o3XJCped3e MYWLnbwE+p3wMMzdAXp40DhXSK0Lq6KXpjmTRl6cntqr/Smlp63AgXaG6/MYeFVYstck fzP7+UWXcUX9okvJ4qVEt6A4gSTWiNB5sKWgvFkTA60H6Wy8nZdlNwKjZLpOO344l2hL TgKg== X-Received: by 10.229.69.24 with SMTP id x24mr2514269qci.16.1360871140063; Thu, 14 Feb 2013 11:45:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Thu, 14 Feb 2013 11:45:20 -0800 (PST) In-Reply-To: <511D3DE3.5050601@fifthhorseman.net> References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> <511D3B33.40908@cs.tcd.ie> <511D3DE3.5050601@fifthhorseman.net> From: Joseph Bonneau Date: Thu, 14 Feb 2013 14:45:20 -0500 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=00032557f3aee37ba104d5b48018 Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:45:43 -0000 --00032557f3aee37ba104d5b48018 Content-Type: text/plain; charset=UTF-8 > Maybe this suggests that any S-link should embed a backup pin as well, > and that an S-link-compatible user agent should require the backup pin > to be present. > Naturally, a search-engine would copy all of the observed HPKP pins, including the "backup" pins, which anyways aren't marked or treated different from any other pins. > Thinking about this stuff makes me worry that we're heading down a path > of making a particularly ephemeral variant of a URL, though; and > ephemerality violates some long-standing guiding principles behind URLs, > e.g. http://www.w3.org/Provider/Style/URI This is why I think HTML attributes are the right place for security directives and not URLs themselves (a la the YURLs proposal). S-links doesn't change URL syntax at all. Most hyperlinks on the web are already quite ephemeral... --00032557f3aee37ba104d5b48018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe this suggests that any S-link should embed a backup pin as well,
and that an S-link-compatible user agent should require the backup pin
to be present.

Naturally, a search-engi= ne would copy all of the observed HPKP pins, including the "backup&quo= t; pins, which anyways aren't marked or treated different from any othe= r pins.
=C2=A0
Thinking about this stuff makes me worry that we're heading down a path=
of making a particularly ephemeral variant of a URL, though; and
ephemerality violates some long-standing guiding principles behind URLs, e.g. =C2=A0http://www.w3.org/Provider/Style/URI

This is why I think HTML attributes are the right place for security direc= tives and not URLs themselves (a la the YURLs proposal). S-links doesn'= t change URL syntax at all. Most hyperlinks on the web are already quite ep= hemeral...
=C2=A0
--00032557f3aee37ba104d5b48018-- From dkg@fifthhorseman.net Thu Feb 14 11:51:03 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19F521F8419 for ; Thu, 14 Feb 2013 11:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSxvPKml706M for ; Thu, 14 Feb 2013 11:51:02 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 66EB821F8942 for ; Thu, 14 Feb 2013 11:51:01 -0800 (PST) Received: from [192.168.13.130] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5301EF970 for ; Thu, 14 Feb 2013 14:51:00 -0500 (EST) Message-ID: <511D4021.1090107@fifthhorseman.net> Date: Thu, 14 Feb 2013 14:50:57 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130112 Icedove/17.0.2 MIME-Version: 1.0 To: therightkey@ietf.org References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> <511D3B33.40908@cs.tcd.ie> <511D3DE3.5050601@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.6a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2PMUCVRHEICITFGNOEVMC" Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:51:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PMUCVRHEICITFGNOEVMC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/14/2013 02:45 PM, Joseph Bonneau wrote: > Naturally, a search-engine would copy all of the observed HPKP pins, > including the "backup" pins, which anyways aren't marked or treated > different from any other pins. https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-4.1 says that compliant user agents "MUST require that hosts set a Backup Pin." What do you think about adopting comparably-strong language in the S-links proposal? > Most hyperlinks on the web are already quite ephemeral... i know. it's sad :( --dkg ------enig2PMUCVRHEICITFGNOEVMC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRHUAhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpzdMP/j9fLYxYdgHxdnmw/jhnpcfI IhgwfwAtw2owZ6B93xDV2hgQNFuGjK4Wu8C2Yao2gNGDmD38eHvprx0V+WRZl5W8 BwexaViO5myPLTIC3NgC7xcB495AthOBibbAr/Pg5o7YMUg1P5L/hT2+QPfffF3O B7aI4uDZdl7Cl1p//Y0UzJM9JTFm1x1jbLHrbsQZoOURpOkZBtjTuRwfiNrEBMsv bsHC9RUHBlUUZi6usoksiUlyk0BufaIX2mrRaOrnSvOJou0dc+lc58tB9MnbjIYU BaioFSj+dJ7B9j/7B/6sBedPvxCHFbrBkC3Erhg9mCzb3CX8S77XkeYyFEiI1HkB uMoOcEKK+8zHk0t6gAZmJ58Dc+fhd1+6i0FY2bPXy86qUrIQvNsmOtZ/cFoepk+f IAR7EeBmwBNBhcGVMeJ3rTie7Tfr7GJp5rX+8c9jrs8aXNHetB/vobBIkI+cldCg XkwvcSiKnXohEMvOoNfWv2iEon+RA28ibQjYfTk52zerpbtEYChUreC2feSZVNyM GtRKK7joIfhmh6ycDqKvQq75AUZJSw6n/ooTtmnXH8Q5NT7mnhc50ZFL8Y2/0CSw bKixV7ulknx9cELVlziGy9XwQTxto0zlo0ZRcLkQn0yQVkf32XGVx9WQY68BascV lAc7hmgJxGFXFsXRC26C =qmO3 -----END PGP SIGNATURE----- ------enig2PMUCVRHEICITFGNOEVMC-- From jbonneau@gmail.com Thu Feb 14 13:49:37 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ABB21F845A for ; Thu, 14 Feb 2013 13:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1Ea2CKWpQel for ; Thu, 14 Feb 2013 13:49:34 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id ABA4921F844F for ; Thu, 14 Feb 2013 13:49:33 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id o13so174931qaj.1 for ; Thu, 14 Feb 2013 13:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tEs+M0c/QWq4Z6IDWytruiZOn6/mGyOzZioPEPbRksY=; b=ncywcOYXhbToLNQg0T73JnjyX/tdbPXLgqvAy9LFTABRnPu+9TGhylvGbXy44ljS37 klwwE2LBOTx3gcWGfsfCZWN7kVr9YKiQ3UdFJBkHXfeQXTGRCp0bBhz05mrOFhZBPFA9 20Ciue1M06MRGa3RMoHtmAz6DGnBfS6BWBYpM2PwtY/YoWipyxwfGwcHrz4yzQnT4Vlu u6dROe9cSqHhKF+wW3g75lxWfIa9Cx2J6ARDHZohJmLN7Uba0aYW/BP/r8L6rGe7d7K3 pCdKGPf+C2cV18500TvLVOhV7YzNvpCkU+s5xV3Ct45FfMNTr/j+IQ9SYvni+eIW0g5g t64g== X-Received: by 10.49.127.240 with SMTP id nj16mr130977qeb.13.1360878572887; Thu, 14 Feb 2013 13:49:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.26.198 with HTTP; Thu, 14 Feb 2013 13:49:12 -0800 (PST) In-Reply-To: <511D4021.1090107@fifthhorseman.net> References: <511C4389.3060904@cs.tcd.ie> <511CD5D9.7050208@cs.tcd.ie> <511D301A.4060608@cs.tcd.ie> <511D327D.5060605@mnt.se> <511D3440.90307@cs.tcd.ie> <511D3655.6030109@mnt.se> <511D3B33.40908@cs.tcd.ie> <511D3DE3.5050601@fifthhorseman.net> <511D4021.1090107@fifthhorseman.net> From: Joseph Bonneau Date: Thu, 14 Feb 2013 16:49:12 -0500 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=047d7b6d9624eb5d5704d5b63b05 Cc: therightkey@ietf.org Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:49:37 -0000 --047d7b6d9624eb5d5704d5b63b05 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 14, 2013 at 2:50 PM, Daniel Kahn Gillmor wrote: > > https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-4.1 > says that compliant user agents "MUST require that hosts set a Backup > Pin." What do you think about adopting comparably-strong language in > the S-links proposal? Certainly possible to add, but I'm not convinced it's necessary. This hedges against sites shooting themselves in the foot, the potential damage from bad s-links seems lower to me. --047d7b6d9624eb5d5704d5b63b05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 14, 2013 at 2:50 PM, Daniel Kahn= Gillmor <dkg@fifthhorseman.net> wrote:
https://tools.ietf.org/html/draft-ietf-websec-k= ey-pinning-04#section-4.1
says that compliant user agents "MUST require that hosts set a Backup<= br> Pin." =C2=A0What do you think about adopting comparably-strong languag= e in
the S-links proposal?

Certainly possible to= add, but I'm not convinced it's necessary. This hedges against sit= es shooting themselves in the foot, the potential damage from bad s-links s= eems lower to me.=C2=A0
--047d7b6d9624eb5d5704d5b63b05-- From gerv@mozilla.org Fri Feb 15 05:56:06 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2EC21F8AE0 for ; Fri, 15 Feb 2013 05:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcjnYFTr52ek for ; Fri, 15 Feb 2013 05:56:05 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id CE3BD21F8ADC for ; Fri, 15 Feb 2013 05:56:05 -0800 (PST) Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 64ACEF22AF; Fri, 15 Feb 2013 05:56:04 -0800 (PST) Message-ID: <511E3E74.4040601@mozilla.org> Date: Fri, 15 Feb 2013 13:56:04 +0000 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20121211 Thunderbird/19.0a2 MIME-Version: 1.0 To: "Hill, Brad" , Richard Barnes , Joseph Bonneau References: <511C4389.3060904@cs.tcd.ie> <370C9BEB4DD6154FA963E2F79ADC6F2E2791B58E@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E2791B58E@DEN-EXDDA-S12.corp.ebay.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:56:06 -0000 On 14/02/13 18:34, Hill, Brad wrote: > It's closest relation is Gerv Markham's Link Fingerprints > (http://www.gerv.net/security/link-fingerprints/), although that > focuses on integrity of linked content to be handled as disposition: > attachment. We may or may not take on that as a "bonus feature" in > WebAppSec, but it is not necessarily implied by the new proposed > charter scope. Hi Brad, Are you interested in the fragment identifier version or the HTML version of Link Fingerprints? I replaced the former with the latter some time back, but can switch back or change the page to show both if the former is interesting. Gerv From bhill@paypal-inc.com Fri Feb 15 14:14:37 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DFC21E8045 for ; Fri, 15 Feb 2013 14:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqL7fhzGqv8n for ; Fri, 15 Feb 2013 14:14:36 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id CF72221E805A for ; Fri, 15 Feb 2013 14:14:36 -0800 (PST) DomainKey-Signature: s=paypalcorp; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter; b=nq4U6GnBOPFwY4qzHynwoyrY67zJnnXy70BF+HR9Qpm26a37iUVqC1vY 5FMchRmXhZrop9AdlQy1BA4lG8J4cUchUhlyjx6F3LMsw9uQT/hVP8kle I/M10uje06zzucLhxhBML8iEN4witNP69K9uzyLYqh4kjU78lhOtwSSTv Y=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=paypalcorp; t=1360966477; x=1392502477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tfyR3W6BXTZHgoccUTK5LKFOk/g3nn9TsnwqcMfpmdg=; b=Ozu0qPuYceEOZUPxoI8AsMcrihpyQG1Vuh/cQx8oJBJzzVO7i1KmU1o4 gHkbSkT73Vz15MY6NUwckDaz0+AooMIE3I7lJ1paprhyC8w7G+XDLwQI/ Dzc1z8ccz1Y3++LWyTXlr2CRipGZJpTkkwQA6WXZ4e9lZuZ2GfT0qJPSj I=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.84,675,1355126400"; d="scan'208";a="12983628" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 15 Feb 2013 14:14:29 -0800 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-002.corp.ebay.com ([fe80::cbe:ffa5:17f0:a24a%14]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 15:14:29 -0700 From: "Hill, Brad" To: Gervase Markham , Richard Barnes , "Joseph Bonneau" Thread-Topic: [therightkey] New proposal: S-links (secure links) Thread-Index: AQHOCghJT3sxCxCZckG5I5JkvBrqt5h5DWCAgAARZoCAAAJNgIAAA6aAgAADy4CAAIM/4IABvegAgAAUyiA= Date: Fri, 15 Feb 2013 22:14:28 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E2791C93E@DEN-EXDDA-S12.corp.ebay.com> References: <511C4389.3060904@cs.tcd.ie> <370C9BEB4DD6154FA963E2F79ADC6F2E2791B58E@DEN-EXDDA-S12.corp.ebay.com> <511E3E74.4040601@mozilla.org> In-Reply-To: <511E3E74.4040601@mozilla.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] New proposal: S-links (secure links) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 22:14:37 -0000 The HTML version is most along the lines we are thinking, thanks. -Brad > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] > On Behalf Of Gervase Markham > Sent: Friday, February 15, 2013 5:56 AM > To: Hill, Brad; Richard Barnes; Joseph Bonneau > Cc: therightkey@ietf.org; Stephen Farrell > Subject: Re: [therightkey] New proposal: S-links (secure links) >=20 > On 14/02/13 18:34, Hill, Brad wrote: > > It's closest relation is Gerv Markham's Link Fingerprints > > (http://www.gerv.net/security/link-fingerprints/), although that > > focuses on integrity of linked content to be handled as disposition: > > attachment. We may or may not take on that as a "bonus feature" in > > WebAppSec, but it is not necessarily implied by the new proposed > > charter scope. >=20 > Hi Brad, >=20 > Are you interested in the fragment identifier version or the HTML version= of > Link Fingerprints? I replaced the former with the latter some time back, = but > can switch back or change the page to show both if the former is interest= ing. >=20 > Gerv >=20 > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Sat Feb 16 10:22:55 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9221F8953; Sat, 16 Feb 2013 10:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=-2.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn0sB2+6UtxB; Sat, 16 Feb 2013 10:22:54 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id A22B621F8930; Sat, 16 Feb 2013 10:22:53 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so2238263wib.9 for ; Sat, 16 Feb 2013 10:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mhWeL7kjJLap9HNa5NHMm97l86OvwXO7JPfPET7oqAU=; b=D4AYCQ98so6IBf4lVsXG9iEwnym+gFfCNKVdI6xu23PMI4k0F2LG1W+Ywq8VvMNodj sHCzLdKGXKabboEX1D579KQsocX71t15WgzlUvijGBoKwa8vK8RqIpl5zb3gVKEPPzfN XRQApS22dT1QujLzTxYTHPPex1fQJSWQ1EsLLzBplacKfpJesvXC8TvNG6dEjLLtUGfM wVkgOEX7pNIf1xSP2/PCgOLWsfA/fd3Nhdhh7sIj9GP1J5geeW3pen89+hblp6xm6eg0 QvM0j7RJ2YZwmARFnLB0RQem1TCmIl5/feVYuJ4i1cUmfbObJPcTd+3gl04KaBerSsde zsaQ== MIME-Version: 1.0 X-Received: by 10.180.100.169 with SMTP id ez9mr12326625wib.3.1361038972848; Sat, 16 Feb 2013 10:22:52 -0800 (PST) Received: by 10.194.176.169 with HTTP; Sat, 16 Feb 2013 10:22:52 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 13:22:52 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=14dae9cc9c56808b2304d5db9408 Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , IETF Discussion List , =JeffH Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 18:22:55 -0000 --14dae9cc9c56808b2304d5db9408 Content-Type: text/plain; charset=ISO-8859-1 Sorry for the delay but I have been thinking of CT and in particular the issues of * Latency for the CA waiting for a notary server to respond * Business models for notary servers As a rule open source software works really well as the marginal cost of production is zero. Open source services tend to sux because even though the marginal cost of a service is negligible, large numbers times negligible adds up to big numbers. Running a DNS server for a university department costs very little, running it for the whole university starts to cost real money and running a registry like .com with 99.9999% reliability ends up with $100 million hardware costs. So the idea that I plug my business into a network of notary servers being run by amateurs or as a community service is a non-starter for me. We have to align the responsibility for running any server that the CA has a critical dependency on with a business model. Looking at the CT proposal, it seems to me that we could fix the business model issue and remove a lot of the CA operational issues as follows: 1) Each browser provider that is interested in enforcing a CT requirement stands up a meta-notary server. 2) Each CA runs their own notary server and this is the only resource that needs to have a check in at certificate issue. 3) Each CA notary server checkpoints to one or more meta-notary servers every 60 minutes. As part of the check in process it uploads the whole information for all the certificates issued in that time interval. 4) Meta-Notaries deliver tokens that assert that the CA notaries are current every 60 minutes. Note here that 'current' is according to the criteria set by the meta notary. This is an intentional piece of 'slop' in the system. 5) The OCSP tokens delivered by the CA contain the information necessary to checkpoint the certificate to the Meta-Notaries. 6) A browser enforcing CT disclosure pulls a list of anchor points from its chosen meta-notary every 60 minutes and uses them to validate the CT assertions delivered in certs. The 'slop' introduced at the meta-notary can of course be removed if we want to ensure that the system is robust even if there is a collusion between the CA and the meta-notary. But since the whole point of the scheme is transparency, the meta-notary operation can be audited by third parties in any event. --14dae9cc9c56808b2304d5db9408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for the delay but I have been thinking of CT and in particular the is= sues of

* Latency for the CA waiting for a notary server to res= pond
* Business models for notary servers

As a rule open source software works really well as the marginal cost of = production is zero. Open source services tend to sux because even though th= e marginal cost of a service is negligible, large numbers times negligible = adds up to big numbers. Running a DNS server for a university department co= sts very little, running it for the whole university starts to cost real mo= ney and running a registry like .com with 99.9999% reliability ends up with= $100 million hardware costs.

So the idea that I plug my business into a network of n= otary servers being run by amateurs or as a community service is a non-star= ter for me. We have to align the responsibility for running any server that= the CA has a critical dependency on with a business model.

Looking at the CT proposal, it seems to me that we coul= d fix the business model issue and remove a lot of the CA operational issue= s as follows:

1) Each browser provider that is int= erested in enforcing a CT requirement stands up a meta-notary server.

2) Each CA runs their own notary server and this is the= only resource that needs to have a check in at certificate issue.

3) Each CA notary server checkpoints to one or more meta-n= otary servers every 60 minutes. As part of the check in process it uploads = the whole information for all the certificates issued in that time interval= .

4) Meta-Notaries deliver tokens that assert that the CA= notaries are current every 60 minutes. Note here that 'current' is= according to the criteria set by the meta notary. This is an intentional p= iece of 'slop' in the system.=A0

5) The OCSP tokens delivered by the CA contain the info= rmation necessary to checkpoint the certificate to the Meta-Notaries.
=

6) A browser enforcing CT disclosure pulls a list of an= chor points from its chosen meta-notary every 60 minutes and uses them to v= alidate the CT assertions delivered in certs.


The 'slop' introduced at the met= a-notary can of course be removed if we want to ensure that the system is r= obust even if there is a collusion between the CA and the meta-notary. But = since the whole point of the scheme is transparency, the meta-notary operat= ion can be audited by third parties in any event.=A0

--14dae9cc9c56808b2304d5db9408-- From paul.hoffman@vpnc.org Sat Feb 16 10:54:39 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1355421F87CE; Sat, 16 Feb 2013 10:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYWmPBo5wDGK; Sat, 16 Feb 2013 10:54:37 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1DE21F86AF; Sat, 16 Feb 2013 10:54:37 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1GIsW2B020451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 16 Feb 2013 11:54:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Sat, 16 Feb 2013 10:54:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <72D4ABBB-9B39-41F6-9AFF-37F0A7DBDAC1@vpnc.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org, IETF Discussion List Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 18:54:39 -0000 On Feb 16, 2013, at 10:22 AM, Phillip Hallam-Baker = wrote: > Looking at the CT proposal, it seems to me that we could fix the = business model issue and remove a lot of the CA operational issues as = follows: >=20 > 1) Each browser provider that is interested in enforcing a CT = requirement stands up a meta-notary server. >=20 > 2) Each CA runs their own notary server and this is the only resource = that needs to have a check in at certificate issue. >=20 > 3) Each CA notary server checkpoints to one or more meta-notary = servers every 60 minutes. As part of the check in process it uploads the = whole information for all the certificates issued in that time interval. >=20 > 4) Meta-Notaries deliver tokens that assert that the CA notaries are = current every 60 minutes. Note here that 'current' is according to the = criteria set by the meta notary. This is an intentional piece of 'slop' = in the system.=20 >=20 > 5) The OCSP tokens delivered by the CA contain the information = necessary to checkpoint the certificate to the Meta-Notaries. >=20 > 6) A browser enforcing CT disclosure pulls a list of anchor points = from its chosen meta-notary every 60 minutes and uses them to validate = the CT assertions delivered in certs. Are you saying that those six items should be added to the experimental = RFC as requirements, or are you just discussing what might happen = operationally after the RFC is published?=20 --Paul Hoffman= From benl@google.com Sat Feb 16 10:55:59 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F29221F8857 for ; Sat, 16 Feb 2013 10:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jPmukO0q++3 for ; Sat, 16 Feb 2013 10:55:58 -0800 (PST) Received: from mail-ia0-x22e.google.com (ia-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C9E1121F87CE for ; Sat, 16 Feb 2013 10:55:58 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so51408iag.33 for ; Sat, 16 Feb 2013 10:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9GCLH3GRy1sXy/A0r1frGN4WexvkDPA0VvbVHlqlbvg=; b=j9Znx05zHMHbrYwWhXiidxeV53ZvLABu9pRzBBA1s8Ikmnb2v+yeYPk79ORZVN7OtU EDcbX0Gabn9rXIk7GdSI6hN3h3TAS8527c2widbWXCG1vfj/vDbjYZyxV9H0FlxTwOqX SPztoFoGU11/cElGdSXYzLX5LlPJgh4Pra+ndFwnKBg2C/MhFbIzDmnNZ9oNUyGjdqEC 6wNaKzZNls7pBK5TO5EDFfz67D+dIGt8xelGGSwJQOPKdnrb6o+pVDv2y1oNvkZ2almh IOSbXAQ+yMX8HwotLjb7jBKL1IAk1XySfjZI9f7ghTS2yd2Qii/ANAh3YYcrFtUQcOfZ ZmVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=9GCLH3GRy1sXy/A0r1frGN4WexvkDPA0VvbVHlqlbvg=; b=mGaZjWAzfETDCdQX1pWps+jAM/lLHCNoVMOT0mo4/JB3exQANAYz9ZJMuS0ISTzS5E Y7Qa3lMQZXzxBti/vXSdtOR2MZoLPsUaDymeT478Rp1n0wl3JB8rt0sgCmfCXoqZ2Vp1 7AZAcO8gaqKfON5q1k/7FCI727DRTmrbD1nedV9D7ztMWxB1PnKPnfsx9ICSLKhu2214 BpSUzJ3HcvnhJ/oKVYlmuKJOKhSaNq0TwLOgFMRiAX+3lLQLfNRNAnP0wDH1WhlvfVrB ocpFQEajTAnhPE++ZGMuTsN2WkEFNh1/HIKux6G4PWFUuTbrAbY0clD1O7se0hWf0CJ/ K+8g== MIME-Version: 1.0 X-Received: by 10.50.17.201 with SMTP id q9mr4680814igd.107.1361040958321; Sat, 16 Feb 2013 10:55:58 -0800 (PST) Received: by 10.64.19.136 with HTTP; Sat, 16 Feb 2013 10:55:58 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 10:55:58 -0800 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnE+K2fPVbjZczydkIJOUM+vVIGESzJHiL4MaspkNAhdv0nKfGTc02uFEngJ0fvjjLBIo8scqP4NduzNf2BRYs3jKXOLYTgi2nIla2/u4ARlM8szmx9oRPTU1arnNoubeP/Y3hNKQS35Hmqg2lXSI+9BWMM5xjC8bpietT8mqQlZylmBhUI8lQXOC3zorhlwNDTCuZ5 Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , IETF Discussion List , =JeffH Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 18:55:59 -0000 On 16 February 2013 10:22, Phillip Hallam-Baker wrote: > Sorry for the delay but I have been thinking of CT and in particular the > issues of > > * Latency for the CA waiting for a notary server to respond > * Business models for notary servers > > As a rule open source software works really well as the marginal cost of > production is zero. Open source services tend to sux because even though the > marginal cost of a service is negligible, large numbers times negligible > adds up to big numbers. Running a DNS server for a university department > costs very little, running it for the whole university starts to cost real > money and running a registry like .com with 99.9999% reliability ends up > with $100 million hardware costs. > > So the idea that I plug my business into a network of notary servers being > run by amateurs or as a community service is a non-starter for me. We have > to align the responsibility for running any server that the CA has a > critical dependency on with a business model. Note that we do not expect CAs to talk to _all_ log servers, only those that are appropriately responsive - and also note that a CA can fire off a dozen log requests in parallel and then just use the first three that come back, which would deal with any temporary log issues. We should probably add this ability to the open source stack at some point. > Looking at the CT proposal, it seems to me that we could fix the business > model issue and remove a lot of the CA operational issues as follows: > > 1) Each browser provider that is interested in enforcing a CT requirement > stands up a meta-notary server. > > 2) Each CA runs their own notary server and this is the only resource that > needs to have a check in at certificate issue. Isn't this part the only part that's actually needed? The meta-notaries seem like redundant extra complication (and also sound like they fulfil essentially the same role as monitors). I assume, btw, that by "notary server" you mean "log server"? Also, if a CA only uses its own log, what happens when it screws up and gets its log struck off the list of trusted logs? This is why we recommend some redundancy in log signatures. > 3) Each CA notary server checkpoints to one or more meta-notary servers > every 60 minutes. As part of the check in process it uploads the whole > information for all the certificates issued in that time interval. > > 4) Meta-Notaries deliver tokens that assert that the CA notaries are current > every 60 minutes. Note here that 'current' is according to the criteria set > by the meta notary. This is an intentional piece of 'slop' in the system. > > 5) The OCSP tokens delivered by the CA contain the information necessary to > checkpoint the certificate to the Meta-Notaries. > > 6) A browser enforcing CT disclosure pulls a list of anchor points from its > chosen meta-notary every 60 minutes and uses them to validate the CT > assertions delivered in certs. > > > The 'slop' introduced at the meta-notary can of course be removed if we want > to ensure that the system is robust even if there is a collusion between the > CA and the meta-notary. But since the whole point of the scheme is > transparency, the meta-notary operation can be audited by third parties in > any event. > From hallam@gmail.com Sat Feb 16 16:24:12 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D289221F8A5F; Sat, 16 Feb 2013 16:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOS4jC-u36Oh; Sat, 16 Feb 2013 16:24:11 -0800 (PST) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5789621F8A47; Sat, 16 Feb 2013 16:24:11 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so1829677wgh.1 for ; Sat, 16 Feb 2013 16:24:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dlrDbfKfWzX5knvTWSzHzoA6mXW4/R+O0DoN5rHbXlU=; b=o+GGFf2Nx6JqQ7CQ5222fIz6YujfKAIub8mdtW5YAx4OX7QH3ge8kKfgSe4G6VqLvV j/1EM2ikHXWQ7loCdFXs9sAQiIhz3BrepshNnD4LlxayX6Zqez6OLjeqFN2dzGmV6Koq tU3DrS8MBONYzy9sbgselqBRewB6A3KMA26zA5dYa1kpWHBmgAat27xJ16pscCF/7XqA JUYhB0lS3jQgaj0/JYXZ6Fk9/Madm8rRueHZwKe/RJNiL5lKVusOcsnyG1WgqnJRJTI+ ItA2Xv23Hw6ftXX0OwN4W+QfYwj7C4PKKyYrODN0kHvq3f1eEtlGOxXYj9VfWwOv9egI kdoA== MIME-Version: 1.0 X-Received: by 10.194.156.170 with SMTP id wf10mr11499066wjb.25.1361060650309; Sat, 16 Feb 2013 16:24:10 -0800 (PST) Received: by 10.194.176.169 with HTTP; Sat, 16 Feb 2013 16:24:09 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 19:24:09 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=089e012280fc94596804d5e0a0a0 Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , IETF Discussion List , =JeffH Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 00:24:12 -0000 --089e012280fc94596804d5e0a0a0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 16, 2013 at 1:55 PM, Ben Laurie wrote: > On 16 February 2013 10:22, Phillip Hallam-Baker wrote: > > Sorry for the delay but I have been thinking of CT and in particular the > > issues of > > > > * Latency for the CA waiting for a notary server to respond > > * Business models for notary servers > > > > As a rule open source software works really well as the marginal cost of > > production is zero. Open source services tend to sux because even though > the > > marginal cost of a service is negligible, large numbers times negligible > > adds up to big numbers. Running a DNS server for a university department > > costs very little, running it for the whole university starts to cost > real > > money and running a registry like .com with 99.9999% reliability ends up > > with $100 million hardware costs. > > > > So the idea that I plug my business into a network of notary servers > being > > run by amateurs or as a community service is a non-starter for me. We > have > > to align the responsibility for running any server that the CA has a > > critical dependency on with a business model. > > Note that we do not expect CAs to talk to _all_ log servers, only > those that are appropriately responsive - and also note that a CA can > fire off a dozen log requests in parallel and then just use the first > three that come back, which would deal with any temporary log issues. > > We should probably add this ability to the open source stack at some point. > > > Looking at the CT proposal, it seems to me that we could fix the business > > model issue and remove a lot of the CA operational issues as follows: > > > > 1) Each browser provider that is interested in enforcing a CT requirement > > stands up a meta-notary server. > > > > 2) Each CA runs their own notary server and this is the only resource > that > > needs to have a check in at certificate issue. > > Isn't this part the only part that's actually needed? The > meta-notaries seem like redundant extra complication (and also sound > like they fulfil essentially the same role as monitors). > > I assume, btw, that by "notary server" you mean "log server"? > > Also, if a CA only uses its own log, what happens when it screws up > and gets its log struck off the list of trusted logs? This is why we > recommend some redundancy in log signatures. That is the reason for checkpointing against meta notaries. Otherwise a CA might not actually release the logs. -- Website: http://hallambaker.com/ --089e012280fc94596804d5e0a0a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 16, 2013 at 1:55 PM, Ben Lau= rie <benl@google.com> wrote:
On 16 February 2013 10:22, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Sorry for the delay but I have been thinking of CT and in particular t= he
> issues of
>
> * Latency for the CA waiting for a notary server to respond
> * Business models for notary servers
>
> As a rule open source software works really well as the marginal cost = of
> production is zero. Open source services tend to sux because even thou= gh the
> marginal cost of a service is negligible, large numbers times negligib= le
> adds up to big numbers. Running a DNS server for a university departme= nt
> costs very little, running it for the whole university starts to cost = real
> money and running a registry like .com with 99.9999% reliability ends = up
> with $100 million hardware costs.
>
> So the idea that I plug my business into a network of notary servers b= eing
> run by amateurs or as a community service is a non-starter for me. We = have
> to align the responsibility for running any server that the CA has a > critical dependency on with a business model.

Note that we do not expect CAs to talk to _all_ log servers, only
those that are appropriately responsive - and also note that a CA can
fire off a dozen log requests in parallel and then just use the first
three that come back, which would deal with any temporary log issues.

We should probably add this ability to the open source stack at some point.=

> Looking at the CT proposal, it seems to me that we could fix the busin= ess
> model issue and remove a lot of the CA operational issues as follows:<= br> >
> 1) Each browser provider that is interested in enforcing a CT requirem= ent
> stands up a meta-notary server.
>
> 2) Each CA runs their own notary server and this is the only resource = that
> needs to have a check in at certificate issue.

Isn't this part the only part that's actually needed? The
meta-notaries seem like redundant extra complication (and also sound
like they fulfil essentially the same role as monitors).

I assume, btw, that by "notary server" you mean "log server&= quot;?

Also, if a CA only uses its own log, what happens when it screws up
and gets its log struck off the list of trusted logs? This is why we
recommend some redundancy in log signatures.

That is the reason for checkpointing against meta notaries.
=A0=
Otherwise a CA might not actually release the logs.

--
Website: http://h= allambaker.com/
--089e012280fc94596804d5e0a0a0-- From stephen.farrell@cs.tcd.ie Mon Feb 18 06:58:56 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E34F21F89F9 for ; Mon, 18 Feb 2013 06:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EnbySZ2jtpF for ; Mon, 18 Feb 2013 06:58:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C943F21F8A48 for ; Mon, 18 Feb 2013 06:58:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B84DEBE38 for ; Mon, 18 Feb 2013 14:58:07 +0000 (GMT) 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 rI0KVoAbqBxi for ; Mon, 18 Feb 2013 14:58:07 +0000 (GMT) Received: from [IPv6:2001:770:10:203:70b4:a884:3fa8:8567] (unknown [IPv6:2001:770:10:203:70b4:a884:3fa8:8567]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9918FBE29 for ; Mon, 18 Feb 2013 14:58:07 +0000 (GMT) Message-ID: <5122417F.8090500@cs.tcd.ie> Date: Mon, 18 Feb 2013 14:58:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <201302181453.r1IErhWQ036131@givry.fdupont.fr> In-Reply-To: <201302181453.r1IErhWQ036131@givry.fdupont.fr> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <201302181453.r1IErhWQ036131@givry.fdupont.fr> Content-Type: multipart/mixed; boundary="------------020405080701080301090003" Subject: [therightkey] Fwd: review of draft-laurie-pki-sunlight-07.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 14:58:56 -0000 This is a multi-part message in MIME format. --------------020405080701080301090003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: review of draft-laurie-pki-sunlight-07.txt Resent-To: agl@google.com, benl@google.com, ekasper@google.com, stephen@tolerantnetworks.com Date: Mon, 18 Feb 2013 15:53:43 +0100 From: Francis Dupont To: gen-art@ietf.org CC: draft-laurie-pki-sunlight.all@tools.ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-laurie-pki-sunlight-07.txt Reviewer: Francis Dupont Review Date: 20130208 IETF LC End Date: 20130226 IESG Telechat date: unknown Summary: Almost Ready Major issues: None Minor issues: - section 2 is not enough accurate, for instance: * the critical [k1:k2] notation is introduced after its first use, IMHO it is the primary one, i.e., [n] is a short hand for [0:n] * the largest power of two must be strictly smaller, not just smaller. Without this critical detail recursion rules don't work for n = 2^m Unfortunately there is no wikipedia or equivalent web page where to refer to so the document is the place where all gory details have to be... - the Maximum Merge Delay (MMD) is an important parameter but I can't find where is the way users get its value, nor any recommendation for it. Nits/editorial comments: - 1 page 4: CA is not a well known abbrev so please introduce it (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) - 1 page 4: it is a general mechanism but what are its constraints at the exception of the intended usage. For instance is the mechanism applicable to any end entity public key certificate? or larger?? - 1 page 5: misbehaviours -> misbehaviors (and 3.3 page 16, and others too) - 1 page 5: e.g. -> e.g., - 2.1.1 page 6: i.e. -> i.e., - 2.1.1 page 7 and 2.1.2 page 8: the wording "the length (k2 - k1) list" is IMHO a bit uncommon even I can understand it. - 2.1.4 page 10: using a key of at least 2048 bits. -> using a public key of at least 2048 bits. (or a modulus as it is for RSA?) - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not ASN.1 itself, nor C? - 3.1 page 12: accomodate -> accommodate - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they are insipid and stupid :-) - 3.1 page 13: submmited -> submitted - 3.2 page 14: opaque TBSCertificate<1..2^16-1> add final ';' - 4.6 page 22: honour -> honor - 4.6 page 22: convering -> covering? BTW if the document creates new OID perhaps they should be put in an annex? Regards Francis.Dupont@fdupont.fr PS: I noted there are still some LC comments in the ML. --------------020405080701080301090003 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------020405080701080301090003-- From ekasper@google.com Fri Feb 22 02:19:48 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1421F8E40 for ; Fri, 22 Feb 2013 02:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoI-vpS+uq69 for ; Fri, 22 Feb 2013 02:19:47 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0D86421F8CAB for ; Fri, 22 Feb 2013 02:19:46 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so374440wgl.6 for ; Fri, 22 Feb 2013 02:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=31aIozX0y3egsfcKA9EiYjZGDEJD+RA1UIeBwVVeDtk=; b=IZKGCZjMLZsBMT/hLppjpO+UAqH5lVuQ6c26Q5glh/rfwB8BXklfhHlp4c9hQcqZAt OysN5P0h0eauMimpelDoRLUQcGMltTZlm7Y9laaMBazbcSVhSs9lGsuaPq0Z9myx7Hyl jSpH5yGZpRtK1AQLyZKtoRzlHdjD5MtPof39eDPLHkaEjO/lG72bkYayp48uV4hvwXGb 0lFLRPrBp1Lo4FffY0rA9P8czsSyqQe1Z00DPbxkcB1I6xUvGr6nXhhIMFAVdGXrRWmA 8aiI04hIhyq1jdPCD49j/ajhCe3TXfPHgB+KQ16aGDa9R7rGhMoMIk1AtpN6ZArlPuui baeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=31aIozX0y3egsfcKA9EiYjZGDEJD+RA1UIeBwVVeDtk=; b=pUpPiG0jSjfIzpmcoN11n6JEUdmDiAIYuI2g4BzlYPJhKQhrwx6EW90Bd/mK58Lx0r ldW6yF/Uy6g2F1bFhtSZUfsgodvXphKzgHu1ZFP8YgJ/5ho6LAj2un6MLFhdfwuFP2U2 03gqCM8GjZAgFe1vGNSl95N+D1p9wt1aEN2emNQtMPifRpa7Zo4WoeXq63b/K3M3wOAA aV2SsLf55b/b6TI6yvqioNcoVlSoduTkkiHvvR3/CA+VYMMg28/IQUlwLX1R3WuL4ZaX A3vOxq1sFHPVe3w0GFSWKmzif09HF3fmx4utM5QZcAM5QU5pakjfFu4hY1Y8bi04XR1r Gk4Q== MIME-Version: 1.0 X-Received: by 10.180.97.99 with SMTP id dz3mr2239094wib.8.1361528385187; Fri, 22 Feb 2013 02:19:45 -0800 (PST) Received: by 10.194.60.41 with HTTP; Fri, 22 Feb 2013 02:19:45 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Feb 2013 11:19:45 +0100 Message-ID: From: Emilia Kasper To: "therightkey@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426e68c02dd904d64d8794 X-Gm-Message-State: ALoCoQmumTiYF0lKJjq2sg4jlTaxM/YRVpwVLvMw1iQLDWpficzVPqReEgLnLwtnau6duxza6gAC0L2VtyKdgWOZ+neyva2bhzLf2aV++SgyzxXWjj50Q9T21lVQuqxQb3F8h+8zJzUcTmCqaBWxugPJqWbzUVKsWL1QH1AGuOrsbxrSapW8z+90rB1I2W32IzeW6kB2XQoC Subject: [therightkey] Fwd: Changes to draft-laurie-pki-sunlight-07.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:19:48 -0000 --f46d04426e68c02dd904d64d8794 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Emilia Kasper Date: Fri, Feb 22, 2013 at 11:19 AM Subject: Changes to draft-laurie-pki-sunlight-07.txt To: draft-laurie-pki-sunlight@tools.ietf.org Hi all, We have identified some small ambiguities/inconsistencies in the draft and propose the following fixes: * Sect. 3.1 - explicitly mention that the special-purpose Precert Issuing Certificate should be a CA certificate. (Note this certificate can be made invalid outside the context of CT by marking the Extended Key Usage extension critical.) * Sect 3.1 - "The precertificate Signing Certificate MUST be certified by the CA certificate..." could read "The precertificate Signing Certificate MUST be directly certified by the CA certificate..." for extra clarity. * Sect. 3.1 "In case of Precertificates, each log MUST also verify that the Precertificate Signing Certificate has the correct Extended Key Usage extension" is superfluous, and can be removed. A Precertificate Signing Certificate is identified as such by its EKU extension. * Sect. 3.1 We note that a log's set of accepted root certificates may change over time, so retrieving currently accepted root certificates may not suffice to determine the root certificate used to verify a certificate's issuer chain. We propose to require that logs record the root in the chain and produce it upon request (in the client message of Sect. 4.6, "Retrieve entries from Log"). That is, in Sect.3.1, "The self-signed root certificate MAY be omitted from the chain" should read "The final certificate MUST be a root certificate accepted by the log", twice. Sections 4.1 and 4.2 remain unchanged, i..e, it is not required for clients to include the root certificate in the submission. * Sect 3.2 mentions that if a Precertificate Signing Certificate is used, "the TBSCertificate also has its issuer changed to that of the CA that will issue the final certificate". We propose to clarify the handling of the Authority Key Identifier extension in this case by requiring that "if an Authority Key Identifier extension is present in the TBSCertificate, the corresponding extension must also be present in the Precertificate Signing Certificate - in this case, the TBSCertificate also has its Authority Key Identifier changed to match the final issuer". * Sect 3.4 In the TimestampedEntry structure, "case precert_entry: TBSCertificate" should read "case precert_entry: PreCert" to match what is signed in the SignedCertificateTimestamp. Best, Emilia --f46d04426e68c02dd904d64d8794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


---------- Forwarded me= ssage ----------
From: Emilia Kasper <= span dir=3D"ltr"><ekasper@google.c= om>
Date: Fri, Feb 22, 2013 at 11:19 AM
Subject: Changes to draft-laurie-pki= -sunlight-07.txt
To: draft-laurie-pki-sunlight@tools.ietf.org


Hi all,

We have identified some small ambiguities/incons= istencies in the draft and propose the following fixes:

* Sect. 3.1 - explicitly mention that the special-purpose Precert Iss= uing Certificate should be a CA certificate. (Note this certificate can be = made invalid outside the context of CT by marking the Extended Key Usage ex= tension critical.)

* Sect 3.1 - "The precertificate Signing Certifica= te MUST be certified by the CA certificate..." could read "The pr= ecertificate Signing Certificate MUST be directly certified by the CA certi= ficate..." for extra clarity.

* Sect. 3.1 =A0"In case of Precertificates, each l= og MUST also verify that the Precertificate Signing Certificate has the cor= rect Extended Key Usage extension" is superfluous, and can be removed.= A Precertificate Signing Certificate is identified as such by its EKU exte= nsion.

* Sect. 3.1 =A0We note that a log's set of accepted= root certificates may change over time, so retrieving currently accepted r= oot certificates may not suffice to determine the root certificate used to = verify a certificate's issuer chain. We propose to require that logs re= cord the root in the chain and produce it upon request (in the client messa= ge of Sect. 4.6, "Retrieve entries from Log").

That is, in Sect.3.1, =A0"The self-signed root cer= tificate MAY be omitted from the chain" should read "The final ce= rtificate MUST be a root certificate accepted by the log", twice. Sect= ions 4.1 and 4.2 remain unchanged, i..e, it is not required for clients to = include the root certificate in the submission.

* Sect 3.2 mentions that if a Precertificate Signing Ce= rtificate is used, "the TBSCertificate also has its issuer changed to = that of the CA that will issue the final certificate". We propose to c= larify the handling of the Authority Key Identifier extension in this case = by requiring that "if an Authority Key Identifier extension is present= in the TBSCertificate, the corresponding extension must also be present in= the Precertificate Signing Certificate - =A0in this case, the TBSCertifica= te also has its Authority Key Identifier changed to match the final issuer&= quot;.

* Sect 3.4 In the TimestampedEntry structure, "cas= e precert_entry: TBSCertificate" should read "case precert_entry:= PreCert" to match what is signed in the SignedCertificateTimestamp.

Best,
Emilia



--f46d04426e68c02dd904d64d8794-- From benl@google.com Fri Feb 22 03:17:53 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9B821F8E7B for ; Fri, 22 Feb 2013 03:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07SsocevHynZ for ; Fri, 22 Feb 2013 03:17:52 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6256F21F8E87 for ; Fri, 22 Feb 2013 03:17:52 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id u20so439218iag.33 for ; Fri, 22 Feb 2013 03:17:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Qgv6TfJpTMh9my6i2QMqH4OHHwEJ+lVMb3mcxKFL++Y=; b=mD2U7O2G/44fv4ZaZjXWcPUd2tSdtmeL84IeJMvhV4HPgYtumP+loy4RAgD6EZBt6o QxTiEgTuJ/O95RA9XB7IA52jFZaY777RgQHrwEGbj6lr7YBqt++ybEqhtzpTZTERSIrR SxVqkxtoDXEqO8E2ompILR5cAU3SPL0tDPBvSe/yE/lTSDBlC4OLj8INsVXulMq+a23p p2ZGPGfItQn6DPvxtnbCQgTd3ahpLE3ydM1rSzDhpRtfnZ371C7Ee3uqlysehrFYg3Pl V2X/cSwAgIfVL2hPcvsL4ewmmboO/PTmRNHoWSOwPe3Lj5rWYz1SrrcoQ/vxmVXvPFvp vooA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Qgv6TfJpTMh9my6i2QMqH4OHHwEJ+lVMb3mcxKFL++Y=; b=Dq1+5+ETRmNU0sXsh2s4CT6X0vgp61B2X4avN70uB/JLwm6a4O6PdUI0TkvYTzETpn ifpJike7kvIBGLb0123u4T19qCUMqACBXQXuZbi1j3ssYgI8gNMjCKmhbfuUSjdwtTru usD8uYcJOu7vvScJhNK997knSOrDgT+afWs4EzrQc/crfpDLvjjWcjg8VNAD67RVQtMy ZkFk0vz209c1OQ7orLA71qO9B1DiigdV7DjI3uUsR4S2gVNxvSYZneGODExwvI12SFV8 ZAXR6N7ZNOBbg4loiKrkiAJUo3LuHBfe1ji0FPMkaO1Tk/SoxHKiCpsRyWUrYS1SY9lJ 8H+w== MIME-Version: 1.0 X-Received: by 10.50.153.198 with SMTP id vi6mr14912231igb.112.1361531871938; Fri, 22 Feb 2013 03:17:51 -0800 (PST) Received: by 10.64.140.71 with HTTP; Fri, 22 Feb 2013 03:17:51 -0800 (PST) In-Reply-To: <201302181453.r1IErhWQ036131@givry.fdupont.fr> References: <201302181453.r1IErhWQ036131@givry.fdupont.fr> Date: Fri, 22 Feb 2013 11:17:51 +0000 Message-ID: From: Ben Laurie To: Francis Dupont , "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkxGmX1fqZ2BAGeQ0xAZX0DO9oA1UHtLNE9edRJPkVd59VPH9aFpwbCc72g0zKZUktkzWDRSVwWMFwoMl/nOaxT01bPIfzVE687UGxTa3vW5BV+EzvKZBXXAifDh1fSfZEZiRVDC4V81Efpg49YZclrvjViu4a/KeFr06ZNPo+ugViQFojzQVhiPO3SGZ+AstBykzsf Cc: gen-art@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org Subject: Re: [therightkey] review of draft-laurie-pki-sunlight-07.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:17:53 -0000 On 18 February 2013 14:53, Francis Dupont wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-laurie-pki-sunlight-07.txt > Reviewer: Francis Dupont > Review Date: 20130208 > IETF LC End Date: 20130226 > IESG Telechat date: unknown > > Summary: Almost Ready > > Major issues: None > > Minor issues: > - section 2 is not enough accurate, for instance: > * the critical [k1:k2] notation is introduced after its first use, IMHO > it is the primary one, i.e., [n] is a short hand for [0:n] Notation is rather tricky here, but I don't think that saying D[n] is shorthand for D[0:n] adds clarity. This is because D[k:n] becomes D[n-k] on recursion. Saying D[k:n] is the same as D[0:n-k] is just confusing (and, indeed, wrong). > * the largest power of two must be strictly smaller, not just smaller. There is no difference between "strictly smaller" and "smaller" (in contrast to "decreasing" and "strictly decreasing"). > Without this critical detail recursion rules don't work for n = 2^m > Unfortunately there is no wikipedia or equivalent web page where to refer to > so the document is the place where all gory details have to be... > > - the Maximum Merge Delay (MMD) is an important parameter but I can't find > where is the way users get its value, nor any recommendation for it. We anticipate that this will be published in some kind of human readable policy. > Nits/editorial comments: > - 1 page 4: CA is not a well known abbrev so please introduce it > (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) Fixed. > - 1 page 4: it is a general mechanism but what are its constraints at > the exception of the intended usage. For instance is the mechanism > applicable to any end entity public key certificate? or larger?? I don't know what this comment refers to. > - 1 page 5: misbehaviours -> misbehaviors > (and 3.3 page 16, and others too) I am not American. > - 1 page 5: e.g. -> e.g., Fixed. > - 2.1.1 page 6: i.e. -> i.e., Fixed. > - 2.1.1 page 7 and 2.1.2 page 8: the wording "the length (k2 - k1) list" > is IMHO a bit uncommon even I can understand it. It's maths. > - 2.1.4 page 10: using a key of at least 2048 bits. -> > using a public key of at least 2048 bits. (or a modulus as it is for RSA?) The public and private keys are the same length in RSA (and the length is the length of the modulus). > - 3 pages 13, 14, etc: what is the language used for ASN.1? It is not > ASN.1 itself, nor C? The format of certificates is defined elsewhere. The name ASN.1Cert (which is what I assume you refer to) is taken from RFC 5246. > - 3.1 page 12: accomodate -> accommodate Fixed. > - 3.1 page 13: parenthesis around 65535 are not necessary (i.e, they > are insipid and stupid :-) I love you, too. In fact, they are required, see section 4.5 of RFC 5246. > - 3.1 page 13: submmited -> submitted Fixed. > - 3.2 page 14: opaque TBSCertificate<1..2^16-1> add final ';' Fixed. > - 4.6 page 22: honour -> honor No. > - 4.6 page 22: convering -> covering? Fixed. > BTW if the document creates new OID perhaps they should be put in an annex? I am not aware of a requirement to do so. Thanks for your comments! > Regards > > Francis.Dupont@fdupont.fr > > PS: I noted there are still some LC comments in the ML. I am not aware of any I have missed. From benl@google.com Fri Feb 22 03:18:49 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D390321F8721 for ; Fri, 22 Feb 2013 03:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTGPLv0yMOJC for ; Fri, 22 Feb 2013 03:18:49 -0800 (PST) Received: from mail-ia0-x232.google.com (ia-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E301821F873C for ; Fri, 22 Feb 2013 03:18:42 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so449388iab.9 for ; Fri, 22 Feb 2013 03:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZwGzg2BH62kO5rVkpbM2lcWy9kHgZGwHszJsALrYc4g=; b=L7E/4p5VPOx58/lpz1QOazigUp4WpYhpYLCBUQFs5d4ycZSv88kU+aSDK5N4kIc3Ty A1iKXlHP52HoSWiAIAJClCdrYHubniel0GUN2lPBX5E7RpHej5dc4TZMt40XyKbsgEaG QPDJypbm8H1whmJMC0/tT3zOAyc/FOOOM11qzCK/SKQgbpJGXSRLP7Qh4j0mQmMDwsZD VnmclVGVhzhIlXFbV7MVcNYF16Vtx8qcZ2qMqFTQyIy99/lT5Jh0Uqfov1jOwd9Rh63q QsjeQF3eJ/u5zwywhgb3CAWxRJJzYxRx/wkgqhnMH742O1FvbAhc0ZNkk/YCBkgrbdol LMvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ZwGzg2BH62kO5rVkpbM2lcWy9kHgZGwHszJsALrYc4g=; b=Jx9yiu/cIhLFLo3PJDPT+MehWkDoWTvOCesvDAmg9HemmhSN76FoqtoTp8krXyZqVa jrKe3KQ1Ag/SFVUfqlExiQWgJWdvTXkPVF7qHnZfQf5UCWXe/BZoGUQAmaorq9o8U/H4 KC6Iti9Bp2VLnNnBTd/UWSykc1alDtGZCy7EKRgAga9lqxrXD+rumcP8YGla9PQPmwgy oSFqK+5uWjANzasExRiFzvY07zPjM8DO5HejehDoEyJA82RdzaKnbGRBKWD26kUUdpqv b4J8w8QWoeFNKuL91Ye5CW2jRvBgT+F0c8inCAdW4aOtW8pEZUVfJKsmwKLUgV9GXdeM hMuA== MIME-Version: 1.0 X-Received: by 10.50.212.3 with SMTP id ng3mr713534igc.43.1361531922420; Fri, 22 Feb 2013 03:18:42 -0800 (PST) Received: by 10.64.140.71 with HTTP; Fri, 22 Feb 2013 03:18:42 -0800 (PST) In-Reply-To: References: Date: Fri, 22 Feb 2013 11:18:42 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmzqO418ox7Kpc85LGxEd5uat7PFH62K6zit6NWMSJt6CJQ7lmTXqRp8xIdAAoCBw3KgpO59N4yrvIguR4ruSB65/o06cUNjvzMCzFW9W8vdgNtmWkaR4yTkwE2tkU2f+ahaU/u25VCljMkr2/MeHp8NsPjFcKyjM59pO1KjYIlWB/6vROlsYVfNhv4kGnU12Zh4k9N Cc: Emilia Kasper , "therightkey@ietf.org" , Adam Langley , IETF Discussion List , =JeffH Subject: Re: [therightkey] LC comments on draft-laurie-pki-sunlight-05 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:18:50 -0000 On 17 February 2013 00:24, Phillip Hallam-Baker wrote: > > > On Sat, Feb 16, 2013 at 1:55 PM, Ben Laurie wrote: >> >> On 16 February 2013 10:22, Phillip Hallam-Baker wrote: >> > Sorry for the delay but I have been thinking of CT and in particular the >> > issues of >> > >> > * Latency for the CA waiting for a notary server to respond >> > * Business models for notary servers >> > >> > As a rule open source software works really well as the marginal cost of >> > production is zero. Open source services tend to sux because even though >> > the >> > marginal cost of a service is negligible, large numbers times negligible >> > adds up to big numbers. Running a DNS server for a university department >> > costs very little, running it for the whole university starts to cost >> > real >> > money and running a registry like .com with 99.9999% reliability ends up >> > with $100 million hardware costs. >> > >> > So the idea that I plug my business into a network of notary servers >> > being >> > run by amateurs or as a community service is a non-starter for me. We >> > have >> > to align the responsibility for running any server that the CA has a >> > critical dependency on with a business model. >> >> Note that we do not expect CAs to talk to _all_ log servers, only >> those that are appropriately responsive - and also note that a CA can >> fire off a dozen log requests in parallel and then just use the first >> three that come back, which would deal with any temporary log issues. >> >> We should probably add this ability to the open source stack at some >> point. >> >> > Looking at the CT proposal, it seems to me that we could fix the >> > business >> > model issue and remove a lot of the CA operational issues as follows: >> > >> > 1) Each browser provider that is interested in enforcing a CT >> > requirement >> > stands up a meta-notary server. >> > >> > 2) Each CA runs their own notary server and this is the only resource >> > that >> > needs to have a check in at certificate issue. >> >> Isn't this part the only part that's actually needed? The >> meta-notaries seem like redundant extra complication (and also sound >> like they fulfil essentially the same role as monitors). >> >> I assume, btw, that by "notary server" you mean "log server"? >> >> Also, if a CA only uses its own log, what happens when it screws up >> and gets its log struck off the list of trusted logs? This is why we >> recommend some redundancy in log signatures. > > > That is the reason for checkpointing against meta notaries. > > Otherwise a CA might not actually release the logs. An unreleased log is not compliant - and so would not be accepted by browsers. From eabalea@gmail.com Fri Feb 22 05:48:39 2013 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C218E21F8EAF for ; Fri, 22 Feb 2013 05:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvRcetgVrxXm for ; Fri, 22 Feb 2013 05:48:39 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5921F8E17 for ; Fri, 22 Feb 2013 05:48:38 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so401506vbi.36 for ; Fri, 22 Feb 2013 05:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yxWXAWkj8JUevsH9FLRULH0IzK1jSk9LIsSwiPMDduA=; b=SloAgHA0h7hHQi0PVDVWj2LSBpGYgWbxlVu3k506jVWOQt+7rA/DBOxkHwFKEfZart pp97PqUYkezGQeMZJg+iIk0JZMfjoWBZL/e49oeYZ2JlR3qg3V3YoSAc/wRgBxqr5sfb 5myS/60RMPILkpl+tUEn7VrLyBDHP2fHqR/g5U+btQSsiCIaAs8FwwpAHJClvb6i3wv+ 5Gb6egE8QW4FuUkspAGcETWO7ypflF0gRJ3p7N7BsDsvTRBsIUVk6g79vQDNjZDekFA5 trBbXflWmUA5Qgr/13GvBHzxtqIYe3q+t6k7lRjX5GVRTpLQWpDYLbvCSPYD3+PztE1s bHyg== MIME-Version: 1.0 X-Received: by 10.52.28.82 with SMTP id z18mr2236868vdg.33.1361540909463; Fri, 22 Feb 2013 05:48:29 -0800 (PST) Received: by 10.52.156.49 with HTTP; Fri, 22 Feb 2013 05:48:29 -0800 (PST) In-Reply-To: <5122417F.8090500@cs.tcd.ie> References: <201302181453.r1IErhWQ036131@givry.fdupont.fr> <5122417F.8090500@cs.tcd.ie> Date: Fri, 22 Feb 2013 14:48:29 +0100 Message-ID: From: Erwann Abalea To: Stephen Farrell Content-Type: multipart/alternative; boundary=20cf3078108e41b40e04d65072bf Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Fwd: review of draft-laurie-pki-sunlight-07.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:48:39 -0000 --20cf3078108e41b40e04d65072bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maybe off-topic, but... 2013/2/18 Stephen Farrell > > From: Francis Dupont > > * the largest power of two must be strictly smaller, not just smaller. > Without this critical detail recursion rules don't work for n =3D 2^m > The reason of this mention is based on how mathematics are taught in different countries, and on biases in translations. Francis is french, and in France, "inf=C3=A9rieur =C3=A0" (which is a litte= ral translation of "smaller than") mathematically means "=E2=89=A4" (U+2265, "&= le;"). --=20 Erwann. --20cf3078108e41b40e04d65072bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maybe off-topic, but...

2013/2/18 Stephe= n Farrell <stephen.farrell@cs.tcd.ie>

From: Francis Dupont <Franc= is.Dupont@fdupont.fr>

=C2=A0 * the largest power of two must be strictly smaller, not just smalle= r.
=C2=A0 =C2=A0Without this critical detail recursion rules don't work fo= r n =3D 2^m

The reason of this mention = is based on how mathematics are taught in different countries, and on biase= s in translations.
Francis is french, and in France, "inf=C3=A9rieur =C3=A0" (w= hich is a litteral translation of "smaller than") mathematically = means "=E2=89=A4" (U+2265, "&le;").

<= /div>
--
Erwann.
--20cf3078108e41b40e04d65072bf--