IETF Logo Mail Archive

Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS

Eric Rescorla <ekr@rtfm.com> Tue, 29 November 2022 02:24 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1777C14CF17 for <tls@ietfa.amsl.com>; Mon, 28 Nov 2022 18:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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=rtfm-com.20210112.gappssmtp.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 eZ-1YHv81Wfe for <tls@ietfa.amsl.com>; Mon, 28 Nov 2022 18:24:16 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 05FD2C14CF15 for <tls@ietf.org>; Mon, 28 Nov 2022 18:24:16 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id i85so9111995ioa.5 for <tls@ietf.org>; Mon, 28 Nov 2022 18:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=hWtUVDozjuxE7e7wDtU1/0kbt3ybYVTKwjWkalzbaIw=; b=VfvlEbRFNqVDyKSAUN3uuR8+HvOyHSSWopTM45/GQ1YktYqDHk9zLz92sprF3vekwH wfSzCPejhzvw+3lybElXJqi5+lCiQAlAsIzWhZfA7x9pST3ajPeItyArDzQVv7jHSy4I 1QBD09gJXAjQPAHr8fcXjVDNcnSls9c+HiD1b77RJQH7CCGWMnqEPY9WszYt9XsPSL/V i0FGcKCjQ15EIsVSQMzIBhsn8dGAD1My9Y+lb/4WMAvD6b1EIv8JZqxRlCueIIETRA+e MOjfCJFyAC7qQtDvll6KmDRJxlL4/WOQdwHE66307a1OacKYMEUcufeHmd9Koqo4FNLa axHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hWtUVDozjuxE7e7wDtU1/0kbt3ybYVTKwjWkalzbaIw=; b=M/44P9s0cNgcUJnkV60m2F6txXsU77/eerxqk+0Zhk6Gf7LJQXRJ5CrjXl0qUmzZg/ Y5SRJ0m6fwITlGhTlrrRW/ir2TPDCXbZJ9GeFszuBhqNFdFrghEUeEMZEbv/b+2I83mq dbwTgaN0LhrOiwROWtZoiqgbKJFJ+yl/SiMAI14jOSoARLdFUHDDiZMOFM2weyWUOlcN CrsbM6L3YvfUxWldCaX0EmseKrPvsl9faKqAmjc9yyRCnyvEdo+k/icroY9/zhnr02Ws F2OC5H7rRqOybjPHbI0ZasO2HUuwVaihjkwAQJenVpNFqgejO5GLOvxORXDh6hVkp28/ x9pg==
X-Gm-Message-State: ANoB5pncklK5KBQo/EQJN0czyXhm16h/KjMkQNRcbQutHTxRVGyFLnOl P1xCY+2U4Wo3CXHKjeVPbaj5hY4OjexbFQ5bSQv0CQBy3I0=
X-Google-Smtp-Source: AA0mqf4RaZhph0CbT7ILh83NmPTINP64hDpeKdIehNE9wl+Ny2xuzafLZWi/k0gBQvyv9sP1qcXM8rrmdk5mtYb7CZo=
X-Received: by 2002:a5d:964c:0:b0:6bb:f826:cf78 with SMTP id d12-20020a5d964c000000b006bbf826cf78mr16142767ios.216.1669688653624; Mon, 28 Nov 2022 18:24:13 -0800 (PST)
MIME-Version: 1.0
References: <9jom-o0k2EKlsgFmAQfJqg2oBOK_bEw9D1VvMz3nmF4L4K1vftMPU916SKERU48MSk10IakHBzdPD74CMFYha65rdhg-8PqDpPpArSfYuPI=@olliejc.uk> <CAMjbhoXbJamGzM3KK8QU2_Qnu3E9DUvX1A_OvqqUFmbTOtTQrQ@mail.gmail.com> <Y4VhIBeSZi2Lclj3@straasha.imrryr.org>
In-Reply-To: <Y4VhIBeSZi2Lclj3@straasha.imrryr.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 28 Nov 2022 18:23:36 -0800
Message-ID: <CABcZeBNvV9f8oB6Ve08AENBGxgiT=11nPUrRXiL=0_r2EW7RWQ@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000015d3d305ee92afe9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sIUDPFvDqBlpWJl1pPoRyRNQVYw>
Subject: Re: [TLS] Trusting self-signed TLS certificates - specifically for HTTPS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2022 02:24:19 -0000

Thanks for the elaboration, Viktor.

I think the TL;DR here is that this isn't TLS-relevant work at present.
Either you get the certs directly or you get them via RFC 9102 but in
either case, TLS has the appropriate support.

If you don't need CT--I'm not entirely persuaded by Viktor's argument but I
agree that the need is probably less than with WebPKI--then it seems like
the technical work is done. If you do need CT, then probably your next stop
is secdispatch, what with trans being closed.

-Ekr


On Mon, Nov 28, 2022 at 5:32 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Tue, Nov 29, 2022 at 01:04:14AM +0100, Bas Westerbaan wrote:
>
> > > In essence, I'm proposing that user agents should trust a fully DNSSEC
> > > domain with a TLS certificate set up using DANE, along with changes to
> CT
> > > log submission process to allow self-signed certificates (looking to
> > > suggest via rfc9162).
> >
> > How do you propose we prevent CT from being DoSed by a deluge of
> > self-signed certificates?
>
> There isn't a known viable approach to combine the existing CT system
> with DANE.  On the other hand, the actual certificates are not what one
> would want to log anyway.  Instead one would only want to log DS RRsets
> or NODATA proofs from eTLD registries (gTLDs, ccTLDs and also various
> 2LD, 3LD, ...  suffixes operated by TLD registries).  Clients that
> contribute to CT logs would need to run validating resolvers and
> log signed delegations.
>
> Once a NODATA proof is recorded, no more such proofs are logged until
> the delegation is again signed.
>
> So spamming can only happen as a result of repeated changes to a zones
> DS RRset, including its deletion.  Similar spamming would be possible by
> obtaining certificates from many CAs and rolling them over as frequently
> as possible.
>
> So long as a domain's DS RRset is not forged by the parent eTLD, what
> (self-signed) certificates its TLSA records vouch for is an internal
> matter, that is easily audited internally.  Monitor your DNS, and don't
> sign rogue TLSA records.
>
> --
>     Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email