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, [email protected] 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,<[email protected]> wrote:
<no hats>
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
[email protected]
https://www.ietf.org/mailman/listinfo/websec
--
Website: http://hallambaker.com/
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
