Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

Toerless Eckert <tte@cs.fau.de> Sun, 28 June 2020 16:11 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7833A0D73 for <anima@ietfa.amsl.com>; Sun, 28 Jun 2020 09:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl7SUdTBZo-T for <anima@ietfa.amsl.com>; Sun, 28 Jun 2020 09:11:56 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861173A0D71 for <anima@ietf.org>; Sun, 28 Jun 2020 09:11:55 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BA3E4548011; Sun, 28 Jun 2020 18:11:49 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B0CA1440043; Sun, 28 Jun 2020 18:11:49 +0200 (CEST)
Date: Sun, 28 Jun 2020 18:11:49 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Russ Housley <housley@vigilsec.com>
Cc: Brian Carpenter <brian.e.carpenter@gmail.com>, Eric Vyncke <evyncke@cisco.com>, Eric Rescorla <ekr@rtfm.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>, Ben Kaduk <kaduk@mit.edu>, barryleiba@computer.org
Message-ID: <20200628161149.GA16571@faui48f.informatik.uni-erlangen.de>
References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <FF181E1F-2B93-47BB-AB45-7F66D880108B@vigilsec.com> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <CABcZeBN_tQgH8ZZmVg82h8-cthm0uQ6b846N71G9NYFSxdUMRQ@mail.gmail.com> <e84cc89e-6503-7cd7-4281-9cf4629a7bb7@gmail.com> <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3A5D70B2-B3F9-42A6-9219-F25D657A7A7F@vigilsec.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/RZI46UBrv9---dIbC35S5NQvX5U>
Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2020 16:12:00 -0000

On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote:
> Brian:
> 
> The point of a certificate is to bind the public key to the identity of the private key holder.  The certificate supports many different forms of names to support many different protocols.  The rfc822name is used to bind to an email address.

How do you think IETF should decide on what is a semantic correct
email address ? RFC5280 simply inherited the non-crypto definitions
of email address/mailbox.

Do you think it is appropriate for you to recommend blocking progress
of a document through IESG review based on your interpretation what
does and what does not constitute a semantic correct email address ?

Do you think that there are rfc2821 email addresses that are
semantically correct if not used in a certificate, but that are
not semantically correct for use in rfc5280 certificates ? If so,
can you please explain how such a differentiation would be justified
by existing RFC text ?

If you do not think that there is a semantic correct email addresses
outside and inside of certificate/rfc822Name use, how then would
it be appropriate for you, Ben or LAMPS to decide on what is and
what is not a semantic correct email address.

> And, something else is going on here.

Are you saying the addresses are (1) semantic correct email addresses AND
something else is going on, or are you saying (2) they are NOT
semantic correct email addresses AND something else is going on.

If you are saying (1), we are back to the above discussion of
the standing of how to decide what does and what does not
consitute a semantic correct email address.

If you are saying (2), i fully agree, but i would need an explanation
of how such "something else" would invalidate the use of such
email addresses in rfc822Name, because i see no further requirements
against email addresses in rfc822Name other than what you showed
in a prior mair on this thread. 

If a terminal is assigned an email address of
"room17.terminal5@example.com", and the software says to the
user "you are sitting in Room17 on Terminal5", because the
software expected a particular formed local part of its
email address and parsed it, that is something else going on.

If the same email address is then use together as an
identifier together with a password for the terminal to
access some resources, oh, like a library database, that is 
also something else going on. 

This is pretty much what ACP does. What is IMHO is NOT going
on here is that these additional aspects render
room17.terminal5@example.com into a non semantic correct
email address. They just do more with it.

> That is why I recommend otherName instead of rfc822name.

No, if you would just recommend an alternative that would be great,
but you are blocking progress of a document that has a lot of
in our opinion crucial explanations how that alternative would
create more use-case harm than the solution choosen in the document.

> I think that everyone understands that at this point.

I do not understand how a recommendation like yours can raise to
a blocking DISCUSS in an IESG review.

> Eric:
> 
> Please change the write-up for this document.  It currently says:
> 
> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
> If so, please summarise the areas of conflict in separate email messages to the
> Responsible Area Director. (It should be in a separate email because this
> questionnaire is publicly available.)
> 
>   No. There was unanimous support for this work and nobody raised any objections.
> This is no longer the case.

So, it is not a recommendation you are voicing, it is instead
"extreme discontent". 

I wonder what rules of IETF are for betting how such "extreme miscontent"
has to be technically founded or just needs to be taken into account
without suficient technical argument. I think you have provided
no clear technical reasoning for:

- How does the documents choice cause more harm than the alternative
  proposed for the use-cases or any other possible victims ?
- How is the choice in violation of any relevant RFC ?
- How are the email addresses not syntactic and semantic correct addresses according to rfc2821 ?
- How are otherwise statements like "i do not think this is the right thing" and
  "there is something else going on here" sufficient arguments for blocking
  IESG progressing the document.

Cheers
    Toerless

> 
> Russ
> 
> 
> > On Jun 27, 2020, at 11:09 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> > 
> > Hi Eric,
> > 
> > On 28-Jun-20 10:58, Eric Rescorla wrote:
> >> I'm not Russ, but I don't take his point to be about ACME one way or the other.
> >> 
> >> Rather, I take his point to be (as he just said in his response to Brian) that while this is *formatted* as an e-mail address, it does not in fact correspond to something to which e-mail can be delivered 
> > 
> > It might do, simply because it is so formatted.
> > 
> >> and therefore does not match the semantics of RFC 5280.
> > 
> > RFC5280 does not require such a mailbox to exist. Is there another normative document, e.g. a BCP, that does require one? It's entirely possible that the authors of RFC5280 assumed that such a mailbox would exist, but this is not written anywhere that I can see. So IMNSHO, this objection to the ACP draft is attempting to hold it to a standard that isn't documented.
> > 
> >> Taking a step back from the substantive issue, it seems to me that to the extent to which their is debate about the meaning of 5280, this is a discussion which cannot be resolved entirely on this list, but instead needs to involve the LAMPS WG.
> > 
> > That may be true, but it's not ANIMA's fault and the discussion first arose last year, so why hasn't LAMPS already considered it, if it's important enough to continue obstructing ANIMA's progress?
> > 
> >  Brian
> > 
> >> 
> >> -Ekr
> >> 
> >> 
> >> 
> >> 
> >> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <tte@cs.fau.de <mailto:tte@cs..fau.de>> wrote:
> >> 
> >>    On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote:
> >>> Toerless:
> >>> 
> >>> I think Brian actually made my point.  While the filed contains an email address, using it as such would result in a delivery failure.  The private key holder cannot be reached by this address.
> >> 
> >>    Russ, i said:
> >> 
> >>> First of all, you can if you want to,
> >>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> 
> >>    Aka: Yes, if an ACP admin thinks ACME style challenge/reply
> >>    email authentication mechanism is useful, then he can of course
> >>    set up those email addresses accordingly. I did reply to that
> >>    point exhaustively in my reply about the ACME email mechanism.
> >> 
> >>     Why do you ignore that answer ?
> >> 
> >>> and secondly, i contest that it is a requirement to be able
> >>> to do that if the recipient doesn't need to support it.
> >>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> 
> >>> Think about noreply@bad-corporation.com <mailto:noreply@bad-corporation.com>.
> >>> You do want to make sure though that you are in control of
> >>> the electronic mail address though, and that is given for ACP
> >>> addresses.
> >> 
> >>    Where in rfc5280 or any other generic RFC about certificates does
> >>    it say you MUST have a mailbox that is reachable ? Where does it
> >>    say that all certificiates with rfc822Name must be email boxes
> >>    that support ACME email style challenge-reply about the email address ?
> >>    I think this is a non-existing requirement against email addresses.
> >> 
> >>    Of course, noreply@bad-corporation.com <mailto:noreply@bad-corporation.com> can have a certificate with
> >>    that rfc822Name. It just can't use the ACME mechanism to be
> >>    generated. But the signed mails sent from that address can be
> >>    authenticated.
> >> 
> >>    Or there are never emails, because the email address just serves
> >>    as identifier of an entity such as in wifi roaming identification
> >>    and authentication. In that case you are not authenticating
> >>    e.g.: password ownership for the email address via actual emails
> >>    but via AAA protocols against a DNS domain known AAA server
> >>    for the domain part of the email address.
> >> 
> >>    If you want to write a standards track RFC that all email addresses
> >>    used in any X.509v3 certificate MUST support an ACME style
> >>    challenge/reply email, then please do that, and seee if you get
> >>    thast through. If would invalidate a lot of solutions like
> >>    those wifi roaming ones. It WOULD NOT invalidate the ACP
> >>    solution, because as said (no several times) the ACP solution
> >>    can perfectly be set up to support this. It just does not
> >>    need to.
> >> 
> >>    Cheers
> >>        Toerless
> >> 
> >>> Russ
> >>> 
> >>> 
> >>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert <tte@cs.fau.de <mailto:tte@cs.fau.de>> wrote:
> >>>> 
> >>>> Russ,
> >>>> 
> >>>> Top posting re. your ACP vs. ACME question.
> >>>> 
> >>>> ACP rfc822name are meant to be under control of the ACP network operations.
> >>>> aka: the ACP registrars could be controlling rfcSELF*@example.com <http://example.com> mailboxes using
> >>>> ACME S/MIME to get rfcSELF*@example.com <http://example.com> certificates or IMHO easier control
> >>>> the acp.example.com <http://acp.example.com> MTA.  Just no need/benefit to do this now IMHO:
> >>>> 
> >>>> An ACP is a private network which is ideally isolated from other
> >>>> ACP networks by use of private TA. Using the ACME rfc822name scheme would
> >>>> IMHO create a lot of attack components (all the MTA in the mail path
> >>>> and domain names) if used acros the Internet - without benefits for
> >>>> ACP. Of course, if it was all a private ACME setup within an enterprise,
> >>>> and using mailboxes and ACME is a popular choice - sure, why not.
> >>>> But for private CA setups there are existing IMO easier options
> >>>> (private CA VMs using EST or the like).
> >>>> 
> >>>> IMHO public ACME CAwith S/MIME authenitcation could  make sense
> >>>> in the future to enable authentication across different ACP domains.
> >>>> 
> >>>> Any network has links into other domains and today they are usually
> >>>> unauthenticated, that could be solved IMHO fairly easily.
> >>>> 
> >>>> "private" CA of ACP domain , lets call it acpCA signs all ACP certs.
> >>>> Its own cert is not self-signed, but signed by ACME CA via S/MIME,
> >>>> maybe email is rfcSELF@example.com <mailto:rfcSELF@example.com> (no ACP IPv6 address in it)
> >>>> 
> >>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA.
> >>>> After IKEv2 authenticates neigbor the followup ACP domain membership
> >>>> step checks if the TA of the peer is acpCA. If yes, then peer
> >>>> becomes ACP member, otherwise we have an authenticated signalling
> >>>> channel to an interdomain / different CA peer. And that of course
> >>>> would enable better/secure auto-configuration of such interdomain
> >>>> links.
> >>>> 
> >>>> This gives me good mix of security: Its still only relying on
> >>>> well controlled private TA to get into ACP, but also doubles
> >>>> at less secure but best available "Internet/Interdomain"
> >>>> authentication.
> >>>> 
> >>>> Cheers
> >>>>     Toerless
> >>>> 
> >>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote:
> >>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson <mcr+ietf@sandelman..ca <mailto:mcr%2Bietf@sandelman.ca>> wrote:
> >>>>>> 
> >>>>>> 
> >>>>>> Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
> >>>>>>> One cannot send email to the character string in this specification, so
> >>>>>>> it should not be carried in the rfc822name.
> >>>>>> 
> >>>>>> You can send email to that character string if you configure the MX.
> >>>>>> It was designed specifically to accomodate that.
> >>>>>> 
> >>>>>> I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon
> >>>>>> was going to have to send/receive email.
> >>>>>> 
> >>>>>> But, Toerless was paranoid that if we did anything at all out of the
> >>>>>> ordinary, that the corporate CA people, in order to protect their fiefdom,
> >>>>>> would freak out and throw some huge roadblock in the way of deploying the ACP.
> >>>>>> 
> >>>>>> And, now have an ACME method past WGLC that does certificate validation by
> >>>>>> SMTP.
> >>>>> 
> >>>>> Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol.  How do you see it working?
> >>>>> 
> >>>>> Russ
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>>> _______________________________________________
> >>>>> Anima mailing list
> >>>>> Anima@ietf.org <mailto:Anima@ietf.org>
> >>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>> 
> >>>> 
> >>>> --
> >>>> ---
> >>>> tte@cs.fau.de <mailto:tte@cs.fau.de>
> >> 
> >>    -- 
> >>    ---
> >>    tte@cs.fau.de <mailto:tte@cs.fau.de>
> >> 
> >>    _______________________________________________
> >>    Anima mailing list
> >>    Anima@ietf.org <mailto:Anima@ietf.org>
> >>    https://www.ietf.org/mailman/listinfo/anima
> >> 
> >> 
> >> _______________________________________________
> >> Anima mailing list
> >> Anima@ietf.org
> >> https://www.ietf.org/mailman/listinfo/anima
> >> 
> > 

-- 
---
tte@cs.fau.de