MAX: please look for your name.
Toerless Eckert <t...@cs.fau.de> wrote:
> Section 5)
> a) Suggest changing the title to "Protocol Details (Pledge - Registrar
> - MASA / CA)"
> to distinguish from Section 4. Might consider also to move up section
renamed.
> b) MASA URI is "https:// authority "./well-known/est".
> ^
> missing a " ?
already fixed.
> c) BRSKI-EST connections SHOULD use persistent connections
> The intention of this guidance is to ensure the provisional TLS
> authentication occurs only once and is properly managed.
> This is not clear to me, please rephrase.
> - What does "properly managed" mean ?
I no longer recall.
I think it's content-free. It means don't throw away the connection
each time or do dumb things with your SSL context.
> - Why would provisional TLS authentication have to occur more than once
> without persistent connection ?
<t>
While EST section 3.2 does not insist upon use of HTTP 1.1
persistent connections, BRSKI-EST connections SHOULD use persistent
connections. The intention of this guidance is to ensure the
provisional TLS state occurs only once, and that the subsequent
resolution of the provision state is not subject to a MITM attack
during a critical phase.
</t>
> The first connection only retrieves the voucher, but then lets say the
> Pledge closes the connection and builds a new one for EST
> enrollment. On that second one it would not need to do provisional
> authentication. /cacerts after /requestvoucher ?
I agree that it's possible to come up with a number of places in which
one could restart the TLS connection, at which point a MITM would either
be detected, or would cause a failure, but I would rather not open this door.
The pledge would have to remember the server's certificate and make sure that
it always connects to a server with the same (identical) certificate.
If the JRC is implemented in a load-balanced scenario with a front-end
*TCP* (not SSL) proxy that distributes load, then it is possible that it
would be legitimate for the different servers to have different
certificates. As long as the voucher comes out correct, that's fine.
But, if the pledge is directed to different servers, which a non-persistent
connection could cause to occur, then the pledge will have a hard time.
What if the single server executes a planned reboot, and when it restarts, a
new (fresher) certificate has been installed? The persistent connection
could be tuned to keep server from rebooting until that transaction is over.
Finally, the non-persistent connections could be redirected by the Join Proxy
to different JRCs!
> d) Q: How would BRSKI work in the absence of persistent connections or
> in the presence of failures ? I guess each request from the pledge is a
> standalone transaction and the pledge would just repeat them until it
> succeeds or until a return code would indicate that the Registrar does
> not support this step and the pledge has to terminate.
The requests from the pledge are not standalone transactions.
They are a series of connections that build towards a result.
I don't think we need to support non-persistent connection.
> Aka: The way i see it, the reason for persistent connections is really
> just
> avoiding unnecessary repeated (expensive) TLS connection setup...
yes. So, couldn't you have edited your comments then?
> e) "If the Registrar responds with a redirection to other web origins"
> A reason for this rule should be written into that paragraph.
> ... This is to minimize attacks by fake registrars trying to
> indefinitely redirect a pledge.
MAX: I think that there are other reason as well?
MAX: Also, the pledge can't go anywhere by URL, only to where the Proxy
directs it, so really can any redirection be accepted?
Of course, it can do Host:
I have opened ticket: https://github.com/anima-wg/anima-bootstrap/issues/50
> f) "It should proceed to other discovered Registrars if there are any"
> Pledes don't discover Registrars, the discover Proxies.
> the Proxy can see a couple redundant Registrars.
fixed with:
<t>
To avoid blocking on a single erroneous Registrar the Pledge
MUST drop the connection after 5 seconds in which there has
been no progress on the TCP connection.
It should proceed to
connect to any other Registrar's via any other discovered
Proxies if there are any. If there were no
other Proxies discovered, the Pledge MAY continue to wait,
as long as it is concurrently listening for new Proxy
announcements.
</t>
> f.1) "If necessary the Pledge calls the EST defined /cacerts method to
> obtain the domain owners' CA certificate."
> Please add an explanation when/why this is necessary. This seems to
> contradict the statement in 5.8.1 about not doing /cacerts,/fullcmc
> during Bootstrap but only during enrollment: "Although these
> limitations are acceptable during initial bootstrapping"
> (aka: "no need for /cacerts during bootstrap").
Now https://github.com/anima-wg/anima-bootstrap/issues/51
> g) After "This moves the BRSKI-EST TLS connection out of the provisional
state." add:
> - Afterwards the Pledge trusts this and other Registrars using the same
> trust anchor. It MAY permit more than one redirects, but it MAY still
> time out the registrar for further REST operations and revert to
> another one.
We need to talk more about ticket #50.
> - Mandatory boostrap steps conclude with Voucher Status Telementry (see
> XXX)
done.
> - Move "Optionally, the BRSKI- EST TLS connection can now be used for EST
enrollment."
> out of the bullet list merge wi next sentence ("The extensions...").
done.
> h) "In the language of RFC6125 this provides for a SERIALNUM-ID category
of identifier.."
> RFC6125 does not use the term SERIALNUM-ID and BRSKI does not use this
> term outside of this paragraph either, so it seems redundant. The whole
> paragraph is also quite dense,
> so maybe rewrite/simplify the language.
We thought a lot about how one does matching of identities in PKIX
SubjectAltNames', and RFC6125 provides the best guidance.
I split the paragraph up.
> Would suggest to also move any details o the whitelist logic
> desccription to 5.1,
> 5.0 is just overview. And in 5.1 you mention TLS setup uses RFC7030
> mechanisms while in 5.0 it refers to RFC6125, so i think it would
> become easier to write & read if tht 5.0 whitelisting stuff was moved
> into 5.1 paragraphs refering to EST TLS setup.
Actually, I agree that 5.0 is way too detailed *IN GENERAL*
https://github.com/anima-wg/anima-bootstrap/issues/52
> Suggested append if you agree with it (whatever wording you like):
> a) "nonce: The Pledge voucher-request MUST contain" ...
> ..."Doing so ensures Section 2.5 functionality"
> If one just follows the reference to section 2.5, it looks contradictory:
> "_If_ the voucher contains a nonce then the Pledge MUST confirm "
> Please clarify, this is confusing:
> - If the nonce is a MUST because of section 2.5, then the MUST would
> only have to
> apply to RTCless Pledges. But its not clear to me why... (forgot our
> discussions,
> and readers where never part of them, so explanation would be nice).
5.2 is about requesting a voucher, not about checking.
We decided that all voucher requests MUST have nonces, to enable noncefull
freshness, but whether or not vouchers are required to have nonces is
a manufacturer's decision.
> - fix to "MUST NOT be reused for _MULTIPLE_ bootstrapping attempts
> IMHO also: (especially not across repeated first bootstrap attempts
> after power cycling).
done.
> Section 5.3 1)
> a) "The Registrar initiates the connection and uses the MASA URL obtained
> as described in Section 2.7 for RFC6125 authentication of the MASA
server."
> Q: Does this mean:
> "The Registrar initiates the connection and uses the DNS name of the
> MASA URL obtained
> as described in Section 2.7 for (RFC6125) authentication of the MASA
> server certificate."
MAX, do you think we need to more this precise?
I think that we really want people to read 6125, not just guess.
> Aka: for the less PKIX/Websecurity initiated readers like me, writing out
> what is actually implied could make the sentence easier to parse
> (instead of having to read more of RFC6125.
But, I want you to read 6125 rather than guess.
Or use a library (libcurl or whatever) that does the right thing.
I'll stop here, since there are a number of issues open.
https://goo.gl/8sQfkb for rfcdiff between -12 and github content.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
