Re: [apps-discuss] draft-farrell-decade-ni-02 - we think this is done...

[Stephen Farrell <[e-mail]>]

So I took a stab at addressing Carsten's and Martin's
good comments. Bit more to do but the significant changes
so far are:

- added a "url=" query string parameter to
   draft-hallambaker-decade-ni-params for Martin's use-case
- added an "nih" scheme to draft-farrell-decade-ni for the
   "human" scheme (nice acronym:-); that seems better than
   using the "ni" scheme with two different but sorta
   similar encodings (base32 and base64Url)

Previews at [1,2] (but might change when co-authors get a
chance to think about those changes).

More comments welcome,
TIA,
S.

[1] http://down.dsg.cs.tcd.ie/misc/draft-farrell-decade-ni.txt
[2] http://down.dsg.cs.tcd.ie/misc/draft-hallambaker-decade-ni-params.txt


On 04/06/2012 04:45 PM, Stephen Farrell wrote:
>
> Hiya,
>
> On 04/06/2012 01:08 PM, Carsten Bormann wrote:
>> On Apr 6, 2012, at 12:28, Stephen Farrell wrote:
>>
>>>> I believe for this to be the replacement of "unsecure links out of
>>>> HTTPS", the secure media type issue must be solved in the base spec.
>>>> (Oh, and is there ever a need to discuss content-coding in this
>>>> context???)
>>>
>>> Not sure what you mean by "solved" can you elaborate?
>>
>> The problem is that the ni: hash only secures the bytes of the payload.
>> (At least that's my assumption -- it might be worth saying explicitly
>> what is hashed here, BTW.)
>>
>> The entity I would have been retrieving over a secure HTTPS channel
>> also has metadata.
>> Many of these are not critical, as they only pertain to the retrieval
>> process (say, the Etag).
>> However, the media type is critical for correctly interpreting the
>> returned result.
>> While I'm not aware of the proverbial contract text that means
>> something different when interpreted as SJIS instead of UTF-8, attacks
>> on the basis of swapping the media type are conceivable. (Also, there
>> is lots of potential for misconfiguration, damaging the reliability.)
>>
>> I'm naming content-coding as another example that it is not quite
>> clear what is the input to the hash function.
>> So maybe it is worth having another (normative) document that spells
>> out how exactly ni:// is used in the Browser Web (among others, to
>> solve the "unsecure links" problem)?
>
> Ah now I see. Yes, I think other documents should define the
> hash input bytes, each in their own contexts.
>
> I'd be happy to help out with making a start on the web/ajax
> thing, but would need help from someone who knows more about
> the input bytes.
>
> Cheers,
> S.
>
>> Grüße, Carsten
>>
>>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>