Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models
Margaret Cullen <mrcullen42@gmail.com> Sun, 13 August 2023 22:46 UTC
Return-Path: <mrcullen42@gmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF353C14CF0D for <radext@ietfa.amsl.com>; Sun, 13 Aug 2023 15:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.855
X-Spam-Level:
X-Spam-Status: No, score=-6.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krAd0ALkd3iq for <radext@ietfa.amsl.com>; Sun, 13 Aug 2023 15:46:28 -0700 (PDT)
Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF434C14F74E for <radext@ietf.org>; Sun, 13 Aug 2023 15:46:27 -0700 (PDT)
Received: by mail-qv1-xf29.google.com with SMTP id 6a1803df08f44-63fbfc0b817so26645116d6.1 for <radext@ietf.org>; Sun, 13 Aug 2023 15:46:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691966786; x=1692571586; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=302JHhw8yNKdxryJQKIsjshJwGnLQPCh1T3+bbBHi7Q=; b=rl22ZO4B2HjpcXxSUtwBEcatFODhXofWQkutr415UYi1P/U5E2RkwGQBAKJbdM6oH6 UMMjG468jDZrCRtqKoOmtoQV981Ox/5Pi3CxxUmWI5gJHa5aS8rMkC7qfzBmqTxzBmDy Lkoylwfd+7k/ICsTQVkFkNDhgwTFqKpLSIdRCnYP20ZtXmy0VYjfPrUTkOwSZ5mzI3mC WzsxtGop+VmfcZ3PLEx0zJP1qv43QcYhmqj3he+i9b1hy2XEPiNlhBE86+xozmXW90jn ratchZ7crYHQqEw4B7foF9KG3XxgW8GG2AJtrO8Rpxvj0pqqBk8oOWcWMo5DzHalfNAI xVtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691966786; x=1692571586; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=302JHhw8yNKdxryJQKIsjshJwGnLQPCh1T3+bbBHi7Q=; b=WNmy2yr3Q8deIGRWey5wtK8GULZXh+7gHn4wZnir8NwlY4K73XTBEzICM7S05+ZAn0 faRvPbweol55mwqJVcqZzQfdctl0Wr55GokA1zfOyPqjzLVxlavYo5xhsflDALk6laAZ Ht8NWmZzQarwXVxogMEvyCCRobcn47Xz89z4pIKugiCDwzhmL3lu4+7TLfb9mU61lYH0 bjCedseVAsd1NBQM69hrSioN5qSX8tIRgMBygJJMFo32bzniAEuMpYLvIZSNp0Xy7ldh L8R5qDrebm8k2C3ycoh+onJwWj6Hh6TpLy1R5GcA1IRz25yen9biZFz9hUfnexRPhQv1 J7/w==
X-Gm-Message-State: AOJu0YxWr5/aja5lhkFqy7A4mwk81cgioJs9eTRf1fk/6KWOfwBKVOc5 3HT/P1vwkUDn4jOVKx+BpGDGjpudMVU=
X-Google-Smtp-Source: AGHT+IEWxMSM4gGIEuVcuBbkk1GQ8WTw3jk/cK9mxTzqmi08KU3u4AyBkv9sgcC2GYPwhkGY+rBhsA==
X-Received: by 2002:a0c:df81:0:b0:63c:f999:ba83 with SMTP id w1-20020a0cdf81000000b0063cf999ba83mr9445401qvl.32.1691966786104; Sun, 13 Aug 2023 15:46:26 -0700 (PDT)
Received: from smtpclient.apple ([2601:18c:503:9630:5cc4:c81a:a38c:14b]) by smtp.gmail.com with ESMTPSA id d28-20020a0caa1c000000b0063f78bc8685sm2921916qvb.139.2023.08.13.15.46.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Aug 2023 15:46:25 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Margaret Cullen <mrcullen42@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 13 Aug 2023 18:46:14 -0400
Message-Id: <176340A7-AA23-4131-87EA-50A4F823FF60@gmail.com>
References: <08757003-146e-446e-88b5-7a97ae217f71@app.fastmail.com>
Cc: radext@ietf.org
In-Reply-To: <08757003-146e-446e-88b5-7a97ae217f71@app.fastmail.com>
To: Alexander Clouter <alex+ietf@coremem.com>
X-Mailer: iPhone Mail (20F75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/42g2ULLARw3l7rqjB2ct3S3_Yus>
Subject: Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Aug 2023 22:46:31 -0000
Okay, I withdraw my concern. From a “better specification” standpoint, I agree that mandating that servers implement everything and allowing clients to implement only what is needed for their application makes sense. Margaret > On Aug 13, 2023, at 6:36 PM, Alexander Clouter <alex+ietf@coremem.com> wrote: > > On Sun, 13 Aug 2023, at 18:38, Margaret Cullen wrote: >>> DTLS is a lot more difficult. I blame some of that on OpenSSL weirdness. Their DTLS implementation has best been described as "alpha" for a long time. >> >> This is the reason for my concern with mandating that servers implement DTLS. > > OpenSSL is not the only TLS library out there. I would be hesitant steering any decisions based on a single (albeit more widely used) library implementation. > > The telephony world though seems to be quite happy using DTLS, after all no one wants to endure voice/video calls over the WAN via TCP. > >> I think RADIUS/DTLS is an awful lot to expect, though — especially >> because I don’t see any evidence that RADIUS/DTLS will ever be widely >> implemented or used. Do you? > > Personally I really think this is more due to people not knowing TLS-over-UDP is even a thing. > > Maybe I am seeing this too simplistically, but the impact of any mandating done here only affects (officially) the labelling available to a vendor? > > * implementors of TLS *and* DTLS: you get to tout 'RFCwxyz compliance' > * implementors of only TLS: "you do not get this scout badge, sorry" > >> Many protocols that run over TLS don’t have a DTLS equivalent defined, >> at all. Is there some important advantage that RADIUS/DTLS offers that >> RADIUS/TLS does not? Is that advantage sufficient to warrant mandating >> both in every server implementation? > > Head of Line blocking. When a packet is lost, the RADIUS server is unable to do anything but twiddle its fingers until the networking stacks, outside of its control, at both ends figure it out. > > This means first the packet drop has to be detected, this can take some time anywhere from one to 1000's of milliseconds (~2xRTT), then retransmitted by the TCP layer until it gets through. > > The RADIUS server meanwhile is unable to get involved in the retransmissions its-self. > > Making it worse, *all* further authentications are gummed up until the stream starts to flow again. > > With datagrams, this simply is not a problem. Recovery is much more application orientated, plus it bubbles up to the application so failover opportunities are made available far sooner. > >>> There's good reason for that, of course. But I think it's best to document the system we need, rather than the system we have. >> >> I absolutely agree with this when it comes to documenting good protocol >> behavior, ways to avoid known issues, etc. I don’t think it extends to >> mandating the implementation of an entirely separate protocol. > > I think the wording makes this seem a bigger deal than it is. > > Transport, not protocol. > > Trying here to shift the focus that this is about something RADIUS runs *over* and not something that actually has to be implemented by anyone; the TLS libraries do all the work for you. > > It may be that an implementor has picked a library that is a pain on the DTLS front to work with, but I do not think this should be a reason to strike "MUST do DTLS". > > Afterall, the hard part of the work is already done. RADIUS servers are already expected to have implemented a datagram transport (ie. UDP) and handle retransmissions. > > Wiring TLS into that is a lot more straight forward than the hoops an implementator already goes through to handle any of the EAP-TLS method families such as fragments and the need to spoon feed the TLS library *manually*, yikes! > > No TLS library supports TLS over EAP, but it still works :) > >>> The alternative is to never fix RADIUS, or to give bad implementations a free pass. >> >> Is there a reason that you think a RADIUS/TLS-only server would be a >> bad implementation, and that it would become a good implementation if >> it also implemented RADIUS/DTLS? > > The fallout I see is we will never see any DTLS implementations, and the for the most part this would have occurred for no real material reason. > > Like Alan said, OSS implementations are able to clear these hurdles without making much of a song or dance about it which leaves the only benefactors of weakening this requirement to those with arguably the resources where implementing this likely to be just a budget rounding error. > > I also suspect requiring DTLS will benefit those Internet cafe hotspot owners with their ropey saturated xDSL uplinks trying to authenticate the users to some hodgepodge WAN hosted RADIUS server federation. > > For all of these reasons, I really do think servers should be expected to do both. My view is the client can implement whatever it wants...they already do for better or worse... > > Cheers > > [1] https://mailarchive.ietf.org/arch/msg/radext/5HB6BTgxA_LqgWDdSIE30u_Ckg8/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext
- [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust mo… Jan-Frederik Rieckers
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Alan DeKok
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Margaret Cullen
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… josh.howlett
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Margaret Cullen
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Alan DeKok
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Alan DeKok
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Alexander Clouter
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Margaret Cullen
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Jan-Frederik Rieckers
- Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trus… Stefan Paetow