- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 24 Mar 2011 17:51:18 +1100
- To: Eran Hammer-Lahav <eran@hueniverse.com>
- Cc: "Thomson, Martin" <Martin.Thomson@commscope.com>, Bill Burke <bburke@redhat.com>, HTTP Working Group <ietf-http-wg@w3.org>
To be clear -- this isn't a WG item, it's a side effort that's using the list for feedback (as many HTTP-related projects do). So, there's no "we" producing the specification, in an IETF WG sense. If Bill wants to submit a draft, implement it, and take feedback from interested folks, nothing here can (or should) stop him. That being the case, why not specify it and let the market decide? Cheers, On 24/03/2011, at 5:47 PM, Eran Hammer-Lahav wrote: > Sure. But there are enough real world deployment issues (frameworks, proxies, broken servers) which render canonicalization of request/response headers pretty much a lost cause. I think a standard way to sign HTTP messages is important, but there should be clear security reasons for normalizing and signing headers (are there actual attacks based solely on changing the header that cannot be prevented with a slightly more intelligent application logic?). > > No matter what the use cases are, most signature algorithm requiring complex canonicalization of data have failed the test of widespread adoption, so before we produce yet another such solutions, we should figure out if this complexity adds real value. > > Also, verification of the body should be possible independently from the header (i.e. optional on both sides). > > EHL > >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Wednesday, March 23, 2011 10:07 PM >> To: Eran Hammer-Lahav >> Cc: Thomson, Martin; Bill Burke; HTTP Working Group >> Subject: Re: Feedback on draft-burke-content-signature-00.txt >> >> TLS everywhere has its own galaxy of issues (one of which has been recently >> highlighted!). I think there are enough use cases for this to make it >> interesting. >> >> Cheers, >> >> >> On 24/03/2011, at 4:01 PM, Eran Hammer-Lahav wrote: >> >>> FWIW, my experience from developing and implementing HTTP request >> signatures in OAuth 1.0 [1] and HTTP MAC authentication [2] is that >> canonicalization of header fields is most likely doomed. >>> >>> At least on the consumer web front, developers are moving away from >> having anything to do with signatures and simply relying on TLS. My HTTP >> MAC authentication draft represents the most the OAuth community is >> willing to swallow, and even that unenthusiastically. >>> >>> EHL >>> >>> [1] http://tools.ietf.org/html/rfc5849 >>> [2] http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 >>> >>> >>>> -----Original Message----- >>>> From: ietf-http-wg-request@w3.org >>>> [mailto:ietf-http-wg-request@w3.org] >>>> On Behalf Of Thomson, Martin >>>> Sent: Wednesday, March 23, 2011 7:42 PM >>>> To: Mark Nottingham; Bill Burke >>>> Cc: HTTP Working Group >>>> Subject: RE: Feedback on draft-burke-content-signature-00.txt >>>> >>>> I'm similarly pleased by the effort. More people are looking for >>>> this functionality recently (I'd go spruiking in the ALTO working group, for >> one). >>>> >>>> Just adding a few comments of my own: >>>> >>>> * Signatures in trailers are a distinct (and useful) option, >>>> particularly for sizeable or dynamic streamed content. (That came >>>> from ALTO :) >>>> >>>> * How you identify the signing principal is a critical aspect of the >>>> document that is only given superficial treatment. I'd go a good >>>> deal beyond Mark's comments and say that you have a lot of missing >>>> detail in this area. For instance, does a relying party need to be >>>> able to determine who they expect a signer to be for a given >>>> resource? There's a lot of existing PKI infrastructure that is >>>> already in use for HTTPS that I'd imagine people would be happy to >>>> use in many cases, but that might be too restrictive for others. How a >> client principal is identified is an even more challenging prospect. >>>> >>>> * Your concatenation method for signing should include delimiters for >>>> values. Concatenating "abc" and "def" is otherwise identical to "a", >>>> "b", "c", and "def". Set up a concatenation operator that handles >>>> this case (and be aware that some delimiters could appear in >>>> headers...and any delimiter can appear in a body). >>>> >>>> * Base64 encoding saves a few more bytes over hex. >>>> >>>> * [NIT] I would not have seen this draft if it weren't for Mark's >>>> email. I'd suggest adding a -http- to the name. >>>> >>>> * [NIT] Header syntax is defined using RFC 5234 syntax in the HTTPbis >> drafts. >>>> Have a look at that syntax (it doesn't use #, for instance) >>>> >>>> * [NIT] Take a look at an existing IANA registry for signature method >>>> identifiers and use that. TLS [1] or DKIM [2] might be a little too >>>> abstract, but keynote [3] looks promising, though it has an >>>> unfortunate encoding component bound to each identifier. >>>> >>>> I'm going to agree with the bulk of what Mark says. More inline... >>>> >>>> Cheers, >>>> Martin >>>> >>>> [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.xml >>>> [2] http://www.iana.org/assignments/dkim-parameters/dkim- >>>> parameters.xml >>>> [3] http://www.iana.org/assignments/keynote/keynote.xml >>>> >>>> On 2011-03-23 at 11:38:31, Mark Nottingham wrote: >>>>> <http://www.ietf.org/internet-drafts/draft-burke-content-signature- >>>>> 00.txt> >>>>> >>>>> Bill, >>>>> >>>>> First of all, I'm very excited that somebody has finally picked up >>>>> the ball on this; it's been discussed for a long time. >>>>> >>>>> Some thoughts, in no particular order: >>>>> >>>>> * The Content-Signature header field-name, along with the various >>>>> parameter names in its value, are quite lengthy. Can I suggest just >>>>> "Sig" for the field-name, and correspondingly shorter parameter names? >>>>> Saving bytes will help deployment. >>>>> >>>>> * I'd argue that there are some HTTP headers which, if present, >>>>> should always form part of the signature, both because they're an >>>>> intrinsic part of the message, and because doing so will (again) >>>>> save bytes in these common cases. Content-Type is the most >>>>> important, but Date, Expires, Cache-Control, ETag, Last-Modified, >>>>> P3P, and Warning may also be suitable. >>>>> >>>>> The important thing here is to figure out a reasonable default that >>>>> works for most cases, so that they can save the bytes and verbosity. >>>>> If necessary, maybe an opt-out for these common headers could be >>>> defined. >>>> >>>> Hmm: >>>> Content-Sig: header=Host;-Content-Type >>>> >>>>> * It'd be good to have a way to include the request-target (i.e., >>>>> the result of combining the host header and the request-line) in a >>>>> request's signature, and the status code in a response signature. >>>>> >>>>> * I can think of a few cases where it's important to NOT sign the >>>>> body, but still sign some headers, etc. >>>> >>>> Another possible use is an intermediary that inserts, then signs an >>>> X- Forwarded-For header to limit spoofing. This can be done on a >>>> clear-text bearer. >>>> >>>>> * The timestamp parameter's purpose is defined as "this gives the >>>>> receiver the option to refuse old signed messages." In some >>>>> implementations, that purpose could be better served by signing the >>>>> Date header, so maybe say something like "this allows signing >>>>> messages before they're actually generated." >>>>> >>>>> BTW, one cool use case is that signing the Date, Cache-Control and >>>>> Expires headers enables clients to verify that the caching policy >>>>> has been honoured by intermediaries. >>>>> >>>>> * A little bit more needs to be said about header canonicalisation; >>>>> at a minimum, an algorithm for stripping whitespace and combining >>>>> multiple header field-values needs to be defined, taking into >>>>> account that intermediaries can modify message headers in certain >> ways. >>>> >>>> Some guidance on this last part is probably useful. Identifying the >>>> headers that intermediaries invariably change is probably important >>>> (see Mark's hop- by-hop comment below). >>>> >>>>> * What algorithm is used if the algorithm parameter is missing? >>>>> Also, at least one algorithm should be pre-defined, to improve interop. >>>>> >>>>> * There currently isn't any structure to the signer field. What >>>>> about putting a URI there, or specifying a parameter for one, so >>>>> that the public key can be discovered? I know this is highly >>>>> algorithm-specific, but IMO most / all algorithms should have a way >>>>> to discover the key, so as to encourage decoupling. >>>> >>>> To expand on this, there should be one baseline with a clearly >>>> defined mechanism for discovering the key. Without that, this >>>> becomes little more than a curiosity. >>>> >>>>> * Can you speak to why you included the ability to put non-signature >>>>> metadata in the field-value, rather than just signing it as the >>>>> payload of other headers? >>>>> >>>>> * It would be friendly to include a warning that hop-by-hop headers >>>>> should not be included in a signature, and to remind people that >>>>> headers which are allowed to be modified by an intermediary (e.g., >>>>> Age) are also probably not wise. >>>>> >>>>> * NIT - Throughout, you use "entity header." In HTTPbis, we've just >>>>> moved away from this terminology; it should just be "header" now. >>>>> >>>>> * NIT - In a few places, you say "server" where "recipient" would be >>>>> more appropriate. >>>>> >>>>> * NIT - It's important to clearly specify that the payload body is >>>>> being signed, not the bytes on the wire. See >>>>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-13#secti >>>>> on >>>>> - >>>>> 3.3>. >>>>> >>>>> Cheers, >>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 24 March 2011 06:51:52 UTC