IETF Logo Mail Archive

Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 13 July 2019 18:41 UTC

Return-Path: <mcr@sandelman.ca>
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 38E4B120157; Sat, 13 Jul 2019 11:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lUyM9Ki-xFMX; Sat, 13 Jul 2019 11:41:24 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189CE12017A; Sat, 13 Jul 2019 11:41:22 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [209.87.249.16]) by relay.sandelman.ca (Postfix) with ESMTPS id DD99F1F44D; Sat, 13 Jul 2019 18:41:20 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 205C02EB5; Sat, 13 Jul 2019 14:41:37 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org
In-reply-to: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com>
References: <156285243815.32459.10845626927382447919.idtracker@ietfa.amsl.com>
Comments: In-reply-to Magnus Westerlund via Datatracker <noreply@ietf.org> message dated "Thu, 11 Jul 2019 06:40:38 -0700."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: text/plain
Date: Sat, 13 Jul 2019 14:41:37 -0400
Message-ID: <17539.1563043297@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/WXFDBLzlK_7h3jlK5rOcbtTnmOU>
Subject: Re: [Anima] Magnus Westerlund's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS)
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: Sat, 13 Jul 2019 18:41:26 -0000

<#secure method=pgpmime mode=sign>

Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
    > A. This is really a discuss discuss. With to little time to dig into
    > the details it appears that this protocol is making i hack of its
    > interface towards the its transport. It appears to attempt to use an
    > HTTP rest interface, but then it is also have a lot of talking about
    > requirement for the TLS connection underlying the HTTP. So to
    > illustrate the issue I see here is what happens if one like to use QUIC
    > as the underlying transport for the rest interface rather than TCP/TLS?
    > So can this document achieve a clearer interface to the lower layers so
    > that it will be simpler to move the protocol to another underlying
    > version of the HTTP "transport"?

Between the JRC (Registrar) and the MASA, we can support any HTTPS, including
HTTP/2 with QUIC (with the 'normal' corporate firewall issue with UDP).

Between the Pledge and the Registrar, we support any HTTPS that works over a
single TCP connection.  We can not support QUIC, since the Pledge is behind
an intentionally limited proxy.  We had some discussion about this a year or
so ago, please see:
  https://mailarchive.ietf.org/arch/msg/anima/ml1OSEKhR4-ICS0Bd0zfuzn8uw4

You are certainly right: we have linkage between the TLS layer and the
application layer, and we expect TLSClientCertificates and
TLSServerCertificates to have meaning at the application layer.

None of the connections could go through TLS "forced proxies" of the kind
that are apparently common in Enterprises.

I am open to suggestions on how to make the document clearer about how it
interfaces to TLS.  We have a sections:
    5.1.  BRSKI-EST TLS establishment details . . . . . . . . . . .  36
    5.4.  BRSKI-MASA TLS establishment details  . . . . . . . . . .  38



    > B. Section 5.6:

    >  The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error
    > code when a problem occurs.

    > Referencing RFC 2616 that has been obsolete by RFC 7230 and
    > companions. I do note that there are no normative reference for that
    > part in this document.

Fixed to 7230.
Yes, that wasn't even a real reference, just a literal [RFC2616].

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email