Re: [Acme] nomenclature: “POST-as-GET”
On Wed, Sep 5, 2018 at 4:33 AM Richard Barnes wrote: >> Alternatively, would it make sense to define a new HTTP verb, e.g., “FETCH”, >> for this? > > I'm inclined not to do this. We definitely shouldn't actually mint a new > HTTP method, since we're not changing the method. One does not merely define a new verb. The limited set of verbs in HTTP is a feature, not a bug. That means occasionally using POST in ways that are suboptimal, but the alternative is struggling with an unrecognized verb. There is a proposal to add something with similar semantics to what you describe, in SEARCH [1], but that has not been successful and it's been a long time. Don't kill ACME on this mountain. Use POST and learn to like it. (Arguably, header fields are the way to deal with this class of problem, but then we're into request signing territory and ACME decided a long time ago not to tilt at that particular windmill.) [1] https://tools.ietf.org/html/draft-snell-search-method-00 - which died only partly because it conflicted with RFC 5323... ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] POST-as-GET payload contents
I like using {} for the POST-as-GET payload as well.
Sincerely,
Logan Widick
On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews wrote:
> New day, new thread for a specific issue I'd like to nail down quickly.
>
> > ISSUE 2: How should we signal that POST-as-GET request is different
> > from other POST requests?
> >
> > The current PR signals this by sending a JWS with an empty
> > (zero-octet) payload, instead of a JSON object. Jacob and Daniel
> > suggested that we should instead use the payload being an empty JSON
> > object as the signal. An earlier draft PR used a field in the
> > protected header.
>
> In short, this question is about whether POST-as-GETs should have:
>
> "payload": ""
>
> or
>
> "payload": "{}"
>
>
> When implementing the first one (empty payload), Daniel and I each
> separately implemented a different bug that would have also accepted:
>
> "payload": null
>
> This may be quirk of Go's handling of byte arrays, but it may turn out
> to be a common pattern in JSON libraries. The downside, if a server
> implementer landed a bug like that, would be that clients might get away
> with generating the invalid "null" form, leading to interoperability
> problems.
>
> There's also potential for client bugs that produce an empty payload
> simply due to an uninitialized field, rather than due to a POST-as-GET.
> This would produce confusing errors relating to GETs rather than a
> clearer "malformed input" error.
>
> Lastly, many clients already implement the "{}" form as a way to GET an
> account, so expanding the use of "{}" minimizes disruption.
>
> My preference is still for "{}" over "", but I am also willing to be
> convinced in the interests of landing this change speedily and keeping
> forward momentum.
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] nomenclature: “POST-as-GET”
On Tue, Sep 4, 2018 at 1:44 PM Felipe Gasper wrote: > FWIW, it seems to me like, if the HTTP verb being used is, in fact, > “POST”, then a more appropriate term for the proposed fix for the identity > correlation problem identified last week would be “GET-as-POST” rather than > “POST-as-GET”. > > “POST-as-GET” sounds to me like the actual HTTP verb is a GET, but we’re > shoehorning what would normally be a POST over that request. The opposite, > of course, is what is proposed: a POST with an uninteresting payload is > being sent to simulate a GET but with the authentication of a POST. The > pattern of a GET is being sent “as a POST”. > I would be fine either way. It really just depends on which implicit verb you read with the "as" -- "POST-acting-as-GET" or "GET-sent-as-POST". I would prefer not to actually include the verb, just because that gets wordy.. > Alternatively, would it make sense to define a new HTTP verb, e.g., > “FETCH”, for this? > I'm inclined not to do this. We definitely shouldn't actually mint a new HTTP method, since we're not changing the method. As a corollary, we shouldn't write it in all caps (so "Fetch" or "fEtcH" or something). Also, while "fetch" is the obvious verb, it collides with the HTML5 JS API of that name, which supports all methods. --Richard > > -FG > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] nomenclature: “POST-as-GET”
FWIW, it seems to me like, if the HTTP verb being used is, in fact, “POST”, then a more appropriate term for the proposed fix for the identity correlation problem identified last week would be “GET-as-POST” rather than “POST-as-GET”. “POST-as-GET” sounds to me like the actual HTTP verb is a GET, but we’re shoehorning what would normally be a POST over that request. The opposite, of course, is what is proposed: a POST with an uninteresting payload is being sent to simulate a GET but with the authentication of a POST. The pattern of a GET is being sent “as a POST”. Alternatively, would it make sense to define a new HTTP verb, e.g., “FETCH”, for this? -FG ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] ACME breaking change: Most GETs become POSTs
On 08/31/2018 03:08 PM, Richard Barnes wrote: ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing the privacy analysis? Agreed we're solved on this. ISSUE 2: How should we signal that POST-as-GET request is different from other POST requests? Started a separate thread on this. ISSUE 3: Should servers be required to allow GET requests for certificate URLs? I'm not convinced this is absolutely necessary for the STAR use case, and I'm still not thrilled about carving out exceptions, but I'm okay leaving this as a MAY GET in the interests of landing the change. ISSUE 4: How should we address the risk that an attacker can discover URLs by probing for Unauthorized vs. Not Found? There seemed to be agreement on the list that this should be addressed with some guidance to servers on how to assign URLs. I have just added some text to the PR for this. This seems like a good plan to me. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] POST-as-GET payload contents
New day, new thread for a specific issue I'd like to nail down quickly.
ISSUE 2: How should we signal that POST-as-GET request is different
from other POST requests?
The current PR signals this by sending a JWS with an empty
(zero-octet) payload, instead of a JSON object. Jacob and Daniel
suggested that we should instead use the payload being an empty JSON
object as the signal. An earlier draft PR used a field in the
protected header.
In short, this question is about whether POST-as-GETs should have:
"payload": ""
or
"payload": "{}"
When implementing the first one (empty payload), Daniel and I each
separately implemented a different bug that would have also accepted:
"payload": null
This may be quirk of Go's handling of byte arrays, but it may turn out
to be a common pattern in JSON libraries. The downside, if a server
implementer landed a bug like that, would be that clients might get away
with generating the invalid "null" form, leading to interoperability
problems.
There's also potential for client bugs that produce an empty payload
simply due to an uninitialized field, rather than due to a POST-as-GET.
This would produce confusing errors relating to GETs rather than a
clearer "malformed input" error.
Lastly, many clients already implement the "{}" form as a way to GET an
account, so expanding the use of "{}" minimizes disruption.
My preference is still for "{}" over "", but I am also willing to be
convinced in the interests of landing this change speedily and keeping
forward momentum.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt
Hi Alexey, > > SMTP does allow choosing an arbitrary "From:" address, so just being able > > to send an email with a specific "From:" address alone doesn't prove > > anything. > This is true, the document needs to add some text about some form of > validation. Possibly DKIM/DMARC. fair enough. > > Couldn't the token just be transmitted back to the CA via HTTPS like the > > rest of the ACME protocol? > > As per above, I think this is not good enough. But wouldn't that create two different levels of validation? Let's consider user Alice. She, or her domain admin, has set up DNSSEC, DKIM, SPF and DMARC. When she does the email-reply-00 challenge, mail reception and sending is proven properly. But user Bob has none of that, just a basic domain with one A record, no DNSSEC and nothing else. When he does the email-reply-00 challenge, essentially just mail reception is proven, as sending could be forged without issue. The CA would hand out the same kind of certificates to both of them and a third party won't know which level of validation was done. Querying the dns data of Bob won't help, because he could have changed it after the certificate was issued. Is a CA like Let's Encrypt ok with such a difference? Or do you want to make the use of DKIM and DMARC mandatory for a user before he can use the email-reply-00 challenge? > DKIM/DMARC already deal with some of this, so I think they should be > encouraged in this context. (They are easy to handle in MTAs, as more > support is available). > > Supporting S/MIME might be a reasonable alternative as well. I'm ok with both of these mechanisms, they would both solve the issue. I just think if we allow a CA to send S/MIME, there should be something like "a client MUST support decoding MIME emails" in the RFC so that there is no surprise if a CA suddenly starts using it. Kind regards, Gerd ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt
Hi Gerd, Thank you for your comments! On 04/09/2018 13:36, Gerd v. Egidy wrote: Hi Alexey, thanks for working on the "email-reply-00" challenge. I would very much welcome a good mechanism to automatically distribute certificates for use with S/MIME. I have two questions / suggestions to your proposal: 3.2. ACME response email - You suggest to send the challenge response via email. What is the reason for choosing email as medium for this? Because we need some way to prove control over the email address. This means both being able to read emails addressed to it and also being able to send on behalf of the email address. SMTP does allow choosing an arbitrary "From:" address, so just being able to send an email with a specific "From:" address alone doesn't prove anything. This is true, the document needs to add some text about some form of validation. Possibly DKIM/DMARC. I am still thinking about this, so maybe better mechanisms are available. But sending an email does require specific setup on the client side (like smtp relay server, port, login,...) which makes it harder to use an ACME client program that is not fully integrated into an email program. Couldn't the token just be transmitted back to the CA via HTTPS like the rest of the ACME protocol? As per above, I think this is not good enough. Challenge email and mail filtering - If "email-reply-00" becomes popular (I'm hoping it will), it will most probably attract scammers which will try to trick users into giving away passwords and so on. As the challenge email mostly contains a random token, it is not easy for mail filtering gateways to filter out scam emails and let legitimate challenge emails through. I think we should design the protocol in a way that makes it easy for mail filtering gateways to do the right thing: 1. Every CA should publish (on their webpage or in a specification document) a static "From:" address they use when sending their challenges. This could be used by gateways for whitelisting purposes. 2. As simple whitelisting without further checks isn't a good idea, the authenticity of the challenge email should be verifiable by the filtering gateway. I propose that the CA should sign all challenge emails with S/MIME to do this. As most email programs already automatically check S/MIME signatures, this would also allow users of manual acme client programs to verify the authenticity of the challenge email. DKIM/DMARC already deal with some of this, so I think they should be encouraged in this context. (They are easy to handle in MTAs, as more support is available). Supporting S/MIME might be a reasonable alternative as well. What do you think? I am a bit torn between requiring one, the other or even allowing both. More feedback from the WG would be useful. Best Regards, Alexey ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt
Hi Sebastian, > I think SPF / DKIM is more of a suitable method of verifying authenticity > for mails, since these can be verifyed automatically by most email server > software without any plugins. For servers yes, but for email clients the opposite is true. Most clients already automatically verify S/MIME. DKIM could be done in the client but SPF is particularly hard to do in a client. > Ergo, a CA **MUST** support SPF as validation method [...] > And a CA **MAY** also support DKIM Why this strong preference for SPF over DKIM? SPF isn't compatible with regular email forwarding and thus creates a lot of problems. See for example https://blog.fastmail.com/2016/12/24/spf-dkim-dmarc/ for details. I recommend my customers to only use DKIM and not use SPF at all because of this. > and/or SMIME as validation method both > for sending I think the main point here is if we want to force clients to support full MIME decoding including S/MIME or not. Making this decision a MAY isn't good practice, as an ACME client without a full MIME parser will just stop to work once the CA decides to activate S/MIME. Also mail filtering gateways then can't rely on the kind of signing a CA does on the challenge mails. > For gateway filtering, I suggest that a couple of static adresses is > reserved for this purpose: > acme @ [ca_domain_name].[tld] yes, good idea. Kind regards, Gerd ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt
I think SPF / DKIM is more of a suitable method of verifying authenticity for mails, since these can be verifyed automatically by most email server software without any plugins. Ergo, a CA **MUST** support SPF as validation method, both for sending and receiving, and a ~ MUST be treated same as -, ergo hardfail. (Unknown should however be treated same as non-existant record and then it should fallback on DKIM and then SMIME) And a CA **MAY** also support DKIM and/or SMIME as validation method both for sending and receiving. This solves both 3.2 and challenge emails. If the CA validate SPF/DKIM/SMIME, you can't forge the From: adress. You could also have that the CA sends a challenge email to the email in question, but this requires rate limiting both on user @ domain.tld part, and also per domain (* @ domain.tld) to prevent becoming a spam problem. For gateway filtering, I suggest that a couple of static adresses is reserved for this purpose: acme @ [ca_domain_name].[tld] abuse @ [ca_domain_name].[tld] postmaster @ [ca_domain_name].[tld] This allows gateway filters to automatically support any CA without any extra configuration required on the administrator's end. -Ursprungligt meddelande- Från: Acme För Gerd v. Egidy Skickat: den 4 september 2018 14:46 Till: acme@ietf.org; Alexey Melnikov Ämne: Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt Hi Alexey, thanks for working on the "email-reply-00" challenge. I would very much welcome a good mechanism to automatically distribute certificates for use with S/MIME. I have two questions / suggestions to your proposal: 3.2. ACME response email - You suggest to send the challenge response via email. What is the reason for choosing email as medium for this? SMTP does allow choosing an arbitrary "From:" address, so just being able to send an email with a specific "From:" address alone doesn't prove anything. But sending an email does require specific setup on the client side (like smtp relay server, port, login,...) which makes it harder to use an ACME client program that is not fully integrated into an email program. Couldn't the token just be transmitted back to the CA via HTTPS like the rest of the ACME protocol? Challenge email and mail filtering - If "email-reply-00" becomes popular (I'm hoping it will), it will most probably attract scammers which will try to trick users into giving away passwords and so on. As the challenge email mostly contains a random token, it is not easy for mail filtering gateways to filter out scam emails and let legitimate challenge emails through. I think we should design the protocol in a way that makes it easy for mail filtering gateways to do the right thing: 1. Every CA should publish (on their webpage or in a specification document) a static "From:" address they use when sending their challenges. This could be used by gateways for whitelisting purposes. 2. As simple whitelisting without further checks isn't a good idea, the authenticity of the challenge email should be verifiable by the filtering gateway. I propose that the CA should sign all challenge emails with S/MIME to do this. As most email programs already automatically check S/MIME signatures, this would also allow users of manual acme client programs to verify the authenticity of the challenge email. What do you think? Kind regards, Gerd ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme smime.p7s Description: S/MIME Cryptographic Signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-email-smime-03.txt
Hi Alexey, thanks for working on the "email-reply-00" challenge. I would very much welcome a good mechanism to automatically distribute certificates for use with S/MIME. I have two questions / suggestions to your proposal: 3.2. ACME response email - You suggest to send the challenge response via email. What is the reason for choosing email as medium for this? SMTP does allow choosing an arbitrary "From:" address, so just being able to send an email with a specific "From:" address alone doesn't prove anything. But sending an email does require specific setup on the client side (like smtp relay server, port, login,...) which makes it harder to use an ACME client program that is not fully integrated into an email program. Couldn't the token just be transmitted back to the CA via HTTPS like the rest of the ACME protocol? Challenge email and mail filtering - If "email-reply-00" becomes popular (I'm hoping it will), it will most probably attract scammers which will try to trick users into giving away passwords and so on. As the challenge email mostly contains a random token, it is not easy for mail filtering gateways to filter out scam emails and let legitimate challenge emails through. I think we should design the protocol in a way that makes it easy for mail filtering gateways to do the right thing: 1. Every CA should publish (on their webpage or in a specification document) a static "From:" address they use when sending their challenges. This could be used by gateways for whitelisting purposes. 2. As simple whitelisting without further checks isn't a good idea, the authenticity of the challenge email should be verifiable by the filtering gateway. I propose that the CA should sign all challenge emails with S/MIME to do this. As most email programs already automatically check S/MIME signatures, this would also allow users of manual acme client programs to verify the authenticity of the challenge email. What do you think? Kind regards, Gerd ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
