Re: [TLS] Why TLSA RR and not CERT RR?

Eric Rescorla <ekr@rtfm.com> Sun, 26 June 2022 13:23 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 6B48AC18BC88 for <tls@ietfa.amsl.com>; Sun, 26 Jun 2022 06:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 3xyVoA6dwlG5 for <tls@ietfa.amsl.com>; Sun, 26 Jun 2022 06:23:16 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 980AAC18BC8B for <tls@ietf.org>; Sun, 26 Jun 2022 06:23:16 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id a16so4411726ilr.6 for <tls@ietf.org>; Sun, 26 Jun 2022 06:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HyfpqxPbwau84gc7z8O3BB1iETPajYpDd75mJDY8Hfc=; b=hZRmjTCM8d1UDSfuaMbFjAgv7uREwEadENtj3M+ftV3J8hWEAMx9MkWr4atpr6WxTR CvDvIWaPvI8v/AYuatRNT+xv6Rjn6LD+/UUALSnYDtLomfumzXpm3l7QYPeO4gA0eUO5 fRfnNiyz5HTPKCmmuREAfFnsq6VsQAId1eUHTnuIZf6ykqxznv8NNzNXLXEPuMi3CTok ePyeV++T2bxxgzApkad7VdfK4YUFLdSve7Jvd1PemtKIqluRw+J9avhNRa79u+49Hufl NCcKVKTpmxTStWp707wAYRlLrJhpqtAc7XbkFXjMch6x4OiJV6MWNjO0ZloD23pZiAD4 5vBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HyfpqxPbwau84gc7z8O3BB1iETPajYpDd75mJDY8Hfc=; b=VsgTSw/M4ZBIxB35tbCCmWt0xzgoeRy/Y2QzroRAejBD69sOeAt2Hf2NgE8vHYiNqm Xio/AQzv/I2wMWOojPkr0buVWNU6O5TKYVDZuNPNpLLGo7ODq5RDLIjlH5nr/+BWMRsL LxAEmpCzYzSqHPk+KzqJBfn51GS36UdRGj2E7fqQAwM7DnM+AyUKXBLKDsVrkrCkUP4g 9LfGP00/qGCRPAy0ZdRoido7b2EEJUXUMoKQFLgvx3by5obuHDeArUifpBku0ZckCOJD 3Y2sW36hsfZkjEx0FSAnAqYVJ6+bWYLU2iuH0NGGrIa7GK8fDeo+X9tv74H8G4/Hs8TA urUA==
X-Gm-Message-State: AJIora/CytTXazINSXLEjXxm5K3vsHQExNLuYcF9r/i02JvwA+s/GKkS N7rLqf/ZIBJyoQU//+WHmvzXvkO7CXa1zPsjxk9YAg==
X-Google-Smtp-Source: AGRyM1tjMI+kpxzq1Y3FCvexQzB7YUfiCvC7rbA+nqk0Jk+NxDmLwNfnOzP4DbHcTRLFDnKa53hZX5ahh2n2eiH8vKU=
X-Received: by 2002:a05:6e02:12e4:b0:2da:73e6:1d8a with SMTP id l4-20020a056e0212e400b002da73e61d8amr4222890iln.276.1656249795667; Sun, 26 Jun 2022 06:23:15 -0700 (PDT)
MIME-Version: 1.0
References: <fbd4826a-8604-9170-b7ea-a5ed86ef1462@htt-consult.com>
In-Reply-To: <fbd4826a-8604-9170-b7ea-a5ed86ef1462@htt-consult.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 26 Jun 2022 06:22:39 -0700
Message-ID: <CABcZeBP3ew2YXKgcfgQwzBTPjG=diAYURBJ+8d1ULJ3pHSUigg@mail.gmail.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: tls <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb02b205e259b42e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/__ygU4Hqd2II-NsbpSpAcpJBozI>
Subject: Re: [TLS] Why TLSA RR and not CERT RR?
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: Sun, 26 Jun 2022 13:23:20 -0000

Well, this really isn't a question for the TLS WG as DANE is external to
TLS.

With that said, ISTM that the primary purpose of DANE is to indicate which
certificates are acceptable rather than to convey them, as TLS already
knows how to convey them.

-Ekr


On Sun, Jun 26, 2022 at 5:05 AM Robert Moskowitz <rgm-sec@htt-consult.com>
wrote:

> Recently I have been in a discussion about DNS RR that hold X.509
> certificates.
>
> I am asking this here, as I *Think* there may be some knowledge here
> without me joining other lists...
>
> I was aware of DANE's rfc6698 that holds both X.509 certs or
> SubjectPublicKeyInfo.
>
> But I was pointed at rfc4398  Which does NOT handle
> SubjectPublicKeyInfo, but handles X.509 and other formats.
>
> Interesting that they both end in '98' and this is way after Jon was
> around seeing to how RFC numbers were assigned  :)
>
> What was the deciding point not to use 4398 for DANE?  (and now DANCE)
>
> What is 4398 currently used for?  Why was it not just updated to add
> SubjectPublicKeyInfo rather than add a new RR?
>
> And then there is rfc7250 which references 6698...
>
> Thank you.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>