ietf
[Top] [All Lists]

RE: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33

2014-09-30 16:00:57
John, to move this discussion along on a concrete basis, as an expert in the 
subject matter, could you write a proposed security considerations subsection 
that explains the conditions under which an exception to the MUST would be OK?  
Then we could evaluate in a concrete way whether we think the specification is 
better with language like "MUST use TLS unless the conditions described in 
Section X.Y are met" or better just requiring TLS to keep things simple.

It would be good if you also expanded on the trust model comments you made 
earlier in the thread and that we discussed on the phone.

                                                                Thanks much,
                                                                -- Mike

From: jose [mailto:jose-bounces(_at_)ietf(_dot_)org] On Behalf Of John Bradley
Sent: Tuesday, September 30, 2014 1:15 PM
To: Dave Cridland
Cc: IETF; IETF Gen-ART; Russ Housley; Mike Jones; jose(_at_)ietf(_dot_)org; 
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33

The attack is not possible if the receiver validates the host from the x5u 
against the certificate CN and validates the path,  otherwise any valid 
certificate would work, as long as it chains to a valid root.

Yes we could explain that that the client could limit itself to a specific root 
or bridge and use the CN or DN for the identity of the signer.

So yes it is possible to make an exception to the MUST but explaining how to do 
that safely is not trivial, and may cause more harm than good.

John B.
On Sep 30, 2014, at 4:53 PM, Dave Cridland 
<dave(_at_)cridland(_dot_)net<mailto:dave(_at_)cridland(_dot_)net>> wrote:




On 30 September 2014 20:37, John Bradley 
<ve7jtb(_at_)ve7jtb(_dot_)com<mailto:ve7jtb(_at_)ve7jtb(_dot_)com>> wrote:
I agree, the likelihood of the application correctly walking the path and 
validating the chain is very small.


I think the likelihood of the application being *able* to is small given the 
scope - however if it can, we should assume that it will.

I strongly prefer leaving it a MUST use TLS and validate the server per RFC 
6125.

The other thing to note is that the CN of the cert is not in the header.  If 
TLS is not used an attacker could simply modify the DNS to retrieve any valid 
certificate and use that to sign.


Whilst I agree there's a range of attacks possible against non-validating 
clients - although "the CN of the cert" sets my teeth on edge - an attacker 
cannot do these if the application performs path validation and checks the key 
matches.

"SHOULD" and "MUST" are not a stick to beat the unthinking implementer, and if 
there exist perfectly reasonable cases where this particular MUST can be 
ignored, then by insisting on a MUST here we are simply weakening the emphasis 
that all other RFC 2119 language has in this document.

"MUST unless you do X" is a compromise I'd be happy with, although that is 
basically what "SHOULD" means.

Certainly this does require the rationale be documented in any case.

Dave.

<Prev in Thread] Current Thread [Next in Thread>