Re: [Acme] ACME Operational best practices

[Jacob Hoffman-Andrews]

On 07/14/2018 04:38 PM, Tobias Fiebig wrote:

Back when we submitted Cloud Strife [0] to NDSS, we reached out to the list on 
pushing our mitigations toward a recommendation/best practices RFC. Given that 
with the Birge-Lee paper, there is now a second attack vector, we (Kevin 
Borgolte and I, but we are open to more collaborators and already talked with 
Prateek Mittal from the BGP MitM paper [1]) would like to author a RFC on 
mitigating IP-use-after-free/IP-misuse attacks. This RFC would summarize the 
operational recommendations as well as how various other measures can (and 
cannot, CAA for example has to be configured correctly to be helpful) mitigate 
these attacks.
The main question here is opt-in vs not. Practical deployment experience 
with ACME has shown that people frequently lose all their private keys. 
For instance, they might need to rebuild a server, and forget to store a 
copy. If a mechanism like you propose were to be enabled by default for 
all hostnames, it would effectively lock out a large number of 
subscribers from being able to get a certificate at all.


Making this opt-in is more plausible. You could do this with 
CAA.However, it might make more sense to just apply a CAA accounturi 
parameter in that case.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] I-D Action: draft-ietf-acme-acme-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : Automatic Certificate Management Environment (ACME)
Authors : Richard Barnes
  Jacob Hoffman-Andrews
  Daniel McCarney
  James Kasten
Filename: draft-ietf-acme-acme-13.txt
Pages   : 86
Date: 2018-07-17

Abstract:
   Certificates in PKI using X.509 (PKIX) are used for a number of
   purposes, the most significant of which is the authentication of
   domain names.  Thus, certificate authorities in the Web PKI are
   trusted to verify that an applicant for a certificate legitimately
   represents the domain name(s) in the certificate.  Today, this
   verification is done through a collection of ad hoc mechanisms.  This
   document describes a protocol that a certification authority (CA) and
   an applicant can use to automate the process of verification and
   certificate issuance.  The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
   this draft is maintained in GitHub.  Suggested changes should be
   submitted as pull requests at https://github.com/ietf-wg-acme/acme
   [1].  Instructions are on that page as well.  Editorial changes can
   be managed in GitHub, but any substantive change should be discussed
   on the ACME mailing list (acme@ietf.org).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-acme-13
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

At IETF102 we had extremely strong consensus to merge this, to address the last 
open AD review comment.

As Richard said, if you have concerns or objections, please speak up NOW.

/rich, co-chair

From: Richard Barnes 
Date: Tuesday, July 17, 2018 at 6:00 PM
To: "c...@letsencrypt.org" 
Cc: Rich Salz , Eric Rescorla , 
"acme@ietf.org" , Russ Housley 
Subject: Re: [Acme] AD Review: draft-ietf-acme-acme-12

... and based on feedback at the meeting, I went ahead and merged this.  I 
understand that EKR will be issuing an IETF last call soon, so if you have 
concerns about this change, please raise them there.  Or on this thread, but in 
any case, ASAP.

Thanks,
--Richard

On Tue, Jul 17, 2018 at 4:27 PM Richard Barnes  wrote:
I went ahead and posted a PR implementing EKR's suggestion:

https://github.com/ietf-wg-acme/acme/pull/429


On Wed, May 30, 2018 at 4:23 PM Daniel McCarney 
mailto:c...@letsencrypt.org>> wrote:
We have multiple CA’s that support it, and other implementations as well.

Of the multiple CAs that support ACME, which support something resembling the 
current draft? When I looked last the non-Let's Encrypt ACME server 
implementations all seemed to be targeting Certbot and the "ACMEv1" era of this 
draft (e.g. are not using the order based issuance flow at all). There have 
been substantial backwards compatibility breaking changes in the draft since 
this time.

I second EKR's sentiment that there has been little true ACME inter-op testing 
of the protocol as described in draft-12 outside of that done with Let's 
Encrypts ACMEv2 endpoint.

- Daniel / cpu

On Wed, May 30, 2018 at 3:56 PM, Salz, Rich 
mailto:rsalz=40akamai@dmarc.ietf.org>> 
wrote:

  *   Well, we have a fair bit of experience of a lot of people talking to 
Let's Encrypt. That's not really the same as a lot of servers and a lot of 
clients.

We have multiple CA’s that support it, and other implementations as well.  
Certainly LE dominates, but it’s not the only usage.  And certainly not the 
only anticipated future usage.


  *   I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with 
X25519.

That would make the MTI limited to a subset of the WebPKI supported by the 
latest browsers, which seems wrong.  But let’s not bikeshed too much and see 
what the WG consensus is.


___
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] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

 and based on feedback at the meeting, I went ahead and merged this.  I
understand that EKR will be issuing an IETF last call soon, so if you have
concerns about this change, please raise them there.  Or on this thread,
but in any case, ASAP.

Thanks,
--Richard

On Tue, Jul 17, 2018 at 4:27 PM Richard Barnes  wrote:

> I went ahead and posted a PR implementing EKR's suggestion:
>
> https://github.com/ietf-wg-acme/acme/pull/429
>
>
> On Wed, May 30, 2018 at 4:23 PM Daniel McCarney 
> wrote:
>
>> We have multiple CA’s that support it, and other implementations as well.
>>
>>
>> Of the multiple CAs that support ACME, which support something resembling
>> the current draft? When I looked last the non-Let's Encrypt ACME server
>> implementations all seemed to be targeting Certbot and the "ACMEv1" era of
>> this draft (e.g. are not using the order based issuance flow at all). There
>> have been substantial backwards compatibility breaking changes in the draft
>> since this time.
>>
>> I second EKR's sentiment that there has been little true ACME inter-op
>> testing of the protocol as described in draft-12 outside of that done with
>> Let's Encrypts ACMEv2 endpoint.
>>
>> - Daniel / cpu
>>
>> On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
>> rsalz=40akamai@dmarc.ietf.org> wrote:
>>
>>>
>>>- Well, we have a fair bit of experience of a lot of people talking
>>>to Let's Encrypt. That's not really the same as a lot of servers and a 
>>> lot
>>>of clients.
>>>
>>>
>>>
>>> We have multiple CA’s that support it, and other implementations as
>>> well.  Certainly LE dominates, but it’s not the only usage.  And certainly
>>> not the only anticipated future usage.
>>>
>>>
>>>
>>>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA
>>>with X25519.
>>>
>>>
>>>
>>> That would make the MTI limited to a subset of the WebPKI supported by
>>> the latest browsers, which seems wrong.  But let’s not bikeshed too much
>>> and see what the WG consensus is.
>>>
>>>
>>>
>>> ___
>>> 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] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

I went ahead and posted a PR implementing EKR's suggestion:

https://github.com/ietf-wg-acme/acme/pull/429


On Wed, May 30, 2018 at 4:23 PM Daniel McCarney  wrote:

> We have multiple CA’s that support it, and other implementations as well.
>
>
> Of the multiple CAs that support ACME, which support something resembling
> the current draft? When I looked last the non-Let's Encrypt ACME server
> implementations all seemed to be targeting Certbot and the "ACMEv1" era of
> this draft (e.g. are not using the order based issuance flow at all). There
> have been substantial backwards compatibility breaking changes in the draft
> since this time.
>
> I second EKR's sentiment that there has been little true ACME inter-op
> testing of the protocol as described in draft-12 outside of that done with
> Let's Encrypts ACMEv2 endpoint.
>
> - Daniel / cpu
>
> On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
> rsalz=40akamai@dmarc.ietf.org> wrote:
>
>>
>>- Well, we have a fair bit of experience of a lot of people talking
>>to Let's Encrypt. That's not really the same as a lot of servers and a lot
>>of clients.
>>
>>
>>
>> We have multiple CA’s that support it, and other implementations as
>> well.  Certainly LE dominates, but it’s not the only usage.  And certainly
>> not the only anticipated future usage.
>>
>>
>>
>>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA
>>with X25519.
>>
>>
>>
>> That would make the MTI limited to a subset of the WebPKI supported by
>> the latest browsers, which seems wrong.  But let’s not bikeshed too much
>> and see what the WG consensus is.
>>
>>
>>
>> ___
>> 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] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Corey Bonnell]

Hi Ilari,
Unfortunately, the situation is even more grave than allowing 0-length 
whitespace delimiters, as section 3 and section 5.2 of RFC 6844 contradict each 
other in regard to the delimiter (section 3 specifies the parameter delimiter 
as a semicolon, whereas in section 5.2 it's "0 or more whitespace characters"). 
This was pointed out in erratum 5200 
(https://www.rfc-editor.org/errata/eid5200). These layers of brokenness lead me 
to believe that no one should be specifying multiple parameters in 
issue/issuewild records until these issues are corrected in 6844-bis, lest they 
might experience incompatibilities between CAA record handling implementations.

 Thanks,
Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com 

On 7/17/18, 11:38 AM, "Acme on behalf of Ilari Liusvaara" 
 wrote:


On Tue, Jul 17, 2018 at 01:25:51PM +, Salz, Rich wrote:
> Ilari,
> 
> That is a very impressive discussion of the issues, and examples.  Thank 
you very much!
> 
> So, what should the WG do with the CAA challenge document?

I think either:

- Change reference to RFC6844bis.
- Fix examples (and other text) to be consistent with the RFC6844
  grammar (which pretty obviously splits on space/tab according to
  the grammar).


-Ilari

___
Acme mailing list
Acme@ietf.org

https://scanmail.trustwave.com/?c=4062=_Y3O2yMmFUlzwyE4YBLSgZbkB1nVwb8L7Z2YF_UTJg=5=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Tim Hollebeek]

Yeah, I'm not particularly picky on the solution as long as we agree on a
solution
that works.  I believe that parameter usage is pretty rare in the wild right
now,
so I think we have time to come to a consensus about what the right behavior
is,
and document it via fixing examples or errata or whatever *before* the
problems
that Ilari rightly points out bite us in practice.

There is a precedent for putting approved errata directly into the BRs to
avoid
"diversity of interpretations", which generally causes problems.  I'd prefer
to
not have to be liberal on expectations, and indeed would support policy
proposal
at CABF to require rejection and non-issuance in the case of non-compliant
or
ambiguous CAA tags.  It's safer.

-Tim

> -Original Message-
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Salz, Rich
> Sent: Tuesday, July 17, 2018 11:39 AM
> To: Ilari Liusvaara 
> Cc: acme@ietf.org; Roland Shoemaker 
> Subject: Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for
> ACME-CAA discussion at 102)
> 
> >- Change reference to RFC6844bis.
> 
> A standards-track document cannot reference a draft.  So either we wait,
or'm 
> we wait for an errata to be written and accepted, or we do this:
> 
> >- Fix examples (and other text) to be consistent with the RFC6844
>   grammar (which pretty obviously splits on space/tab according to
>   the grammar).
> 
> We could also add text saying "be liberal in what you expect" as the
> community is migrating, I suppose.
> 
> ___
> 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] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Ilari Liusvaara]

On Tue, Jul 17, 2018 at 01:08:28PM +, Tim Hollebeek wrote:
> Yes, the RFC 6844 grammar is a mess, and it has significantly impeded
> efforts to improve CAA.  It's one of the things I think is most important to
> fix in 6844bis.

The main problem in my opinion with RFC6844 grammar is the examples
that contradict it. Yes, the grammar does have the problem that it is
ambiguous, but it seems that running into this problem is unlikely in
real world, as the inputs required are pretty odd.

In practicular, if someone tries to implment RFC6844 grammar:

- They handroll the parser. With high likehood, the parser picks the
  obvious meaning of the input (because it is far the simplest to
  implement the parser that way).
- They use parser generator, but accidentially misenter the grammar in
  a way that fixes the problem. With high likehood, this is also the
  obvious meaning (because it is the easiest to specify).
- They use parser generator and correctly enter the grammar. In this
  case, the parser generator would probably complain about the grammar
  (most parser generators do not handle general context-free grammars).
  If the buggy parser makes it into production, it will still handle
  most of the inputs seen in the real world.

> It is particularly troubling because CABF rules point to 6844, and some
> people have been sticklers about requiring very strict compliance with RFCs
> that are pointed to by the BRs.  For 6844, it's often very unclear what's
> compliant, as the document is often ambiguous, and contradicts itself and
> other well-known RFCs!
> 
> I'm a big fan of CAA (as long as it isn't used anti-competitively ...), but
> 6844 has been an endless source of headaches.  High quality analysis like
> Ilari's will go a long way towards helping us make 6844bis much better...

On the other hand, I find the existence of inputs that parse in both
RFC6844 and RFC6844bis but differently quite troublesome. Especially
given that these inputs are not necressarily rare in the real world.


Also, if someone uses RFC6844bis CAA records containing multiple
parameters with a CA that uses RFC6844 CAA records, that is likely
discovered fairly quickly as the misparsed parameters probably cause
things to blow up.

However, if someone uses RFC6844 CAA records with multiple parameters
with a CA that uses RFC6844bis CAA records and does not use parser
that treat unparseable records as unsatisfiable or have handrolled
parser that misparses the thing in a really whacky way, you have fail-
open situation on your hands.


I say that it would be nice if CAs treated issue records with
unknown parameters or parse errors as unsastisfiable (as this makes
errors much more likely to fail closed and fixed than to fail open
and lurk as security problems). I do not offhand know if this is
already required or not.



-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Salz, Rich]

>- Change reference to RFC6844bis.

A standards-track document cannot reference a draft.  So either we wait, or we 
wait for an errata to be written and accepted, or we do this:

>- Fix examples (and other text) to be consistent with the RFC6844
  grammar (which pretty obviously splits on space/tab according to
  the grammar).
  
We could also add text saying "be liberal in what you expect" as the community 
is migrating, I suppose.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Ilari Liusvaara]

On Tue, Jul 17, 2018 at 01:25:51PM +, Salz, Rich wrote:
> Ilari,
> 
> That is a very impressive discussion of the issues, and examples.  Thank you 
> very much!
> 
> So, what should the WG do with the CAA challenge document?

I think either:

- Change reference to RFC6844bis.
- Fix examples (and other text) to be consistent with the RFC6844
  grammar (which pretty obviously splits on space/tab according to
  the grammar).


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Tim Hollebeek]

My personal opinion is that the WG should try to come up with something that
makes sense and complies with the intent of 6844 and its examples, instead
of trying to be overly strict about complying with the current grammar as
written.

We can then file an errata and work with LAMPS to fix up the grammar to
unambiguously state what we want it to in 6844bis.

It's unfortunate to be in this position, but I think it's the only
reasonable path forward.

-Tim

> -Original Message-
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Salz, Rich
> Sent: Tuesday, July 17, 2018 9:26 AM
> To: Ilari Liusvaara ; Roland Shoemaker
> 
> Cc: acme@ietf.org
> Subject: Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for
> ACME-CAA discussion at 102)
> 
> Ilari,
> 
> That is a very impressive discussion of the issues, and examples.  Thank
you
> very much!
> 
> So, what should the WG do with the CAA challenge document?
> 
> 
> ___
> 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] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Salz, Rich]

Ilari,

That is a very impressive discussion of the issues, and examples.  Thank you 
very much!

So, what should the WG do with the CAA challenge document?
 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for ACME-CAA discussion at 102)

[Tim Hollebeek]

Yes, the RFC 6844 grammar is a mess, and it has significantly impeded
efforts to improve CAA.  It's one of the things I think is most important to
fix in 6844bis.

It is particularly troubling because CABF rules point to 6844, and some
people have been sticklers about requiring very strict compliance with RFCs
that are pointed to by the BRs.  For 6844, it's often very unclear what's
compliant, as the document is often ambiguous, and contradicts itself and
other well-known RFCs!

I'm a big fan of CAA (as long as it isn't used anti-competitively ...), but
6844 has been an endless source of headaches.  High quality analysis like
Ilari's will go a long way towards helping us make 6844bis much better...

-Tim

> -Original Message-
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ilari Liusvaara
> Sent: Tuesday, July 17, 2018 3:05 AM
> To: Roland Shoemaker 
> Cc: Salz, Rich ; acme@ietf.org
> Subject: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for
> ACME-CAA discussion at 102)
> 
> On Mon, Jul 16, 2018 at 08:08:24PM -0700, Roland Shoemaker wrote:
> > I know this is quite late but could we reserve some time for a
> > discussion of the (possible) pending issues with regard to the
> > parameter format mismatch between ACME-CAA and 6844 and possible
> > solutions.
> 
> I took a look at the issue:
> 
> The RFC 6844 grammar is ambiguous due to incorrect multiplicities.
> As far as I can see, there is no erratum for this.
> 
> As an example, consider the multiple-parameter example from the ACME-CAA
> document:
> 
> issue "example.net; accounturi=https://example.net/account/2345;
> validationmethods=http-01"
> 
> This has unique valid meanings for both RFC6844 and RFC6844bis grammars,
> but the two are different! Even taking additional constraint that
accounturi
> value is an uri is no help.
> 
> Now, under RFC6844bis rules, one can presumably rewrite this rule into:
> 
> issue
> "example.net;accounturi=https://example.net/account/2345;validationmetho
> ds=http-01"
> 
> The RFC6844bis parse is still the same, but now there are 18(!) possible
> meanings under RFC6844 rules. One of those is the same as the above.
> However, what I think is the most sensible way to fix the RFC6844 grammar
> gives different meaning from the first example (this can not alter the
first
> example, because there the meaning is unique already). And restriction to
URI
> does not help here either.
> 
> Another rewrite under RFC6844bis rules would be:
> 
> issue "example.net;accounturi=https://example.net/account/2345 ;
> validationmethods=http-01"
> 
> RFC6844bis parse is still the same, but RFC6844 rules would reject this as
> invalid.
> 
> 
> 
> RFC6844 and RFC6844bis grammars have all of:
> 
> - Strings that are valid in RFC6844 but not RFC6844bis.
> - Strings that are valid in RFC6844bis but not RFC6844.
> - Strings that have unique different meanings for RFC6844 and
>   RFC6844bis.
> - Strings that have unque meaning in RFC6844bis, but
>   multiple meanings in RFC6844, all different from the
>   unique meaning in RFC6844bis.
> 
> 
> If one fixes the RFC6844 grammar in most obvious way (by disallowing
> zero space between parameters, which is the source of ambiguous cases),
> then:
> 
> - Strings that are valid in RFC6844(fixed) but not RFC6844bis.
> - Strings that are valid in RFC6844bis but not RFC6844(fixed).
> - Strings that have unique different meanings for RFC6844(fixed) and
>   RFC6844bis.
> 
> Since the language is not changed by the fix, the last two cases
> with unfixed RFC6844 are collapsed into the last case.
> 
> 
> 
> -Ilari
> 
> ___
> 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] Time for ACME-CAA discussion at 102

[Roland Bracewell Shoemaker]

Great, thanks!

> On Jul 16, 2018, at 8:44 PM, Salz, Rich  wrote:
> 
> Yes, you can go right after the main acme doc
> 
> On 7/16/18, 11:08 PM, "Roland Shoemaker"  wrote:
> 
>I know this is quite late but could we reserve some time for a discussion 
> of the (possible) pending issues with regard to the parameter format mismatch 
> between ACME-CAA and 6844 and possible solutions.
> 
>Thanks!
>Roland
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme