Re: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02

[Benjamin Kaduk <[e-mail]>]

On Sun, Nov 10, 2019 at 03:41:44PM -0500, Russ Housley wrote:
> Ben:
> 
> I have made the edits indicated in my response below.  I cannot pot it until the I-D repository reopens.

I'm happy to approve a manual posting sooner if you want, though I do not
think it would have a huge impact on time-to-end-of-IETF-LC.

> > Thanks for putting this together, and sorry again for the delays in
> > processing.
> > 
> > I note inline many places where we essentially repeat preexisting
> > requirements from RFC 8446 but use normative keywords as if they were
> > new requirements being imposed by this document.  (There are other places
> > where we repeat or duplicate some narrative descriptions from RFC 8446 as
> > well, though I did not note specific locations.) I think our general
> > preference is to try to only use the normative keywords once, and have
> > either direct quotations or descriptive language for other places where we
> > refer to those requirements, though of course there are always exceptions.
> > 
> > Similarly, we may have more duplication of content/requirements between
> > Sections 4 and 5 than is needed.
> > 
> > Some other section-by-section notes are included as well, in particular for
> > the IANA Considerations that will need some tweaking.
> > 
> > Section 3
> > 
> >   The invention of a large-scale quantum computer would pose a serious
> >   challenge for the cryptographic algorithms that are widely deployed
> >   today, including the digital signature algorithms that are used to
> >   authenticate the server in the TLS 1.3 handshake protocol.  It is an
> >   open question whether or not it is feasible to build a large-scale
> >   quantum computer, and if so, when that might happen.  However, if
> >   such a quantum computer is invented, many of the cryptographic
> >   algorithms and the security protocols that use them would become
> >   vulnerable.
> > 
> > Apparently we don't have an RFC style entry for "the kind of quantum
> > computer that we have to worry about for cryptographic purposes"; I see
> > reference to "sufficiently large quantum computer" (RFC 8080),
> > "large-scale quantum computer" (RFC 8576), "cryptographically relevant
> > quantum computer" (RFC 8603), and there's probably more that didn't jump
> > out at me.  (This question did just come up in response to my review of
> > draft-ietf-ipsecme-qr-ikev2, where Scott Fluhrer suggested
> > "cryptographically significant quantum computer", that I was going to
> > lean towards until I did this search just now.)  It would be great to
> > normalize our terminology use here, though I don't know that there's a
> > clear winner yet.
> > (I also wonder if "invention" is quite the right word to describe the
> > process in question, but that's probably a side note.)
> 
> One of your references is using "large-scale quantum computer" as I do in this document.  I can see that alignment on a single term would be desirable, but I do not think that a common term has emerged in the greater research community.
> 
> I will gladly change "invention" to "development" in the first sentence.

Understood, and thanks.

> >   The TLS 1.3 handshake protocol employs key agreement algorithms that
> >   could be broken by the invention of a large-scale quantum computer
> >   [I-D.hoffman-c2pq].  These algorithms include Diffie-Hellman (DH)
> >   [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363].  As a
> > 
> > It might be worth using "also employs" to emphasize that the signature
> > algorithms of the first paragraph and the key-agreement algorithms of
> > the second paragraph are distinct classes of algorithms.
> > Also, do we want to also reference RFC 7748 to get an "I*TF-internal"
> > reference for ECDH technologies?
> 
> I am using the same reference for ECDH as RFC 8446.  This was intensional.

(I grabbed the RFC 7748 reference from RFC 8446, too.)

> I suggest the following to bring in the signature algorithm concern:
> 
>    The TLS 1.3 handshake protocol employs key agreement algorithms and
>    digital signature algorithms that could be broken by the development
>    of a large-scale quantum computer [I-D.hoffman-c2pq].  The key
>    agreement algorithms include Diffie-Hellman (DH) [DH1977] and
>    Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital
>    signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital
>    Signature Algorithm (ECDSA) [FIPS186].  As a result, an adversary
>    that stores a TLS 1.3 handshake protocol exchange today could decrypt
>    the associated encrypted communications in the future when a large-
>    scale quantum computer becomes available.

Okay, that should work.

> > Section 4
> > 
> >   The client includes the "tls_cert_with_extern_psk" extension in the
> >   ClientHello message.  The "tls_cert_with_extern_psk" extension MUST
> >   be accompanied by the "key_share", "psk_key_exchange_modes", and
> > 
> > Do we need to mandate anything about the contents of
> > "psk_key_exchange_modes" in this case?  (I see we do say something later
> > on in Section 5, so maybe not here.  But see also the note about
> > duplication of normative requirements between Sections 4 and 5.)
> 
> I think the discussion in Section 5 covers this extension well.  RFC 8446 defines two values (psk_ke and psk_dhe_ke), and both are discussed in Section 5.
> 
> >   "pre_shared_key" extensions.  The "pre_shared_key" extension MUST be
> >   the last extension in the ClientHello message, and it provides a list
> >   of external PSK identifiers that the client is willing to use with
> >   this server.  [...]
> > 
> > I think that the last paragraph of
> > https://tools.ietf.org/html/rfc8446#section-4.2.11 is quite clear that
> > "pre_shared_key" must be the last extension, and we don't need to have
> > new normative language to require it.
> 
> Okay.  I'd like to preserve the reminder that the "pre_shared_key" extension needs to come at the end.  I suggest:
> 
>    The client includes the "tls_cert_with_extern_psk" extension in the
>    ClientHello message.  The "tls_cert_with_extern_psk" extension MUST
>    be accompanied by the "key_share", "psk_key_exchange_modes", and
>    "pre_shared_key" extensions.  The client MAY also find it useful to
>    include the "supported_groups" extension.  Since the
>    "tls_cert_with_extern_psk" extension is intended to be used only with
>    initial handshakes, it MUST NOT be sent alongside the "early_data"
>    extension.  These extensions are all described in Section 4.2 of
>    [RFC8446], which also requires the "pre_shared_key" extension to be
>    the last extension in the ClientHello message.

Thanks.

> >   The successful negotiation of the "tls_cert_with_extern_psk"
> >   extension requires the TLS 1.3 key schedule processing to include
> >   both the selected external PSK and the (EC)DHE shared secret value.
> > 
> > grammar pedant alert: I believe that this construction is parsed such
> > that inclusion of (both external PSK and ECDHE shared secret) in the key
> > schedule is a prerequisite for successful negotiation, whereas the
> > intent is that successful negotiation implies the key schedule change.
> > One plausible "fix" (if any is indeed desired) would be "After
> > successful negotiation [...], it is required to adopt the TLS 1.3 key
> > schedule [...]", but there are probably better ones.
> 
> I think this is an improvement:
> 
>    When the "tls_cert_with_extern_psk" extension is successfully
>    negotiated, the TLS 1.3 key schedule processing includes both the
>    selected external PSK and the (EC)DHE shared secret value.  As a
>    result, the Early Secret, Handshake Secret, and Master Secret values
>    all depend upon the value of the selected external PSK.

Thanks, I agree that it is an improvement.

> >   As a result, the Early Secret, Handshake Secret, and Master Secret
> >   values all depend upon the value of the selected external PSK.
> > 
> > (side note) Not that anyone here is likely to be confused, but the Early
> > Secret does not incorporate the (EC)DHE shared secret.  I don't really
> > see any reason to include a clarification about this, since the current
> > text isn't really implying that it does, but will mention it in case
> > anyone feels differently.
> 
> To make sure this is clear, I suggest and additional sentence to the above:
> 
>     Of course, the Early Secret does not depend upon
>     the (EC)DHE shared secret.

Thanks!

> >   Each external PSK is associated with a single hash algorithm, which
> >   is required by Section 4.2.11 of [RFC8446].  The hash algorithm MUST
> >   be set when the PSK is established, with a default of SHA-256 if no
> >   hash algorithm is specified during establishment.
> > 
> > This is likely to get flagged by the IESG -- it's a construction of the
> > form "MUST do X, but if you don't do X, assume Y" that inherently
> > assumes the MUST will not always be adhered to.
> 
> I think this says the same thing with a cleaner construction:
> 
>    Each external PSK is associated with a single hash algorithm, which
>    is required by Section 4.2.11 of [RFC8446].  The hash algorithm MUST
>    be set when the PSK is established, with a default of SHA-256.

I'm happy to go forward with it, but cannot guarantee it will pass IESG
review.

> > Section 5
> > 
> > Is there a useful way to group this content into sub-sections?
> 
> Yes. I have introduces subsections to talk about the companion extensions, authentication, and keying material.

Thanks.  I didn't get a chance to think very hard about what groupings
might make sense.

> >   appeared in the preceding ClientHello message.  If an implementation
> >   recognizes the "tls_cert_with_extern_psk" extension and receives it
> >   in any other message, then the implementation MUST abort the
> >   handshake with an "illegal_parameter" alert.
> > 
> > nit: "abort the handshake" is not quite right, since there are
> > Extensions blocks involved in post-handshake messages (NST,
> > CertificateRequest, etc.) which do not have a handshake to abort.  I
> > think "terminate the connection with a <foo> alert" is the preferred
> > construction for this situation.
> 
> Since the "tls_cert_with_extern_psk" extension MUST NOT appear in any message other than the ClientHello message and the ServerHello message, I think this is the correct construction.  For example, Section 4.1.1 of RFC 8446 says:
> 
>    ...  If there is no overlap between the received
>    "supported_groups" and the groups supported by the server, then the
>    server MUST abort the handshake with a "handshake_failure" or an
>    "insufficient_security" alert.

I think that's still talking about the server responding to a ClientHello.

To be clear, I only called it out because the current text begins with "any
other message", which is (to me, at least) calling out NewSessionTicket,
CertificateRequest, and friends.

> >   ClientHello message.  If the server responds with a HelloRetryRequest
> >   message, then the client sends another ClientHello message as
> >   described in Section 4.1.2 of [RFC8446], and it MUST include the same
> >   "tls_cert_with_extern_psk" extension as the original ClientHello
> >   message or abort the handshake.
> > 
> > (This is another MUST that duplicates an existing requirement from RFC
> > 8446.)
> 
> Okay.  Reworded to remove the MUST:
> 
>    ...  If the server responds with a HelloRetryRequest
>    message, then the client sends another ClientHello message as
>    described in Section 4.1.2 of [RFC8446], including the same
>    "tls_cert_with_extern_psk" extension as the original ClientHello
>    message or abort the handshake.

Thanks

> >   Many server extensions are carried in the EncryptedExtensions
> >   message; however, the "tls_cert_with_extern_psk" extension is carried
> >   in the ServerHello message.  It is only present in the ServerHello
> > 
> > I suggest adding a brief phrase noting that it's unfeasible to put this
> > extension in the EncryptedExtensions since it affects what key is used
> > to encrypt that message.
> 
> I suggest:
> 
>    Many server extensions are carried in the EncryptedExtensions
>    message; however, the "tls_cert_with_extern_psk" extension is carried
>    in the ServerHello message.  Successful negotiation of the
>    "tls_cert_with_extern_psk" extension affects the key used for
>    encryption, so it cannot be carried in the EncryptedExtensions
>    message.  Therefore, the "tls_cert_with_extern_psk" extension is only
>    present in the ServerHello message if the server recognizes the
>    "tls_cert_with_extern_psk" extension and the server possesses one of
>    the external PSKs offered by the client in the "pre_shared_key"
>    extension in the ClientHello message.

Thanks.  I might (but might not) s/Therefore/Accordingly/, since we don't
do much to present an argument about when/whether to have the server send
the extension, just which message it goes in when it is sent.

> >   To use an external PSK with certificates, clients MUST provide the
> >   "tls_cert_with_extern_psk" extension, and it MUST be accompanied by
> >   the "key_share", "psk_key_exchange_modes", and "pre_shared_key"
> >   extensions in the ClientHello.  If clients offer a
> >   "tls_cert_with_extern_psk" extension without all of these other
> >   extensions, servers MUST abort the handshake.  The client MAY also
> > 
> > This seems redundant with the requirements from Section 4; is the
> > repetition necessary?
> 
> I moved the one sentence that was not a repeat to Section 4 (as shown above).  With that done, the whole paragraph can be deleted.

Cool, thanks.

> >   find it useful to include the "supported_groups" extension.  Note
> >   that Section 4.2 of [RFC8446] allows extensions to appear in any
> >   order, with the exception of the "pre_shared_key" extension, which
> >   MUST be the last extension in the ClientHello.  Also, there MUST NOT
> >   be more than one instance of each extension in the ClientHello
> >   message.
> > 
> > I'd prefer to either use direct quotations from RFC 8446 or descriptive
> > versions of the requirements (without normative keywords).
> 
> Okay.  This one was deleted.
> 
> >   might supply via a subsequent NewSessionTicket.  As a result, clients
> >   MUST include the psk_dhe_ke mode, and clients MAY also include the
> >   psk_ke mode to support a subsequent NewSessionTicket.  Servers MUST
> >   select the psk_dhe_ke mode for the initial handshake.  Servers MUST
> >   select a key exchange mode that is listed by the client for
> >   subsequent handshakes that include the resumption PSK from the
> >   initial handshake.
> > 
> > I suppose it's probably implicit that "MUST select the psk_dhe_ke mode"
> > is contingent on negotiating "tls_cert_with_extern_psk", but maybe
> > there's not any harm in making it explicit as well.
> 
> I suggest:
> 
>    The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of
>    [RFC8446].  The "psk_key_exchange_modes" extension restricts both the
>    use of PSKs offered in this ClientHello and those which the server
>    might supply via a subsequent NewSessionTicket.  As a result, when
>    the "psk_key_exchange_modes" extension is included in the ClientHello
>    message, clients MUST include psk_dhe_ke mode.  In addition, clients

nit: "the psk_dhe_ke mode"

>    MAY also include psk_ke mode to support a subsequent

nit: missing "the" again

>    NewSessionTicket.  When the "psk_key_exchange_modes" extension is
>    included in the ServerHello message, servers MUST select the
>    psk_dhe_ke mode for the initial handshake.  Servers MUST select a key
>    exchange mode that is listed by the client for subsequent handshakes
>    that include the resumption PSK from the initial handshake.

but I appreciate the addition; thanks!

> >   The "pre_shared_key" extension is defined in Section 4.2.11 of
> >   [RFC8446].  The syntax is repeated below for convenience.  All of the
> >   listed PSKs MUST be external PSKs.
> > 
> > Should we specify that the server must abort the handshake if it detects
> > a resumption PSK present in a ClientHello that contains
> > "tls_cert_with_extern_psk"?  (What alert would be best in that case?)
> 
> I suggest:
> 
>    The "pre_shared_key" extension is defined in Section 4.2.11 of
>    [RFC8446].  The syntax is repeated below for convenience.  All of the
>    listed PSKs MUST be external PSKs.  If a resumption PSK is listed
>    along with the "tls_cert_with_extern_psk" extension, the server MUST
>    abort the handshake with an "illegal_parameter" alert.

Works for me.

> >   The obfuscated_ticket_age is not used for external PSKs; clients
> >   SHOULD set this value to 0, and servers MUST ignore the value.
> > 
> > (These are the same requirements from RFC 8446, though it's probably
> > reasonable to repeat them here to confirm that they apply.)
> 
> To be clear that these are not new requirements:
> 
>    The obfuscated_ticket_age is not used for external PSKs.  As stated
>    in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0,
>    and servers MUST ignore the value.

Thanks.

> >   The selected_identity contains the external PSK identity that the
> >   server selected from the list offered by the client.  If none of the
> > 
> > nit: it's the index of the identity, though it's unclear to what length
> > we need to cover that in this document, since RFC 8446 is pretty clear
> > and available to the reader in case of confusion.
> 
> I think that some context is useful, but I suggest getting rid of some text:
> 
>    The selected_identity contains the index of the external PSK identity
>    that the server selected from the list offered by the client.  As
>    described in Section 4.2.11.2 of [RFC8446], the server MUST validate
>    the binder value that corresponds to the selected external PSK, and
>    if the binder does not validate, the server MUST abort the handshake
>    with an "illegal_parameter" alert.

Looks good.

> > 
> >                                                            The server
> >   MUST validate the binder value that corresponds to the selected
> >   external PSK as described in Section 4.2.11.2 of [RFC8446].  If the
> >   binder does not validate, the server MUST abort the handshake with an
> >   "illegal_parameter" alert.  Servers SHOULD NOT attempt to validate
> >   multiple binders; rather they SHOULD select one of the offered
> >   external PSKs and validate only the binder that corresponds to that
> >   external PSK.
> > 
> > (This chunk also has pretty high overlap with existing RFC 8446
> > requirements.)
> 
> Agreed, and I proposed to reduce the repeated text above.
> 
> >   TLS 1.3 does not permit the server to send a CertificateRequest
> >   message when a PSK is being used.  This restriction is removed when
> >   the "tls_cert_with_extern_psk" extension is negotiated, allowing
> >   certificate-based authentication for both the client and the server.
> > 
> > We might get some questions about whether this weakening of an RFC 8446
> > requirement requires an "Updates:" relationship (problematic given this
> > document is targetting Experimental status), but I don't think it's
> > necessary.  (That text is relevant when the server is authenticating
> > solely with a PSK, which is not the case here.)
> 
> I would argue that it is not a "weakening" for exactly this reason.  The TLS WG wanted to move forward with an Experimental RFC, so I assume that it cannot update RFC 8446.

Agreed.

> >   Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule.  The
> >   successful negotiation of the "tls_cert_with_extern_psk" extension
> >   requires the key schedule processing to include both the external PSK
> >   and the (EC)DHE shared secret value.
> > 
> > Do we want to say "into the PSK and (EC)DHE inputs, respectively"?  It
> > seems almost banal to do so, so maybe not...
> 
> There are only two variable inputs, and then text says to "include both", so I am not sure how "respectively" adds clarity.
> 
> >   If the client and the server have different values associated with
> >   the selected external PSK identifier, then the client and the server
> >   will compute different values for every entry in the key schedule,
> >   which will lead to the termination of the connection with a
> >   "decrypt_error" alert.
> > 
> > (side note) this is a case where "abort the handshake" would be
> > appropriate, though the verb tense into which we have to fit probably
> > makes the current wording better :)
> 
> I suggest:
> 
>    If the client and the server have different values associated with
>    the selected external PSK identifier, then the client and the server
>    will compute different values for every entry in the key schedule,
>    which will lead to the client aborting the handshake with a
>    "decrypt_error" alert.

Excellent, thanks.

> > Section 6
> > 
> > We also should probably say that it gets the "Recommended" value "N"
> > (not that we have any choice about it) and [this document] is the
> > reference.
> 
> I suggest:
> 
>    IANA is requested to update the TLS ExtensionType Registry to include
>    "tls_cert_with_extern_psk" with a value of TBD and the list of
>    messages "CH, SH" in which the "tls_cert_with_extern_psk" extension
>    may appear.

I think you copied the OLD text and not the NEW, but am confident that your
NEW is something reasonable.

> >   Implementations must protect the external pre-shared key (PSK).
> >   Compromise of the external PSK will make the encrypted session
> >   content vulnerable to the future invention of a large-scale quantum
> >   computer.
> > 
> > ("invention" and "large-scale quantum computer" again, if we end up
> > making a pass to change either of those)
> 
> I changed it to "development" as above.
> 
> >   Implementers should not transmit the same content on a connection
> >   that is protected with an external PSK and a connection that is not.
> >   Doing so may allow an eavesdropper to correlate the connections,
> >   making the content vulnerable to the future invention of a large-
> >   scale quantum computer.
> > 
> > I think I'm missing a step here.  While it's clear that if the same
> > content is sent on two connections, and the attacker can correlate the
> > connections so as to know that fact, then the PSK-less connection can be
> > attacked with the quantum computer and thus reveal the contents of the
> > PSK-protected connection, I'm not sure how just having the same content
> > on the two connection allows the eavesdropper to correlate the
> > connections.  Or is this just a more generic risk (e.g., timing/size
> > analysis) that's not particularly enabled by the external PSK
> > (non-)usage?
> 
> The point is more straightforward than the correlation.  if the content requires protection from the future development of a large-scale quantum computer, then sending it on a connection with external PSK protection and one without external PSK protection leave the content vulnerable.

If that's all you want to say, then why mention correlation at all?
(I assumed the correlation was needed so as to be able to attack the
nominally-PSK-protected connection.)

> >   If the external PSK is known to any party other than the client and
> >   the server, then the external PSK MUST NOT be the sole basis for
> >   authentication.  The reasoning is explained in [K2016] (see
> >   Section 4.2).  When this extension is used, authentication is based
> >   on certificates, not the external PSK.
> > 
> > Are we talking about [K2016] as https://eprint.iacr.org/2016/711.pdf ?
> > I failed to find anything in Section 4.2 that considers the case when
> > the PSK is shared between more parties than just C and S.
> 
> Yes.  Footnote 6 says it, but you need a lot of context from earlier in the paper to get the full consequences of that short statement.
> 
> If you are aware of another reference that explains the situation, I'll be glad to take a look.

Ah, I failed to read (or even notice?) the footnote.
I don't know of a particular reference, though the result does seem rather
intuitive.

> >   1.2 PRF.  Thus, the safest approach is to use a PSK with either TLS
> >   1.2 or TLS 1.3.  However, any PSK that might be used with both TLS
> >   1.2 and TLS 1.3 must be used with only one hash function, which is
> >   the one that is bound for use in TLS 1.3.  This restriction is less
> > 
> > nit(?): I suggest rewording "use a PSK with either TLS 1.2 or TLS 1.3",
> > as the current wording can be confusing as to the exclusive nature of
> > the "or", perhaps to "the safest approach is to use any given PSK with
> > at most one of TLS 1.2 and TLS 1.3".
> 
> I suggest:
> 
>    ... Thus, the safest approach is to use a PSK exclusively with
>    TLS 1.2 or exclusively with TLS 1.3.  ...

Works for me.

> > What is the origin of the "only one hash function" requirement?
> 
> Section 4.2.11 of RFC 8446 says:
> 
>    Each PSK is associated with a single Hash algorithm.  For PSKs
>    established via the ticket mechanism (Section 4.6.1), this is the KDF
>    Hash algorithm on the connection where the ticket was established.
>    For externally established PSKs, the Hash algorithm MUST be set when
>    the PSK is established or default to SHA-256 if no such algorithm is
>    defined.  The server MUST ensure that it selects a compatible PSK
>    (if any) and cipher suite.
> 
> {{Note the wording that you expect the IESG to complain about.}}

((It's easy to miss things when they're buried in 100-page documents.  Tiny
ones are easier to nitpick.))

> > (Appendix E.7 of RFC 8446 only has this limitation apply to the TLS 1.3
> > usage, not the TLS 1.2 usage.)
> 
> Observe that draft-ietf-tls-external-psk-importer is a way to handle this situation.  Given a PSK, one can derive another PSK for use with TLS 1.2 and a different one for use with TLS 1.3.

I agree that there are lots of reasonable-ish ways to handle the situation,
including draft-ietf-tls-external-psk-importer.
I think what I'm really trying to get at is whether this
(version-agnonstic) "must be used with only one hash function" requirement
is coming from some other preexisting document (in which case a reference
thereto seems in order), or whether (the TLS 1.2 part of) it is new to this
document (in which case we might say something about why).

> >   than optimal when users want to provision a single PSK.  While the
> >   constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC
> >   [RFC2104], the constructions are different, and there is no known way
> >   in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would
> >   produce related outputs.
> > 
> > (This also has pretty high overlap with Appendix E.7 of RFC 8446; do we
> > need to inline it all as opposed to incorporating by reference?)
> 
> I agree, and now that draft-ietf-tls-external-psk-importer is available, I can suggest a way to handle the situation instead of just warning about it:
> 
>    TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are
>    bound to a specific hash function and KDF.  By contrast, TLS 1.2
>    [RFC5246] allows PSKs to be used with any hash function and the TLS
>    1.2 PRF.  Thus, the safest approach is to use a PSK exclusively with
>    TLS 1.2 or exclusively with TLS 1.3.  Given one PSK, one can derive a
>    PSK for exclusive use with TLS 1.2 and derive another PSK for
>    exclusive use with TLS 1.3 using the mechanism specified in
>    [I-D.ietf-tls-external-psk-importer].

Of course, there's always the third path of removing the need to answer the
question at all, which in this case sounds like a fine thing to do :)

Thanks,

Ben