Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 29 Aug 2011 18:33:54 +0300

Proposal for a new hint:

> 5.8.  https
>
>     o  Browser Hint Name: https
>     o  Description: When true, this hint indicates the user agent may
>        use HTTPS and, correspondigly, 'https' URI scheme [RFC2818] with
>        the specific areas (resources) of the site.
>     o  Value Type: prefixlist
>     o  Contact: /somebody/

Mykyta Yevstifeyev

31.05.2011 9:28, Mark Nottingham wrote:
> FYI. Diffs at:
>    http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02
>
> Changelog:
>    - removed Ref header and rearranged referer-based hints
>    - added 'prefixlist' value type
>    - changed omit-cookies from list of cookie names to prefixlist
>    - added caching advice for 404s
>
> Feedback appreciated, as always.
>
>
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: 31 May 2011 4:22:29 PM AEST
>> To: [email-masked]
>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : HTTP Browser Hints
>> 	Author(s)       : Mark Nottingham
>> 	Filename        : draft-nottingham-http-browser-hints-02.txt
>> 	Pages           : 9
>> 	Date            : 2011-05-30
>>
>>    Over time, Web browsers have adapted how they use HTTP based upon
>>    common server configurations and behaviours.  While this is necessary
>>    in the common case, it can be detrimental for performance and
>>    interoperability.
>>
>>    This document establishes a mechanism whereby origin servers can make
>>    available hints for browsers about their preferences and
>>    capabilities, without imposing overhead on their interactions or
>>    requiring support for them.
>>
>>    This is intended to allow browsers to safely optimise connections to
>>    servers.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Aug 2011 11:03:42 +1000

I didn't go in this direction because it *seems* to conflict with the STS effort in websec. Maybe someone from over there could comment?

Cheers,

s

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 31 Aug 2011 17:39:55 +0300

> I didn't go in this direction because it *seems* to conflict with the STS effort in websec. Maybe someone from over there could comment?

I understand that HSTS is only useful when site declares that HTTPS must 
be used any time when connecting to it.  Specific areas/resources may 
not be declared to be so (If I'm wrong, correct me).

Anyway, an alternative is never a bad thing.

Mykyta Yevstifeyev

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Aug 2011 08:40:59 -0600

On 8/31/11 8:39 AM, Mykyta Yevstifeyev wrote:
>> I didn't go in this direction because it *seems* to conflict with the
>> STS effort in websec. Maybe someone from over there could comment?
> 

What is the use case for that feature?

> Anyway, an alternative is never a bad thing.

Too many ways to do the same thing can be confusing.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 31 Aug 2011 17:48:05 +0300

> What is the use case for that feature?

This provides a way for client which prefers to use secure variant to 
learn which areas of the site are fine to be accessed so, without 
attempting to use HTTPS where it isn't possible.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 31 Aug 2011 10:53:09 -0400

> This provides a way for client which prefers to use secure variant to learn
> which areas of the site are fine to be accessed so, without attempting to
> use HTTPS where it isn't possible.

Let me see if I understand this correctly:

A client that wants to use HTTPS, but isn't sure whether this part of
the site supports it, can do it one of two ways:

1. Try HTTPS.  If it doesn't work, fall back to HTTP.

2. Use HTTP.  If a "hint" is included in the HTTP response that says
HTTPS is OK, then switch to HTTP.

You're proposing 2.  Is that right?

Assuming that's right, I'm saying that 1 is better.

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 31 Aug 2011 19:19:46 +0300

> Assuming that's right, I'm saying that 1 is better.

You're right.  But: a client needs to do 1 for each time it tries to 
access something whereas 2 would only be required once.  2 is more 
practical; are there any other considerations which led you to the 
conclusion that 1 is better?

Mykyta

---

From: Barry Leiba <[email-masked]>
Date: Wed, 31 Aug 2011 12:29:03 -0400

> You're right.  But: a client needs to do 1 for each time it tries to access
> something whereas 2 would only be required once.  2 is more practical; are
> there any other considerations which led you to the conclusion that 1 is
> better?

2 is not more practical.  Very few (probably no) web sites will have
HTTPS enabled or disabled item by item.  In reality, clients will try
HTTPS, it will work, and it will continue to work for most or all of
what they're doing at that site.  When it fails, they'll fall back to
HTTP and continue using it for the section of the site for which HTTPS
failed.

On the other hand, method 2 requires that they try to figure out when
they can safely use the hint they were given before.  When, exactly,
is it that they cross over into another part of the site, which might
not support HTTPS?  If they get it wrong, they wind up with method 1
anyway.

Apart from that, method 1 ensures that if they can use HTTPS, the
entire client session (that is, all interactions between the client
and the site in question) is protected by TLS.  With method 2, the
initial communication is in the open, unprotected, and the client has
to switch to protection after getting the hint.  That creates a window
for snooping.  Also, a MitM attacker can remove the HTTPS hints,
preventing the client from ever even trying SSL.

This looks like a bad solution in search of a problem.

Barry