Re: Stephen Farrell's No Objection on draft-ietf-httpbis-alt-svc-12: (with COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 04 March 2016 13:56 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290521A0120 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Mar 2016 05:56:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1NRmBFBmSH9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 4 Mar 2016 05:56:49 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783461A0115 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 4 Mar 2016 05:56:49 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1abq9N-00045f-Ax for ietf-http-wg-dist@listhub.w3.org; Fri, 04 Mar 2016 13:52:13 +0000
Resent-Date: Fri, 04 Mar 2016 13:52:13 +0000
Resent-Message-Id: <E1abq9N-00045f-Ax@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1abq9G-00044s-4B for ietf-http-wg@listhub.w3.org; Fri, 04 Mar 2016 13:52:06 +0000
Received: from mercury.scss.tcd.ie ([134.226.56.6]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <stephen.farrell@cs.tcd.ie>) id 1abq9D-0000Wd-Fz for ietf-http-wg@w3.org; Fri, 04 Mar 2016 13:52:05 +0000
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BDDEFBE55; Fri, 4 Mar 2016 13:51:34 +0000 (GMT)
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 XliTuBx_ToVt; Fri, 4 Mar 2016 13:51:34 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40DBBBE4D; Fri, 4 Mar 2016 13:51:34 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457099494; bh=r/yiZaZ8UcGF8PLp0LPIiQEhHh3uWUSAPntH1UT3GCQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=svIS/kVO2IAsOH7jSiP3Tt4W3X+3g3n1BsRuj/VLkoy2GMYrlk4cC4y7eSV6vD/Ju akPGoXd5v124Fw/Bh5ZE1YfzUDYo7Jq0DZreEvYpDsq6fpbZ+aAEFDAqOB9Xp9CBR2 whgDQ8+aHkPaQ15gTUKdY+QRZF9MP33xKYxySeaY=
To: Mark Nottingham <mnot@mnot.net>
References: <20160301122415.25221.56881.idtracker@ietfa.amsl.com> <FAC27A79-D409-4665-A9AA-BA362B99B425@mnot.net>
Cc: The IESG <iesg@ietf.org>, Mike Bishop <michael.bishop@microsoft.com>, HTTP WG <ietf-http-wg@w3.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <56D992E5.9070406@cs.tcd.ie>
Date: Fri, 04 Mar 2016 13:51:33 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <FAC27A79-D409-4665-A9AA-BA362B99B425@mnot.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050009090700050907040709"
Received-SPF: pass client-ip=134.226.56.6; envelope-from=stephen.farrell@cs.tcd.ie; helo=mercury.scss.tcd.ie
X-W3C-Hub-Spam-Status: No, score=-8.6
X-W3C-Hub-Spam-Report: AWL=1.749, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1abq9D-0000Wd-Fz 3f6120991306f7d4da7ed546ab3bdac7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Stephen Farrell's No Objection on draft-ietf-httpbis-alt-svc-12: (with COMMENT)
Archived-At: <http://www.w3.org/mid/56D992E5.9070406@cs.tcd.ie>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31177
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hiya, On 02/03/16 23:13, Mark Nottingham wrote: > Hi Stephen, > >> - If TLS1.3 continues to have 0rtt replayable early-data, could >> that interact badly with Alt-Svc? Or what about false-start? For >> example, if such a combination meant that an otherwise functional >> replay detection scheme would fail to spot a replay that would be >> bad. This is not a DISCUSS, as neither TLS1.3 nor false-start are >> formally "done" so blocking this for that reason would be "odd";-) >> However, both are implemented or will be, so I would love to chat >> about it and that might lead to some new security considerations >> text, here or in a TLS document. > > I don't think there's any interaction, because an Alt-Svc is "just > another HTTP connection" as far as replay goes; Hmm... seems to me that the probability of having an effective replay detection cache in place has to be lower with Alt-Svc. I'd be interested if that is wrong. That said, the probability of having an effective replay cache in place is probably quite small for any significantly sized site, so this isn't likely a major deal. Could still be worth noting though, as I'd say it'd be non-obvious for people deploying. I do accept that might be better noted as a security consideration in some other document. I'm not sure if the tls1.3 spec will be the best place for that or if there'll be a need for some guidance on using tls1.3 with HTTP, but if there were to be a document like that, noting it there would be good. > of course one still > needs to be mindful of not using it for things like POST. Right, I suspect if 0rtt stays in tls1.3 then someone will need to write down how to safely use that for the web, e.g. also noting that DELETE/PUT could also involve some ickiness if replayable. >> - Does this still all work for opportunistic security for HTTP? If >> not, why not? Note: I'm not asking if the WG have reached consensus >> on oppo, rather I'd like to be reassured that if they do, this will >> still work for that. I think that's all ok, though, right? > > It is still the basis, yes. Great, ta. > > >> - section 3: with "clear" you say alternatives are to be >> invalidated. Does that mean anything about cached resources? I >> assume not, but just checking. > > No, they're completely separate. Ditto. > >> - section 5: I wondered why you didn't include the ALPN identifier >> here? > > That didn't come up. Generally, it's because the alternative hostname > isn't available to the server (thanks to DNS), whereas the negotiated > protocol generally is. I say "generally" because the scope of the > ALPN identifier is somewhat fuzzy, and some have talked about using > it to indicate out-of-band information (e.g., whether certs are > checked). > > I'd be interested to hear what WG members think about this -- do we > need to include this? Arguably, it would be more useful than knowing > what the port is (information that the server *does* have). > I'd also be interested if folks think this useful. >> - 9.2: What does "might also choose" mean and which "other >> requirements" have you in mind? That's very vague. > > Browsers can -- and do -- add other checks to certificates, and this > gives them wiggle-room to do so. This might be CT as it's not > required now, it might be a browser-specific blacklist based upon its > own data, it might be additional limits on validity periods, it might > be Perspectives or a similar approach, etc. > I have to say I'm still not clear on what could usefully be done there - are you envisaging e.g. paying attention to whether the new host name is in a SAN in the cert or matches a wildcard cert or something? I also don't see how CT would interact with Alt-Svc at all, but maybe there's something. >> - 9.5: What are you telling me with the last para? > > This? > > """ When the protocol does not explicitly carry the scheme (as is > usually the case for HTTP/1.1 over TLS), servers can mitigate this > risk by either assuming that all requests have an insecure context, > or by refraining from advertising alternative services for insecure > schemes (for example, HTTP). """ > Yep, I still don't get what it's saying. Maybe I just find "assuming that all requests have an insecure context" hard to grok. Cheers, S. PS: Just to note again, none of the above ought be considered blocking - if you/the-WG think I'm wittering on about nonsense, then please do just ignore me:-) > > > > -- Mark Nottingham https://www.mnot.net/ >
- Stephen Farrell's No Objection on draft-ietf-http… Stephen Farrell
- Re: Stephen Farrell's No Objection on draft-ietf-… Mark Nottingham
- Re: Stephen Farrell's No Objection on draft-ietf-… Stephen Farrell
- Re: Stephen Farrell's No Objection on draft-ietf-… Patrick McManus
- Re: Stephen Farrell's No Objection on draft-ietf-… Erik Nygren
- Re: Stephen Farrell's No Objection on draft-ietf-… Mark Nottingham
- Re: Stephen Farrell's No Objection on draft-ietf-… Martin Thomson