Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt

[Julian Reschke <[e-mail]>]

On 2013-05-17 12:37, Julian Reschke wrote:
> On 2013-05-17 11:20, Stephen Farrell wrote:
>>
>> Nice. This looks pretty baked to me. Some nitty comments
>> below, nothing major at all.
>>
>> Cheers,
>> S.
>>
>> - What's the story on updating/obsoleting 2617? I don't much
>
> HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two
> additional specs defining Basic and Digest to get rid of RFC 2617
> completely.
>
> *This* draft just addresses the I18N issue of Basic. The reason why I
> don't want to do it in a new Basic spec is that this *really* is
> experimental. There's no point putting it into something that's
> replacing 2617 if we don't have any evidence that it works.
>
>> care but this'd be a good thing to work out before IETF LC as
>> otherwise we might end up doing multiple LC's to get it right.
>> Seems like httpbis-p7 doesn't obsolete 2617 and nor does this
>> and presumably nor would an updated digest. Somehow that seems
>> wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or
>> not but maybe that'd be worth checking out with someone who
>> cares. I can find someone who cares and ask if that's what
>> the wg want - the chairs can tell me if so, or that might be
>> better as a thing the httpbis wg think about, or perhaps its
>> all been thought about already.
>>
>> - An additional example or two would be good, maybe with
>> a username and password with asian characters or something.
>> If sticking with one Example, maybe change the title of
>> section 4:-)
>
> Ok.

Done.

>> - section 5: I wondered if there are any potential bad effects
>> if a UA sends an Authorization header like this to a server
>> that only supports ASCII. Is it worth adding a warning that
>> servers that assume that they get ASCII after base64 decoding
>> Authorization headers might get a surprise? Yes, it'd have
>> to be pretty crappy server code for that to cause a security
>> problem, but I guess it could happen.
>
> Clients already send non-ASCII; the issue here is making the encoding
> reliable.
>
>> - A.1: do we know that current UAs will actually ignore the
>> new parameter? I think I recall someone saying that is the
>> case, but I forget. Ah - you have it in B.3 - I think it'd
>> be better to merge those bits. The links from B.3 are great
>> btw, thanks for doing that work.
>
> I can do that.

Actually, that part is in B.3 because it's a section I assume will be 
removed in the final RFC.

>> - A.1.1: trying twice made me wonder if there's any way to
>> leverage that for some kind of side-channel/oracle attack.
>> Can't think of one but has someone thought about that?
>
> Feedback appreciated :-)
>
>> - A.2: "as well as before" - is that being disingenuous? If
>> so I think it'd be better not to do that since many people
>> reading this won't get it. I'd suggest replacing that with
>> "as well or as badly as before."
>
> Ack.

Done.

>> - B.2: "this scheme" - I think the "this" here refers to
>> Digest, but its ambiguous as written.
>
> Also, this WG actually is chartered to update Digest, so this needs work.

I rephrased this to say:

"The Digest scheme has similar issues with respect to 
internationalization. The HTTPAuth Working Group is chartered to address 
this problem as well, and the solution might be very similar."

>> - D.2: I don't understand this but then I never did and
>> probably never will, so you could add anything and that'd
>> work for me:-)
>
> Thanks for the feedback!
>
> Best regards, Julian

Best regards, Julian

PS: "done" meaning: in the HTTPauth SVN (see 
<http://tools.ietf.org/wg/httpauth/trac/browser/draft-ietf-httpauth-basicauth-enc/latest>)