Subject: Security Properties, was: Rechartering HTTPbis

From: Julian Reschke <[email-masked]>
Date: Thu, 02 Feb 2012 14:34:24 +0100

On 2012-01-24 04:55, Mark Nottingham wrote:
> ...
>    Feb 2012    Working Group Last Call for HTTP Security Properties
> ...

Out of curiosity: this document hasn't changes since March 2010. Do we 
plan to do any additional work on it?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Feb 2012 11:58:59 +1100

On 03/02/2012, at 12:34 AM, Julian Reschke wrote:

> Out of curiosity: this document hasn't changes since March 2010. Do we plan to do any additional work on it?

That's a good question. Originally, this document was put into our charter to address the need for Mandatory-to-Implement security in HTTP; since we couldn't make it a hard requirement, it was thought that educating users / implementers / administrators was the next best thing.

In the meantime, it's been difficult to get forward momentum on the document (perhaps because it is so broad, and because for it to be useful, it needs to be detailed; however, if it's detailed, it will likely become stale quickly, IMO). 

We should discuss this as part of re-chartering; if HTTP/2.0 has MTI security, it could change things.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 05:01:56 +0100

lör 2012-01-28 klockan 09:13 +0100 skrev Julian Reschke:

> > I would apply a lossy conversion (reverse-mapping between UTF-8 and 8859-1).
> > So whatever fits 8859-1 would correctly be mapped, and the rest would be lost
> > or quoted. I don't think it's that big an issue if this is a well-known
> 
> There is no quoting we can use, unless we define a new one...

Or we just accept that HTTP/1.1 implementations do not follow HTTP/1.1
encoding specifications anyway for non-ascii data and simply say that
when I18N  field values need to be gatewayed to HTTP/1.1 then send them
as UTF-8 even if HTTP/1.1 specifications says otherwise, intentionally
overriding HTTP/1.1 specifications.

Sure it will break some to fix some (and mainly authentication), but
it's not really such a big deal. In the end it's about the same amount
of breakage as today, only different and more consistent.

But it's a bad idea to open for I18N in field names.

Regards
Henrik

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 6 Feb 2012 07:28:08 +0100

> of breakage as today, only different and more consistent.

+1

> But it's a bad idea to open for I18N in field names.

+1. For me i18n should only appear in values. Otherwise we'll be dealing
with a big new can of worms caused by UTF-8 to anything conversion (eg:
multiple ways to write "Content-Length" because you can have a number of
UTF-8 hyphens which translate into "-").

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Feb 2012 08:51:20 +0100

> of breakage as today, only different and more consistent.

It will break some uses of Content-Disposition. It will not fix 
authentication.

> But it's a bad idea to open for I18N in field names.

Sure. Did anybody propose that?

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 09:42:57 +0100

> It will break some uses of Content-Disposition. It will not fix 

Sorry bad wording from my part. I meant that it breaks some and fix
some, mainly affecting authentication. But yes, the same reasoning also
applies to Content-Disposition. But I do not think that I have seen
non-ascii characters ever work well in Content-Disposition..

> Sure. Did anybody propose that?

I do not think so. Only mentioned it in case someone had doubts.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Feb 2012 10:07:44 +0100

> some, mainly affecting authentication. But yes, the same reasoning also

It doesn't affect Basic auth at all, because Basic uses plain-ASCII (so 
the encoding happens on a different layer).

> non-ascii characters ever work well in Content-Disposition..

Check the issue trackers for Firefox and Chrome, or browse StackOverflow :-)

> I do not think so. Only mentioned it in case someone had doubts.

ok!

---

From: Henrik Nordström <[email-masked]>
Date: Mon, 06 Feb 2012 19:02:51 +0100

> the encoding happens on a different layer).

True. But it does affect Digest auth, and can't be recoded there without
breaking the digest. Plus that browsers vary greatly in what encoding
they use within basic auth before base64-encoding so in a sense it does
affect basic auth as well.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 06 Feb 2012 19:28:57 +0100

> affect basic auth as well.

I agree that Basic auth has a problem, but it's not going to be fixed by 
changing the encoding default for field values.

See 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 07 Feb 2012 14:28:49 +1300

> affect basic auth as well.

I thought that pre-base64 representation was what this draft was about.
To label the "user:pass" string as being in UTF-8 before base-64 
encoding was applied converting it to ASCII for the HTTP transfer.

So that the decoder at the other end know what the base64-decoded 
octets arriving were.

AYJ