subject:"\[websec\] Digest URI scheme"

On Mon, Oct 3, 2011 at 9:07 PM, "Martin J. Dürst"
 wrote:
> On 2011/10/03 23:13, Phillip Hallam-Baker wrote:

>> I suggest that we use Base 64 Encoding with URL and Filename Safe
>> Alphabet:
>>
>> http://tools.ietf.org/html/rfc4648#page-7
>
> Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a
> better pointer.

The other name for this scheme is 'filesafe'.

While it is not particularly relevant to our current use cases, the
ability to convert the stem portion of the URI into a filename
directly is going to be very useful for DECADE and for many other
purposes.

>> This would mean using the characters - and _ for char codes 63 and 64
>> and dropping the padding completely.
>
> Yes. I wish RFC 4648 would say this upfront, and move the reasons why other
> characters such as '.' and '~' were not chosen later. And the character
> numbers, in RFC 4648 terminology, are the 62:nd and 63:rd character.

Yes, that is right.

>> I am strongly tending towards:
>>
>> "digest:" algorithm ':' base64(content) ['?' tag '=' value [ '&' tag
>> '=' value]* ]
>>
>> Where:
>>
>> algorithm - is from the IANA registry discussed earlier
>> base64 - is the RFC 4648 file and url safe version
>> content is the referenced content
>> tag is taken from the URL encoding precedent
>> value is taken from the URL encoding precedent
>>
>>
>> If people need a locator then it would be formed from a tag/value pair
>> as follows:
>>
>> tag = "http"
>> value = domain name
>
> Can you explain why we need a domain name as a locator? Wouldn't

We don't need it, but the DECADE folk need to have it in somewhere.
There are two basic options:

1) Use the authority slot. This results in a URL with the form ni:///alg/digest

2) Use a parameter on the query slot.

The advantage of 1 is mostly familiarity. The disadvantage is that it
suggests that the 'authority' controlling the interpretation of the
name is the domain and the whole point of the digest schemes is that
the place you get the bits from becomes irrelevant.

The advantage of 2 is that there can be multiple locators.

I think we need comments from the DECADE folk on that to know what to do.

> tag = "uri"
> value = URI
>
> be much more general?

Actually this is actually a very useful case that is worth calling out
separately.

Again this is something that I had thought about but not put in the
draft because I did not want to add in functionality that went too far
beyond what DECADE and WEBSEC might require.

Larry Masinter suggested a URI scheme that was something like this but
focused on just that use case.

This creates a URI whose semantics are roughly speaking 'content
retrieved from the URI=foo. It would be best paired with a date
parameter. This does not remove the need for the locator however.

For example, let us say that you want to create a link to the text of
rfc 822 which you have retrieved on a particular date and pickled
somewhere. The digest URI might look something like:

di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?

http=di.example.com&uri=http://www.ietf.org/rfc/rfc822.txt&date=2011-10-3:21:00

This being a strong reference to the content that was downloaded from
the uri specified on the date specified and a hint that it can be
found in the specified content registry(s)

>> The corresponding url would be formed as:
>>
>> "http://"; + domain-name + "/.well-known/digest/" + algorithm + "/" +
>> base64(content)
>>
>> This can then be transformed inside the Web Server as is necessary to
>> support the constraints of the local file system.
>
> Sorry, but I'm much more an URI expert than a security expert. Can you
> explain what all that is about? What would be at that location? Why all this
> hard-coded stuff?

The alternative would be to bloat the identifier used as the reference
in documents and protocols with a second set of information to allow
it to be retrieved from the specified repositories.

>
>> Other protocol tags can be specified to support alternative protocols.
>
> So it would be possible to use all the URI scheme names as tag names? Like
> tag = "https"
> tag = "ftp"

No, not unless there was an explicit mapping defined for that protocol.

Now clearly, if an 'ftp' parameter tag was defined it should only be
for something involving ftp as the transport. But there would have to
be a document to specify the protocol mapping.

>> For certain applications the full 256 bits of the content URL are
>> unnecessary.
>
> Which 256 bits exactly?

Sorry the content digest.

>> The collision resistant digest identifier for the content is then formed
>> as:
>>
>> digest + E ( digest, key )
>>
>> "Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q",
>> "491X0pTnLkJHFN_AVctJUA")
>>
>> The result is an identifier of 256 bits that has 128 bits worth of
>> authentication security, 128 bits worth of confidentiality security
>> and 128 bits worth of birthday attack collision resistance.
>>
>>
>> For the current WebSec use cases, only the dig

Re: [websec] Digest URI scheme

On 2011/10/03 22:30, Phillip Hallam-Baker wrote:

On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. Dürst"
wrote:

On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip
Hallam-Baker:

One of the things I was thinking about was that for our case the
essence of the digest is really the digest part. The domain is really
just a location hint. Why stick at just one domain? If the same
content is present at foo.com and bar.com why not have an identifier
that can specify both:

dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=foo.com&loc=bar.com&ct=text/plain

The example here is a bit more explicit (and doesn't use 'http' as a tag
name), so I'm asking again:

Why isn't this something like:

dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=http://foo.com/path/to/content.ext&loc=http://bar.com/path/to/content.ext&ct=text/plain

(the slashes here should be %-encoded, but I left them as is for easy
readability)

Now I know that we do not need this for our particular application,
but if we are going to come up with a common scheme with DECADE we
have to meet their use cases as well as out own.

I have some other ideas that would be interesting in the DECADE
context. Right back in 1995 Rohit Khare and myself were fooling about
with identifiers that had decryption keys built in.

For their particular application, the ability to send a single
identifier that allows the content to be uniquely identified,
authenticated and located would be quite interesting I think.

Adding a symmetric decryption key means that the set of people who can
read the plaintext is precisely the set of people with access to the
plaintext plus the people who can access the identifier. The host on
which confidential content resides is thus moved outside the zone
where security concerns apply.

I think I get the idea, but wouldn't that be quite similar to URIs
including passwords? That has been widely frowned upon since quite some
time, to the extent that it has been kicked out from the generic URI
syntax (although it can be quite convenient on occasion).

I note that you have a content type, which I have but someone here was
objecting to. I consider the content type to be essential meta-data
for obvious security reasons.

Our use-case for that is for cases where the named object actually
arrives in some wrapped form (e.g. encrypted) and you need to know
the "inner" content type. However, I could see it being used otherwise
or being dropped as things progress.

Just curious: Why would you need to know the inner content type? Wouldn't
the wrapper contain that information?

Probably so that they can perform negotiation.

If the consumer is a video player, it wants to be able to select
content that it knows how to play. In most cases the player will be
grabbing the bits and negotiating the decryption capability in
parallel.

Ok. I was assuming that the 'outer' content is what's hashed, but it
looks like the outer wrapping (compression or so) is only used on
transport, and it's the 'inner' content that's hashed. Then that makes
sense (using a digest of the outer content but having the content type
apply to the inner content would be quite weird in my opinion).

In my case the concern is that it should be possible to use the
generalized form of this identifier as a secure URL for referencing
static content from a secure Web page.

So imagine that we have anybank.com that has its main pages on HTTPS
but has the images etc. on a separate server that really does not need
SSL for any purpose other than authenticating the source.

It would be a trivial matter to write a script that could transform
such Web pages into Web pages with 'hardened' URLs of the digest form
being discussed here. This would in turn provide a long term answer to
the problem of efficiently supporting the strict security concerns we
discuss here without the overhead of SSL everywhere.

So e.g. the Anybank logo is not a secret, so it can go over HTTP in the
open, and we don't care about where it comes from (even from a bad guy)
as long as it's the same logo, which we can check with the digest.

The only problem with that being that the content-type is actually a
security sensitive piece of meta-data and manipulation of
content-types is a major attack vector (probably the fastest growing
at the mo).

So, just as a totally hypothetical example, the attacker sends exactly
the same bits, but claims they are image/png instead of image/jpg, and
the user sees something different (e.g. an 'okay' button instead of a
'cancel' button).

For these cases of faking metadata, wouldn't it be better to have some
general way of making the metadata part of the content that is hashed?

Regards,Martin.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme


On 2011/10/03 23:13, Phillip Hallam-Baker wrote:

On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke  wrote:



Also keep in mind that if you use "/" for a different purpose than
hierarchy, surprising things will happen when relative references are
resolved. It's good to avoid them in this case.


That is probably the killer argument here.


It's not a killer argument, because these URIs aren't going to be used 
in a relative form (except potentially leaving out the scheme, which is 
irrelevant), and aren't going to be used as base URIs (same irrelevant 
exception again). Paul is actually right on that one.


But it's okay to stay on the safe side, and to comply with a SHOULD in 
RFC 3986.


However, there's no reason for shouting about this on either side, or 
for coming up with MUSTs where there are none (only SHOULDs).




I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet:

http://tools.ietf.org/html/rfc4648#page-7


Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a 
better pointer.




This would mean using the characters - and _ for char codes 63 and 64
and dropping the padding completely.


Yes. I wish RFC 4648 would say this upfront, and move the reasons why 
other characters such as '.' and '~' were not chosen later. And the 
character numbers, in RFC 4648 terminology, are the 62:nd and 63:rd 
character.




I am strongly tending towards:

"digest:" algorithm ':' base64(content) ['?' tag '=' value [ '&' tag
'=' value]* ]

Where:

algorithm - is from the IANA registry discussed earlier
base64 - is the RFC 4648 file and url safe version
content is the referenced content
tag is taken from the URL encoding precedent
value is taken from the URL encoding precedent


If people need a locator then it would be formed from a tag/value pair
as follows:

tag = "http"
value = domain name


Can you explain why we need a domain name as a locator? Wouldn't

tag = "uri"
value = URI

be much more general?


The corresponding url would be formed as:

"http://"; + domain-name + "/.well-known/digest/" + algorithm + "/" +
base64(content)

This can then be transformed inside the Web Server as is necessary to
support the constraints of the local file system.


Sorry, but I'm much more an URI expert than a security expert. Can you 
explain what all that is about? What would be at that location? Why all 
this hard-coded stuff?




Other protocol tags can be specified to support alternative protocols.


So it would be possible to use all the URI scheme names as tag names? Like
tag = "https"
tag = "ftp"
...

Then we'd get collisions between URI schemes and other tag uses.


Stephen's DECADE application then becomes a special case of the
general form of the identifier. It is essentially a different lookup
protocol.


Some additional tweakage:

For certain applications the full 256 bits of the content URL are unnecessary.


Which 256 bits exactly?


If an encryption key is in use then the encryption key can be used to
form part of the identifier for the purpose of distinguishing
identifiers.

For example:

let the plaintext be p and the encryption key be k.

The identifier might be

digest:sha-2-128:Ry_yKcfFmWj4cs9ucvm10Q?enc=aes&key=491X0pTnLkJHFN_AVctJUA

Where sha-2-128 is SHA256 truncated to 128 bits as per NIST instructions.


The collision resistant digest identifier for the content is then formed as:

digest + E ( digest, key )

"Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q",
"491X0pTnLkJHFN_AVctJUA")

The result is an identifier of 256 bits that has 128 bits worth of
authentication security, 128 bits worth of confidentiality security
and 128 bits worth of birthday attack collision resistance.


For the current WebSec use cases, only the digest is actually
required. I am not entirely convinced, but I suspect that for our use
cases the truncated identifier would be sufficient since we rely only
on the 2nd preimage resistance property.


If that kind of security magic works, then it's great if we can express 
it in the URI.



Regards,Martin.

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

On Mon, Oct 3, 2011 at 7:49 PM, Bjoern Hoehrmann  wrote:
> * Phillip Hallam-Baker wrote:
>>I have implemented Base64 from scratch many times. It takes about 30
>>lines. If that is too hard it is easy enough to swap the characters
>>over.
>>
>>Base 256 would use a whole rack of characters that are illegal in URIs.
>>
>>Isn't the alleged point of free software that it is easy to add in features?
>
> You started this thread saying "it would be better if we had a single
> format". How about you abandon this idea, you call your scheme "d64:"
> to keep things concise, and the rest of us develop our own format?

Implicit in the idea of a single format is the notion that at least
some people will write code for it.

Compatibility with unix command line tools would rank really low in my
list of priorities if at all. They are easily written and easily added
to. That is the whole point of them.

I was planning to write a command line tool for supporting the format
anyway. There seems to be no man page entry for di.

How about something like:

di [-d ] [-e ] [-http domain]* input output

If someone wants to compare with a dumb string comparison they need do
the necessary case conversions and chop off the parameters part since
that is not canonical.

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

* Phillip Hallam-Baker wrote:
>I have implemented Base64 from scratch many times. It takes about 30
>lines. If that is too hard it is easy enough to swap the characters
>over.
>
>Base 256 would use a whole rack of characters that are illegal in URIs.
>
>Isn't the alleged point of free software that it is easy to add in features?

You started this thread saying "it would be better if we had a single
format". How about you abandon this idea, you call your scheme "d64:"
to keep things concise, and the rest of us develop our own format?
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

I have implemented Base64 from scratch many times. It takes about 30
lines. If that is too hard it is easy enough to swap the characters
over.

Base 256 would use a whole rack of characters that are illegal in URIs.


Isn't the alleged point of free software that it is easy to add in features?


On Mon, Oct 3, 2011 at 7:17 PM, Bjoern Hoehrmann  wrote:
> * Phillip Hallam-Baker wrote:
>>That adds significantly to the size of the identifiers.
>>
>>For my application the amount of space that is available to transport
>>the identifiers will be constrained. Thus if X bytes permits 100 sites
>>to be secured using a base64 encoding, use of base16 will drop that to
>>60 or so.
>
> So? Maybe for my application I want people to easily compare the URI
> with the output from GNU sha256sum which does not have an option for
> your particular Base 64 dialect, and maybe you should use Base 256
> without a "digest:" prefix if size is so important?
> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>



-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

* Phillip Hallam-Baker wrote:
>That adds significantly to the size of the identifiers.
>
>For my application the amount of space that is available to transport
>the identifiers will be constrained. Thus if X bytes permits 100 sites
>to be secured using a base64 encoding, use of base16 will drop that to
>60 or so.

So? Maybe for my application I want people to easily compare the URI
with the output from GNU sha256sum which does not have an option for
your particular Base 64 dialect, and maybe you should use Base 256
without a "digest:" prefix if size is so important?
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

* Phillip Hallam-Baker wrote:
>I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet:

How about Base 16 instead? Like we use it for checksums everywhere else?
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

That adds significantly to the size of the identifiers.

For my application the amount of space that is available to transport
the identifiers will be constrained. Thus if X bytes permits 100 sites
to be secured using a base64 encoding, use of base16 will drop that to
60 or so.

There is already an IETF specification and precedent that covers this issue.

On Mon, Oct 3, 2011 at 1:42 PM, Bjoern Hoehrmann  wrote:
> * Phillip Hallam-Baker wrote:
>>I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet:
>
> How about Base 16 instead? Like we use it for checksums everywhere else?
> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

* Paul Hoffman wrote:
>I don't see how the digest URL you propose has either "relative
>references" nor "resolved". More detail in your next draft would be
>valuable.

Resolving a relative reference with respect to a base reference is some-
thing you can do regardless of the scheme. Scheme definitions don't need
to discuss relative references at all, there are always relative forms,
and anything that can be said about them is already defined in RFC 3986.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

>From RFC 4395:

2.2.  Syntactic Compatibility

   RFC 3986 [5] defines the generic syntax for all URI schemes, along
   with the syntax of common URI components that are used by many URI
   schemes to define hierarchical identifiers.  All URI scheme
   specifications MUST define their own syntax such that all strings
   matching their scheme-specific syntax will also match the
grammar described in Section 4.3 of RFC 3986.

   New URI schemes SHOULD reuse the common URI components of RFC 3986
   for the definition of hierarchical naming schemes.  However, if there
   is a strong reason for a URI scheme not to use the hierarchical
   syntax, then the new scheme definition SHOULD follow the syntax of
   previously registered schemes.

   URI schemes that are not intended for use with relative URIs SHOULD
   avoid use of the forward slash "/" character, which is used for
   hierarchical delimiters, and the complete path segments "." and ".."
   (dot-segments).

Question closed in my view.

I don't see any point in responding to further comments that simply
repeat the original statement. There is a clear requirement that URI
schemes are required to meet stated in the URI standards documents.

The rules were developed from long experience and are designed to
encourage interoperability. I don't see any reason to second guess
that reasoning on the basis of the vague and unsubstantiated concerns
you have raised.

On Mon, Oct 3, 2011 at 1:23 PM, Paul Hoffman  wrote:
> On Oct 3, 2011, at 10:12 AM, Phillip Hallam-Baker wrote:
>
>> On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman  wrote:
>>> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote:
>>>
 URLs are used in cases where hierarchy is assumed.
>>>
>>> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll 
>>> put them in your next proposal.
>>
>> As Julian correctly pointed out, a generic URI will be used in
>> situations where the application will (correctly) assume that anything
>> in URI syntax that has a slash character in it will be hierarchical.
>
> Did Julian say that? The one thing that I saw him say was "Also keep in mind 
> that if you use "/" for a different purpose than hierarchy, surprising things 
> will happen when relative references are resolved. It's good to avoid them in 
> this case."
>
> I don't see how the digest URL you propose has either "relative references" 
> nor "resolved". More detail in your next draft would be valuable.
>
> --Paul Hoffman
>
>

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-10-03 Thread Paul Hoffman

On Oct 3, 2011, at 10:12 AM, Phillip Hallam-Baker wrote:

> On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman  wrote:
>> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote:
>> 
>>> URLs are used in cases where hierarchy is assumed.
>> 
>> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll 
>> put them in your next proposal.
> 
> As Julian correctly pointed out, a generic URI will be used in
> situations where the application will (correctly) assume that anything
> in URI syntax that has a slash character in it will be hierarchical.

Did Julian say that? The one thing that I saw him say was "Also keep in mind 
that if you use "/" for a different purpose than hierarchy, surprising things 
will happen when relative references are resolved. It's good to avoid them in 
this case."

I don't see how the digest URL you propose has either "relative references" nor 
"resolved". More detail in your next draft would be valuable.

--Paul Hoffman

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman  wrote:
> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote:
>
>> URLs are used in cases where hierarchy is assumed.
>
> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put 
> them in your next proposal.

As Julian correctly pointed out, a generic URI will be used in
situations where the application will (correctly) assume that anything
in URI syntax that has a slash character in it will be hierarchical.

Thus a URI scheme that does not intend to indicate hierarchy MUST NOT
include a slash character in that part of the identifier.

Plus it is essential to ensure that anything that is to fit in a URI
slot is compatible with code for making entries URI-safe. A URI that
contains a + character is likely to end up being mangled.

This issue has already been litigated in the IETF and the result of
that consensus was RFC 4648. I see no reason to re-open that
discussion in case someone does not bother to test their code.

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-10-03 Thread Paul Hoffman

On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote:

> URLs are used in cases where hierarchy is assumed.

I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put 
them in your next proposal.

--Paul Hoffman

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

On Mon, Oct 3, 2011 at 11:00 AM, Paul Hoffman  wrote:
>
> On Oct 3, 2011, at 1:46 AM, Julian Reschke wrote:
>
>> On 2011-10-03 09:29, "Martin J. Dürst" wrote:
>>> On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip
>>> Hallam-Baker:
>>>

>>
>> Also keep in mind that if you use "/" for a different purpose than 
>> hierarchy, surprising things will happen when relative references are 
>> resolved. It's good to avoid them in this case.
>
>
> That's silly for this case. The proposed URL scheme has no hierarchy scheme, 
> nor is it even resolvable because there is no host. I know Phill has already 
> responded that he intends to use an encoding that changes Base64 for the 
> reason you give; I believe that will lead to likely lack of interop due to 
> complexity.

Complexity, shmexity. We have a case where Julian has pointed out that
failing to properly address these cases will lead to interop failures.
I don't see how using the URI-safe encoding in a URI is more complex
than using the one we already know to be broken.

URLs are used in cases where hierarchy is assumed. Thus there is code
to attempt to apply relative naming to identifiers that are put in URI
slots. Julian is completely right on this.

This is a known issue and the IETF already has a standards based fix for it.

There is a fine line between simple and simplistic. Using the +/
encoding would be simplistic and definitely not simple.

Interop issues due to incompetent programmers not reading the spec
will on average be detected in (64/2) / ((4/3)*(256/8))  trials, that
is 0.75. We can even choose test vectors that ensure that these issues
are exposed.

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-10-03 Thread Paul Hoffman


On Oct 3, 2011, at 1:46 AM, Julian Reschke wrote:

> On 2011-10-03 09:29, "Martin J. Dürst" wrote:
>> On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip
>> Hallam-Baker:
>> 
 Only real issue for me is that it has to fit in URI type slots. The
 scheme I was thinking of would be a pure URN scheme, your proposal
 includes URL like things.
>> 
>> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at
>> all; in RFC 3986, I think slashes would even be allowed if they don't
>> appear directly after the first ':'), then you can define an URI scheme
>> without including host-like stuff and you don't have to use "urn:" as a
>> prefix.
>> 
>>> Yep. We have use-cases for that. Note though that the authority
>>> part is optional, so a fairly bare digest is quite possible and
>>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj...
>> 
>> The triple slash at the beginning is a bad idea. There should only be
>> slashes if the scheme conforms to the generic syntax (i.e. a double
>> slash, something like a host name, and then slashes for something
>> pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better.
> > ...
> 
> Also keep in mind that if you use "/" for a different purpose than hierarchy, 
> surprising things will happen when relative references are resolved. It's 
> good to avoid them in this case.


That's silly for this case. The proposed URL scheme has no hierarchy scheme, 
nor is it even resolvable because there is no host. I know Phill has already 
responded that he intends to use an encoding that changes Base64 for the reason 
you give; I believe that will lead to likely lack of interop due to complexity.

--Paul Hoffman

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke  wrote:
> On 2011-10-03 09:29, "Martin J. Dürst" wrote:
>>
>> On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip
>> Hallam-Baker:
>>
 Only real issue for me is that it has to fit in URI type slots. The
 scheme I was thinking of would be a pure URN scheme, your proposal
 includes URL like things.
>>
>> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at
>> all; in RFC 3986, I think slashes would even be allowed if they don't
>> appear directly after the first ':'), then you can define an URI scheme
>> without including host-like stuff and you don't have to use "urn:" as a
>> prefix.
>>
>>> Yep. We have use-cases for that. Note though that the authority
>>> part is optional, so a fairly bare digest is quite possible and
>>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj...
>>
>> The triple slash at the beginning is a bad idea. There should only be
>> slashes if the scheme conforms to the generic syntax (i.e. a double
>> slash, something like a host name, and then slashes for something
>> pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better.
>
>> ...
>
> Also keep in mind that if you use "/" for a different purpose than
> hierarchy, surprising things will happen when relative references are
> resolved. It's good to avoid them in this case.

That is probably the killer argument here.

I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet:

http://tools.ietf.org/html/rfc4648#page-7

This would mean using the characters - and _ for char codes 63 and 64
and dropping the padding completely.

There is a great summary table here that folk can choose from
http://en.wikipedia.org/wiki/Base64

I am strongly tending towards:

"digest:" algorithm ':' base64(content) ['?' tag '=' value [ '&' tag
'=' value]* ]

Where:

algorithm - is from the IANA registry discussed earlier
base64 - is the RFC 4648 file and url safe version
content is the referenced content
tag is taken from the URL encoding precedent
value is taken from the URL encoding precedent

If people need a locator then it would be formed from a tag/value pair
as follows:

tag = "http"
value = domain name

The corresponding url would be formed as:

"http://"; + domain-name + "/.well-known/digest/" + algorithm + "/" +
base64(content)

This can then be transformed inside the Web Server as is necessary to
support the constraints of the local file system.

Other protocol tags can be specified to support alternative protocols.

Stephen's DECADE application then becomes a special case of the
general form of the identifier. It is essentially a different lookup
protocol.

Some additional tweakage:

For certain applications the full 256 bits of the content URL are unnecessary.

If an encryption key is in use then the encryption key can be used to
form part of the identifier for the purpose of distinguishing
identifiers.

For example:

let the plaintext be p and the encryption key be k.

The identifier might be

digest:sha-2-128:Ry_yKcfFmWj4cs9ucvm10Q?enc=aes&key=491X0pTnLkJHFN_AVctJUA

Where sha-2-128 is SHA256 truncated to 128 bits as per NIST instructions.

The collision resistant digest identifier for the content is then formed as:

digest + E ( digest, key )

"Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q",
"491X0pTnLkJHFN_AVctJUA")

The result is an identifier of 256 bits that has 128 bits worth of
authentication security, 128 bits worth of confidentiality security
and 128 bits worth of birthday attack collision resistance.

For the current WebSec use cases, only the digest is actually
required. I am not entirely convinced, but I suspect that for our use
cases the truncated identifier would be sufficient since we rely only
on the 2nd preimage resistance property.

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. Dürst"
 wrote:
> On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip
> Hallam-Baker:
>
>>> Only real issue for me is that it has to fit in URI type slots. The
>>> scheme I was thinking of would be a pure URN scheme, your proposal
>>> includes URL like things.
>
> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at all;
> in RFC 3986, I think slashes would even be allowed if they don't appear
> directly after the first ':'), then you can define an URI scheme without
> including host-like stuff and you don't have to use "urn:" as a prefix.

I think that 'some' structure would be useful. I don't see that
keeping the Base64 character scheme needs to be a priority. There have
been plenty of alternatives that don't use a slash as one of the two
extra chars.

>> Yep. We have use-cases for that. Note though that the authority
>> part is optional, so a fairly bare digest is quite possible and
>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj...
>
> The triple slash at the beginning is a bad idea. There should only be
> slashes if the scheme conforms to the generic syntax (i.e. a double slash,
> something like a host name, and then slashes for something pathlike). Just
> ni:sha256:NDVmZTMzOGVkY2Jj... is way better.

That was Stephen, not me. I was also somewhat surprised by the tripple
slash. It is the sort of thing that could break assumptions.

One of the things I was thinking about was that for our case the
essence of the digest is really the digest part. The domain is really
just a location hint. Why stick at just one domain? If the same
content is present at foo.com and bar.com why not have an identifier
that can specify both:

dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=foo.com&loc=bar.com&ct=text/plain

Now I know that we do not need this for our particular application,
but if we are going to come up with a common scheme with DECADE we
have to meet their use cases as well as out own.

I have some other ideas that would be interesting in the DECADE
context. Right back in 1995 Rohit Khare and myself were fooling about
with identifiers that had decryption keys built in.

For their particular application, the ability to send a single
identifier that allows the content to be uniquely identified,
authenticated and located would be quite interesting I think.

Adding a symmetric decryption key means that the set of people who can
read the plaintext is precisely the set of people with access to the
plaintext plus the people who can access the identifier. The host on
which confidential content resides is thus moved outside the zone
where security concerns apply.

>>> I note that you have a content type, which I have but someone here was
>>> objecting to. I consider the content type to be essential meta-data
>>> for obvious security reasons.
>
> I don't think Paul Hoffman, who brought this up, was objecting. He just
> wanted to know what it's good for. Some security reasons may be obvious for
> you, but not for everybody :-).

Since we already had this discussion at great length in another place
I think that he just does not understand the security issue and never
will.

>> Our use-case for that is for cases where the named object actually
>> arrives in some wrapped form (e.g. encrypted) and you need to know
>> the "inner" content type. However, I could see it being used otherwise
>> or being dropped as things progress.
>
> Just curious: Why would you need to know the inner content type? Wouldn't
> the wrapper contain that information?

Probably so that they can perform negotiation.

If the consumer is a video player, it wants to be able to select
content that it knows how to play. In most cases the player will be
grabbing the bits and negotiating the decryption capability in
parallel.

In my case the concern is that it should be possible to use the
generalized form of this identifier as a secure URL for referencing
static content from a secure Web page.

So imagine that we have anybank.com that has its main pages on HTTPS
but has the images etc. on a separate server that really does not need
SSL for any purpose other than authenticating the source.

It would be a trivial matter to write a script that could transform
such Web pages into Web pages with 'hardened' URLs of the digest form
being discussed here. This would in turn provide a long term answer to
the problem of efficiently supporting the strict security concerns we
discuss here without the overhead of SSL everywhere.

The only problem with that being that the content-type is actually a
security sensitive piece of meta-data and manipulation of
content-types is a major attack vector (probably the fastest growing
at the mo).

-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-10-03 Thread Julian Reschke


On 2011-10-03 09:29, "Martin J. Dürst" wrote:

On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip
Hallam-Baker:


Only real issue for me is that it has to fit in URI type slots. The
scheme I was thinking of would be a pure URN scheme, your proposal
includes URL like things.


If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at
all; in RFC 3986, I think slashes would even be allowed if they don't
appear directly after the first ':'), then you can define an URI scheme
without including host-like stuff and you don't have to use "urn:" as a
prefix.


Yep. We have use-cases for that. Note though that the authority
part is optional, so a fairly bare digest is quite possible and
would look like ni:///sha256:NDVmZTMzOGVkY2Jj...


The triple slash at the beginning is a bad idea. There should only be
slashes if the scheme conforms to the generic syntax (i.e. a double
slash, something like a host name, and then slashes for something
pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better.

> ...

Also keep in mind that if you use "/" for a different purpose than 
hierarchy, surprising things will happen when relative references are 
resolved. It's good to avoid them in this case.


Best regards, Julian
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme


On 2011/09/30 1:33, Phillip Hallam-Baker wrote:


OK, I will rev the draft to make it text identifiers.


Great!



I will also check up on the uri syntax issues. Base64 uses two non
ascii characters and these need to be checked for legality.


These are '+' and '/'. As for '+', this is a sub-delim in RFC 3986, but 
I don't see any problem in using it, unless you create a query-part 
syntax and expect users to enter it in HTML forms (In which case you 
would get hit by the space->'+' conversion).


The '/' is somewhat different, because it's heavily involved in 
resolution of relative references,... But even there, I don't see a 
problem if we never have a '/' (or worse, two or more) after the initial 
colon. And relative references won't make sense for digests anyway, as 
far as I understand.




We might also reduce the length of the scheme name maybe? digest is 6
chars, do we need them all?


The shortest you could go is just one character, 'd'. But frankly, I 
don't understand why we need to be short and opaque. This would be 
another thing if the term we started was 10 or 20 characters long.




I would also like to see if we can ditch
the urn: prefix legally, it was bogus from the start, names and
locators are not disjoint categories.


Just go ahead and ditch it.


Regards,Martin.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

On 2011/09/30 23:40, stephen.farr...@cs.tcd.ie answered Phillip 
Hallam-Baker:



Only real issue for me is that it has to fit in URI type slots. The
scheme I was thinking of would be a pure URN scheme, your proposal
includes URL like things.


If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at 
all; in RFC 3986, I think slashes would even be allowed if they don't 
appear directly after the first ':'), then you can define an URI scheme 
without including host-like stuff and you don't have to use "urn:" as a 
prefix.



Yep. We have use-cases for that. Note though that the authority
part is optional, so a fairly bare digest is quite possible and
would look like ni:///sha256:NDVmZTMzOGVkY2Jj...


The triple slash at the beginning is a bad idea. There should only be 
slashes if the scheme conforms to the generic syntax (i.e. a double 
slash, something like a host name, and then slashes for something 
pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better.



Clearly, your scheme is a better way to reference external content in
a resolvable format. I have to go look at the URN and URI specs again
in detail.


I also thought about URNs but was told (by PSA I think) that those
are intended for managed name spaces and not things like this.


This recently came up on the urn mailing list. Please e.g. see
http://www.ietf.org/mail-archive/web/urn/current/msg01616.html.



I note that you have a content type, which I have but someone here was
objecting to. I consider the content type to be essential meta-data
for obvious security reasons.


I don't think Paul Hoffman, who brought this up, was objecting. He just 
wanted to know what it's good for. Some security reasons may be obvious 
for you, but not for everybody :-).



Our use-case for that is for cases where the named object actually
arrives in some wrapped form (e.g. encrypted) and you need to know
the "inner" content type. However, I could see it being used otherwise
or being dropped as things progress.


Just curious: Why would you need to know the inner content type? 
Wouldn't the wrapper contain that information?


Regards,   Martin.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-10-02 Thread Tobias Gondrom


Hi guys,
a big +1 for the "do it once". ;-)

Whether DECADE or WEBSEC - think that is something we can sort out in 
Taipei or shortly afterwards.


As we already have several ideas on that, it seems interesting enough to 
discuss at the websec meeting in Taipei? Any volunteers for a short 
presentation/discussion slot on this bit?
(if yes, please drop a quick email to Alexey, Yoav and me so we can 
adjust the agenda...)


Kind regards, Tobias


On 30/09/11 15:40, stephen.farr...@cs.tcd.ie wrote:

Hiya,


Come to think of it, didn't you send this to us when we first proposed
the ODI thing in CAA v1.0?

Could be. When my little brain sees a good idea, it tends to repeat
it:-)


I really don't care about the specifics of the design half so much as
we end up with having one, not three.

Strongly agree. I think a URI for naming things with digests should
have broad applicability.


Only real issue for me is that it has to fit in URI type slots. The
scheme I was thinking of would be a pure URN scheme, your proposal
includes URL like things.

Yep. We have use-cases for that. Note though that the authority
part is optional, so a fairly bare digest is quite possible and
would look like ni:///sha256:NDVmZTMzOGVkY2Jj...


Clearly, your scheme is a better way to reference external content in
a resolvable format. I have to go look at the URN and URI specs again
in detail.

I also thought about URNs but was told (by PSA I think) that those
are intended for managed name spaces and not things like this.


I note that you have a content type, which I have but someone here was
objecting to. I consider the content type to be essential meta-data
for obvious security reasons.

Our use-case for that is for cases where the named object actually
arrives in some wrapped form (e.g. encrypted) and you need to know
the "inner" content type. However, I could see it being used otherwise
or being dropped as things progress.


You want to share your design issue here or should we go offline, rev
the proposal and come back?

I'm not bothered by where or how we progress this, so long as we do
the right thing and do it once:-)

I need to check with co-authors about what DECADE want, but this I-D
could be worked there or here in WEBSEC. I'm very happy to have more
help as well if it gets us closer to doing this once only.

FWIW, we're part of a project that is coding this up, and will
almost certainly release a library with a reasonable license in a
few months.

Cheers,
S.


On Thu, Sep 29, 2011 at 6:00 PM,  wrote:



I agree with the motivation but not the design. A while ago
I posted my idea for a design for this. [1] It may become a
work item for the DECADE WG, ... or not, we'll see.

S.

[1] http://tools.ietf.org/html/draft-farrell-ni-00



As I mentioned previously, the need to refer to a static data object
by means of a digest comes up frequently. Rather than re-invent the
mechanism for creating a reference each time we need one, it would be
better if we had a single format that could be re-used.

We used to have this back in the days when we trusted MD5 since we
used that everywhere as a 'fingerprint'. Then things got muddy after
the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it
will be very muddy.

This would be relevant to the cert pinning debate.


I wrote a draft making the proposal:

http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt


On the digest front the objective would be to make it possible to use
the URI format with any digest at all in theory but strongly encourage
people to only use the digests IETF is confident in. Use of OIDs as
the identifier has the nice property that anyone can get an identifier
to distinguish their algorithm from other people's but getting an OID
does not produce any paper trail that can be used to imply an IETF
endorsement.

We could add in support for the text based identifiers as well, but
since the only identifiers that I would want to encourage are SHA2 and
SHA3, I don't see a need. For all applications that make sense it is
going to be perfectly OK to simply generate the prefix for the
identifier part as a static array of octets and append / verify it as
such whenever it is needed. I do not see any need to write ASN.1
handling code for these apps :-)


The basic idea here is that we need to allow for algorithm agility and
to prevent a content substitution attack. So imagine that we have web
page A linking to some off site static content via a digest. Site A
regards the static content as a PNG and has checked out the page and
it works fine. What they don't know is that buried in the PNG there is
some malicious Jscript and if the content server delivers it as
application/script the result will be a series of syntax errors (that
are silently ignored because the app is stupid)  and then it finds the
malicious code... ooops.

OK, so maybe not an attack that you find to be a worry in every
circumstance, but it is definitely an attack vector we should address
in a general

Re: [websec] Digest URI scheme

2011-09-30 Thread stephen . farrell


Hiya,

> Come to think of it, didn't you send this to us when we first proposed
> the ODI thing in CAA v1.0?

Could be. When my little brain sees a good idea, it tends to repeat
it:-)

> I really don't care about the specifics of the design half so much as
> we end up with having one, not three.

Strongly agree. I think a URI for naming things with digests should
have broad applicability.

> Only real issue for me is that it has to fit in URI type slots. The
> scheme I was thinking of would be a pure URN scheme, your proposal
> includes URL like things.

Yep. We have use-cases for that. Note though that the authority
part is optional, so a fairly bare digest is quite possible and
would look like ni:///sha256:NDVmZTMzOGVkY2Jj...

> Clearly, your scheme is a better way to reference external content in
> a resolvable format. I have to go look at the URN and URI specs again
> in detail.

I also thought about URNs but was told (by PSA I think) that those
are intended for managed name spaces and not things like this.

> I note that you have a content type, which I have but someone here was
> objecting to. I consider the content type to be essential meta-data
> for obvious security reasons.

Our use-case for that is for cases where the named object actually
arrives in some wrapped form (e.g. encrypted) and you need to know
the "inner" content type. However, I could see it being used otherwise
or being dropped as things progress.

> You want to share your design issue here or should we go offline, rev
> the proposal and come back?

I'm not bothered by where or how we progress this, so long as we do
the right thing and do it once:-)

I need to check with co-authors about what DECADE want, but this I-D
could be worked there or here in WEBSEC. I'm very happy to have more
help as well if it gets us closer to doing this once only.

FWIW, we're part of a project that is coding this up, and will
almost certainly release a library with a reasonable license in a
few months.

Cheers,
S.

>
> On Thu, Sep 29, 2011 at 6:00 PM,   wrote:
>>
>> 
>>
>> I agree with the motivation but not the design. A while ago
>> I posted my idea for a design for this. [1] It may become a
>> work item for the DECADE WG, ... or not, we'll see.
>>
>> S.
>>
>> [1] http://tools.ietf.org/html/draft-farrell-ni-00
>>
>>
>>> As I mentioned previously, the need to refer to a static data object
>>> by means of a digest comes up frequently. Rather than re-invent the
>>> mechanism for creating a reference each time we need one, it would be
>>> better if we had a single format that could be re-used.
>>>
>>> We used to have this back in the days when we trusted MD5 since we
>>> used that everywhere as a 'fingerprint'. Then things got muddy after
>>> the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it
>>> will be very muddy.
>>>
>>> This would be relevant to the cert pinning debate.
>>>
>>>
>>> I wrote a draft making the proposal:
>>>
>>> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt
>>>
>>>
>>> On the digest front the objective would be to make it possible to use
>>> the URI format with any digest at all in theory but strongly encourage
>>> people to only use the digests IETF is confident in. Use of OIDs as
>>> the identifier has the nice property that anyone can get an identifier
>>> to distinguish their algorithm from other people's but getting an OID
>>> does not produce any paper trail that can be used to imply an IETF
>>> endorsement.
>>>
>>> We could add in support for the text based identifiers as well, but
>>> since the only identifiers that I would want to encourage are SHA2 and
>>> SHA3, I don't see a need. For all applications that make sense it is
>>> going to be perfectly OK to simply generate the prefix for the
>>> identifier part as a static array of octets and append / verify it as
>>> such whenever it is needed. I do not see any need to write ASN.1
>>> handling code for these apps :-)
>>>
>>>
>>> The basic idea here is that we need to allow for algorithm agility and
>>> to prevent a content substitution attack. So imagine that we have web
>>> page A linking to some off site static content via a digest. Site A
>>> regards the static content as a PNG and has checked out the page and
>>> it works fine. What they don't know is that buried in the PNG there is
>>> some malicious Jscript and if the content server delivers it as
>>> application/script the result will be a series of syntax errors (that
>>> are silently ignored because the app is stupid)  and then it finds the
>>> malicious code... ooops.
>>>
>>> OK, so maybe not an attack that you find to be a worry in every
>>> circumstance, but it is definitely an attack vector we should address
>>> in a general purpose crypto building block.
>>>
>>>
>>> Having produced a static building block like this it is very easy to
>>> generate a fingerprint for a static data object in a cut and paste
>>> ready format. I don't need a separate tool to generate digest
>>> identifier

Re: [websec] Digest URI scheme

Come to think of it, didn't you send this to us when we first proposed
the ODI thing in CAA v1.0?


I really don't care about the specifics of the design half so much as
we end up with having one, not three.

Only real issue for me is that it has to fit in URI type slots. The
scheme I was thinking of would be a pure URN scheme, your proposal
includes URL like things.

Clearly, your scheme is a better way to reference external content in
a resolvable format. I have to go look at the URN and URI specs again
in detail.


I note that you have a content type, which I have but someone here was
objecting to. I consider the content type to be essential meta-data
for obvious security reasons.


You want to share your design issue here or should we go offline, rev
the proposal and come back?




On Thu, Sep 29, 2011 at 6:00 PM,   wrote:
>
> 
>
> I agree with the motivation but not the design. A while ago
> I posted my idea for a design for this. [1] It may become a
> work item for the DECADE WG, ... or not, we'll see.
>
> S.
>
> [1] http://tools.ietf.org/html/draft-farrell-ni-00
>
>
>> As I mentioned previously, the need to refer to a static data object
>> by means of a digest comes up frequently. Rather than re-invent the
>> mechanism for creating a reference each time we need one, it would be
>> better if we had a single format that could be re-used.
>>
>> We used to have this back in the days when we trusted MD5 since we
>> used that everywhere as a 'fingerprint'. Then things got muddy after
>> the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it
>> will be very muddy.
>>
>> This would be relevant to the cert pinning debate.
>>
>>
>> I wrote a draft making the proposal:
>>
>> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt
>>
>>
>> On the digest front the objective would be to make it possible to use
>> the URI format with any digest at all in theory but strongly encourage
>> people to only use the digests IETF is confident in. Use of OIDs as
>> the identifier has the nice property that anyone can get an identifier
>> to distinguish their algorithm from other people's but getting an OID
>> does not produce any paper trail that can be used to imply an IETF
>> endorsement.
>>
>> We could add in support for the text based identifiers as well, but
>> since the only identifiers that I would want to encourage are SHA2 and
>> SHA3, I don't see a need. For all applications that make sense it is
>> going to be perfectly OK to simply generate the prefix for the
>> identifier part as a static array of octets and append / verify it as
>> such whenever it is needed. I do not see any need to write ASN.1
>> handling code for these apps :-)
>>
>>
>> The basic idea here is that we need to allow for algorithm agility and
>> to prevent a content substitution attack. So imagine that we have web
>> page A linking to some off site static content via a digest. Site A
>> regards the static content as a PNG and has checked out the page and
>> it works fine. What they don't know is that buried in the PNG there is
>> some malicious Jscript and if the content server delivers it as
>> application/script the result will be a series of syntax errors (that
>> are silently ignored because the app is stupid)  and then it finds the
>> malicious code... ooops.
>>
>> OK, so maybe not an attack that you find to be a worry in every
>> circumstance, but it is definitely an attack vector we should address
>> in a general purpose crypto building block.
>>
>>
>> Having produced a static building block like this it is very easy to
>> generate a fingerprint for a static data object in a cut and paste
>> ready format. I don't need a separate tool to generate digest
>> identifiers for WebSec vs other applications. In terms of ease of use
>> we get back to what things were like when we used MD5 fingerprints.
>>
>> It is also quite easy to make use of truncated fingerprints should
>> that be necessary. For example, to put on a business card.
>>
>> --
>> Website: http://hallambaker.com/
>> ___
>> websec mailing list
>> websec@ietf.org
>> https://www.ietf.org/mailman/listinfo/websec
>>
>
>
>



-- 
Website: http://hallambaker.com/
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-09-29 Thread stephen . farrell




I agree with the motivation but not the design. A while ago
I posted my idea for a design for this. [1] It may become a
work item for the DECADE WG, ... or not, we'll see.

S.

[1] http://tools.ietf.org/html/draft-farrell-ni-00


> As I mentioned previously, the need to refer to a static data object
> by means of a digest comes up frequently. Rather than re-invent the
> mechanism for creating a reference each time we need one, it would be
> better if we had a single format that could be re-used.
>
> We used to have this back in the days when we trusted MD5 since we
> used that everywhere as a 'fingerprint'. Then things got muddy after
> the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it
> will be very muddy.
>
> This would be relevant to the cert pinning debate.
>
>
> I wrote a draft making the proposal:
>
> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt
>
>
> On the digest front the objective would be to make it possible to use
> the URI format with any digest at all in theory but strongly encourage
> people to only use the digests IETF is confident in. Use of OIDs as
> the identifier has the nice property that anyone can get an identifier
> to distinguish their algorithm from other people's but getting an OID
> does not produce any paper trail that can be used to imply an IETF
> endorsement.
>
> We could add in support for the text based identifiers as well, but
> since the only identifiers that I would want to encourage are SHA2 and
> SHA3, I don't see a need. For all applications that make sense it is
> going to be perfectly OK to simply generate the prefix for the
> identifier part as a static array of octets and append / verify it as
> such whenever it is needed. I do not see any need to write ASN.1
> handling code for these apps :-)
>
>
> The basic idea here is that we need to allow for algorithm agility and
> to prevent a content substitution attack. So imagine that we have web
> page A linking to some off site static content via a digest. Site A
> regards the static content as a PNG and has checked out the page and
> it works fine. What they don't know is that buried in the PNG there is
> some malicious Jscript and if the content server delivers it as
> application/script the result will be a series of syntax errors (that
> are silently ignored because the app is stupid)  and then it finds the
> malicious code... ooops.
>
> OK, so maybe not an attack that you find to be a worry in every
> circumstance, but it is definitely an attack vector we should address
> in a general purpose crypto building block.
>
>
> Having produced a static building block like this it is very easy to
> generate a fingerprint for a static data object in a cut and paste
> ready format. I don't need a separate tool to generate digest
> identifiers for WebSec vs other applications. In terms of ease of use
> we get back to what things were like when we used MD5 fingerprints.
>
> It is also quite easy to make use of truncated fingerprints should
> that be necessary. For example, to put on a business card.
>
> --
> Website: http://hallambaker.com/
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-09-29 Thread Tobias Gondrom


On 29/09/11 17:55, Paul Hoffman wrote:

On Sep 29, 2011, at 9:44 AM, Phillip Hallam-Baker wrote:


If we go for text, we should use:

http://www.iana.org/assignments/dssc/dssc.xml

+1

+1. Makes sense.


So there would have to be text to strongly discourage use of sha-1 and
very strongly discourage md2 and md5.

+1. Even just "very strongly discourage" all three.


+1 on very strongly discourage md2, md5.
Not sure whether we need to explicitely also "very strongly discourage" 
sha-1.


Btw. on a personal note: understanding why we need to discourage those. 
Do we need to judge the security of hash algorithms in every standards 
documents using them individually? After all, after a couple of years 
even SHA-3 may become weak/broken while the RFC would still encourage 
one alg and discourage the others. Don't we have a central place to 
state quality/recommendation of used algorithms, that could just be 
referenced to enhance alg agility.





--Paul Hoffman

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec


___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

2011-09-29 Thread Paul Hoffman


On Sep 29, 2011, at 9:44 AM, Phillip Hallam-Baker wrote:

> If we go for text, we should use:
> 
> http://www.iana.org/assignments/dssc/dssc.xml

+1

> So there would have to be text to strongly discourage use of sha-1 and
> very strongly discourage md2 and md5.

+1. Even just "very strongly discourage" all three.

--Paul Hoffman

___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

If we go for text, we should use:

http://www.iana.org/assignments/dssc/dssc.xml

Registration Procedures : First Come First Served
Reference : [RFC5698]


Here are the digest algs:

md2 1.2.840.113549.2.2  [RFC3279]
md5 1.2.840.113549.2.5 [RFC3279][RFC4051]
sha-1   1.3.14.3.2.26 [RFC3279][RFC4051]
sha-224 2.16.840.1.101.3.4.2.4 [RFC4055][RFC4051]
sha-256 2.16.840.1.101.3.4.2.1 [RFC4055]
sha-384 2.16.840.1.101.3.4.2.2 [RFC4055][RFC4051]
sha-512 2.16.840.1.101.3.4.2.3 [RFC4055]

I would presume that sha-3-* will be defined in due course.


So there would have to be text to strongly discourage use of sha-1 and
very strongly discourage md2 and md5.

I don't think we could prohibit use while relying on an extensible registry.
___
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Re: [websec] Digest URI scheme

OK, I will rev the draft to make it text identifiers.

I am aware of the urn:sha1 stuff. I would prefer to avoid having every
digest become a urn scheme, plus there are issues with the legacy.


I will also check up on the uri syntax issues. Base64 uses two non
ascii characters and these need to be checked for legality. There is
some other house cleaning stuff.

We might also reduce the length of the scheme name maybe? digest is 6
chars, do we need them all? I would also like to see if we can ditch
the urn: prefix legally, it was bogus from the start, names and
locators are not disjoint categories.

On Wed, Sep 28, 2011 at 12:55 PM, Tobias Gondrom
 wrote:
> 
> I would also agree with the textual form. And don't see any reasons for
> using ASN.1 in this instance.
> For the alg identifier, there might be reasons for using values from a
> registry, as that gives extendibility and at the same time the ids reference
> their specifications (which is superior to just using a name and hope that
> everybody understands it the same way, i.e. uses the same specification).
>
>
> 
> like the idea and it could be within websec charter if we as a WG want to
> work on that.
> If you like we could have a discussion on that in Taipei (volunteers please
> contact me in the next few days so I can make sure the slot in the agenda is
> sufficient)
> For drafts, please consider that there are cut-off dates for Taipei.
>
> Kind regards, Tobias
>
>
>
> On 28/09/11 11:52, "Martin J. Dürst" wrote:
>>
>> I fully agree with others that a textual form is better. That's the
>> tradition of URIs. It's much easier to implement, write tests, and so on,
>> and won't unnecessarily scare people away.
>>
>> Regards,    Martin.
>>
>>
>> P.S.: As a nit (but a strong one), the current draft has "DIGEST:" all
>> over the place. But RFC 3986
>> (http://tools.ietf.org/html/rfc3986#section-3.1, second paragraph) says:
>>
>>   Scheme names consist of a sequence of characters beginning with a
>>   letter and followed by any combination of letters, digits, plus
>>   ("+"), period ("."), or hyphen ("-").  Although schemes are case-
>>   insensitive, the canonical form is lowercase and documents that
>>   specify schemes must do so with lowercase letters.  An implementation
>>   should accept uppercase letters as equivalent to lowercase in scheme
>>   names (e.g., allow "HTTP" as well as "http") for the sake of
>>   robustness but should only produce lowercase scheme names for
>>   consistency.
>>
>> which fully matches current practice.
>>
>>
>> On 2011/09/28 18:32, Gervase Markham wrote:
>>>
>>> On 27/09/11 18:10, Phillip Hallam-Baker wrote:

 On the digest front the objective would be to make it possible to use
 the URI format with any digest at all in theory but strongly encourage
 people to only use the digests IETF is confident in. Use of OIDs as
 the identifier has the nice property that anyone can get an identifier
 to distinguish their algorithm from other people's but getting an OID
 does not produce any paper trail that can be used to imply an IETF
 endorsement.
>>>
>>> But it also makes the identifiers less human readable and much longer
>>> than they could otherwise be.
>>>
 We could add in support for the text based identifiers as well, but
 since the only identifiers that I would want to encourage are SHA2 and
 SHA3, I don't see a need.
>>>
>>> Why does it take so many bytes to determine between a very small number
>>> of options?
>>>
>>> Worrying about clashes in the text-based identifiers people use seems
>>> somewhat unnecessary. How many hash algorithms with the same name (or
>>> without an obvious canonical name) are there? If this was really a
>>> problem, we could have a microformats-like wiki registry:
>>> http://microformats.org/wiki/existing-rel-values
>>>
 For all applications that make sense it is
 going to be perfectly OK to simply generate the prefix for the
 identifier part as a static array of octets and append / verify it as
 such whenever it is needed. I do not see any need to write ASN.1
 handling code for these apps :-)
>>>
>>> Then why use ASN.1 at all?
>>>
>>> Counter-proposal: how about:
>>>
>>> digest:SHA1,
>>>
>>> Like a data: URL, except without the option for ASCII/URL encoding:
>>> http://en.wikipedia.org/wiki/Data_URI_scheme
>>>
>>> For bonus points, allow multiple comma-separated digests to ease
>>> algorithm migration.
>>>
>>> Simple :-)
>>>
>>> Gerv
>>>
>>> ___
>>> websec mailing list
>>> websec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/websec
>>>
>> ___
>> websec mailing list
>> websec@ietf.org
>> https://www.ietf.org/mailman/listinfo/websec
>
> ___
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
>



-- 
Website: http://hallambaker.com/
___

Re: [websec] Digest URI scheme