Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
Justin Uberti <justin@uberti.name> Fri, 01 March 2024 01:15 UTC
Return-Path: <juberti@gmail.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BC0C14F60D; Thu, 29 Feb 2024 17:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.405
X-Spam-Level:
X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=no autolearn_force=no
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 IzDflrrNpSVq; Thu, 29 Feb 2024 17:14:58 -0800 (PST)
Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 1D2F3C15107F; Thu, 29 Feb 2024 17:14:58 -0800 (PST)
Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-5131316693cso1984172e87.0; Thu, 29 Feb 2024 17:14:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709255696; x=1709860496; h=cc: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=Q491HHUDbbmyZnXrsZgaoNxKl1oY+oSbQRJPLSDsGR4=; b=kq9qY5cJcnNJmU5XYarz+xy7GudBOMAX99OWRJ0NeDxLVF38iyvRFzhSzGCEbPDMR9 cdkRGY3Tww/ct273QfKzvIOFKmTtMNbcVsHIagxpzz15curQwzET1tEIG6rGYPEsCYAb kkPnUitxgPuDK95yKqqDQgfbF7QJlT/S5G+nsvCUa17edhwzVOZzwfv0KE+BwSXPKfb4 oJAAi+FXqHIC2PWC4pK5Vh9IYwTwQw2FPUchQZK19IdyXxvdtt4No3xiz025HD4FCRuC VyZeO0d/K6jw7yQ+G56yb723D+gLHXLQ8lHojtOz7OGaj6ASt53JgUoExn5wqFM5D/lk HDLg==
X-Forwarded-Encrypted: i=1; AJvYcCWUMdZioQg6F7CP+UAwl+qiapOzgZxYGyJasdgsN0ZRUWG7TqWuNGZYBZm9aY10B9o0Fm5hw3/FS4frdiYCM6OjFiE02SdXMLGUWvRPtJNm1kTxiFzO6bGbwCYttE5xj8WH/pVRPBZ9
X-Gm-Message-State: AOJu0YwgO7oWD7/gvlXrEWamY4Lxv7Ru+gk5SWPZvmi527wDB8D7a0ke NHb2SOshoVS27O4wwgFTAtKDa/e/JgqSUIt7THmiGMhzQ+bNqxvrMMjiLC/sVkxU2JoFW5MSAcR rqLlXy/dbV4L/ECDId3WOyVwLYBw=
X-Google-Smtp-Source: AGHT+IGX24/8SKLeOnzIiQZ9J10bM5SE4tkPDrI7z8VTHk2Nx0mWAUZlvp6Uz2Psc/145FgH9Ug1sxMwR4GqA1LupCY=
X-Received: by 2002:ac2:42cf:0:b0:513:2039:63b2 with SMTP id n15-20020ac242cf000000b00513203963b2mr128224lfl.32.1709255695802; Thu, 29 Feb 2024 17:14:55 -0800 (PST)
MIME-Version: 1.0
References: <20231010213257.4587F18E4B44@rfcpa.amsl.com> <CALe60zDWOpAgXM=T+q=jG7GumtWGzASe=i=x5qBSG+bew5046g@mail.gmail.com> <57DC6A9D-181D-4A92-9B78-1A9E4F97252C@amsl.com> <6530F168-75F1-4CA6-9E7D-2D402D6BEC41@iii.ca> <9F18480D-4F13-4C85-B224-66BA4EF2F4EC@amsl.com> <CABcZeBPjdcsea_X0YMrcwbgQmV_uiDdV+3=Aet7VPMaJG1=9GA@mail.gmail.com> <A60976A1-3B52-42A9-9A5B-13618AE62855@amsl.com> <CAL0qLwZYokpy-UHFf24NyEBufFG4rtJQ6MS8bEUrugaJNmdusw@mail.gmail.com> <882B1E35-51DE-4AE2-85A7-6027CF9A3679@amsl.com> <137CB627-2A2A-46E5-86CA-24FF50C97BBC@sn3rd.com> <1EC63115-8045-4442-B1F9-1621DF507D98@amsl.com> <5B33BBAB-FA41-441B-97AF-6518CA98726E@iii.ca> <CABcZeBOZGsHZR7WarEdF+UyHmOJjbCDA_KCiEUpGT6JE75CGtA@mail.gmail.com> <D610B593-CABA-4B44-ABCB-C712F6F112BC@iii.ca> <CABcZeBOiZrOLmTLHpu_b831TCzm_OpciV1c8JxN4fV57+kOw0w@mail.gmail.com> <A3F92F81-CEB4-4E78-9D46-310A1AAFC542@iii.ca> <CABcZeBMuOKg-=pDGU_6uq1gxxmMM13ZHkNzXt1=qvg3dXr0ZCQ@mail.gmail.com> <CA+9kkMAMqyzvMew1tfzRTxt6apGMYwYZ2YrprMHH+mxX-pyTwQ@mail.gmail.com> <CALe60zDok93CoPpD+pMRZd+mrcUiYJaFW+M6zYZDLG_oZ8Gb4A@mail.gmail.com> <12BE1DBA-973A-456B-BD34-FD91A090F9FD@amsl.com> <B776A6A8-BA14-48AA-A1BD-CAF2FC4BA080@iii.ca> <66332362-23DF-4EE8-B7A7-165522A51DC5@amsl.com> <CA+9kkMB_+SZmksb06jW0pBwc682=zumrLzNHTFNZ=E96D8wZcA@mail.gmail.com> <CABcZeBOLw6mN0R+A1ok7drf=WGBPyfdmRtt4AWdLeEMn1AXDjw@mail.gmail.com>
In-Reply-To: <CABcZeBOLw6mN0R+A1ok7drf=WGBPyfdmRtt4AWdLeEMn1AXDjw@mail.gmail.com>
From: Justin Uberti <justin@uberti.name>
Date: Thu, 29 Feb 2024 17:14:39 -0800
Message-ID: <CALe60zBZFUtBmH0=tZbbtMDVNmgHm3dg0MxyTwEiRZNDw1zVhQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Lynne Bartholomew <lbartholomew@amsl.com>, Cullen Jennings <fluffy@iii.ca>, Sean Turner <sean@sn3rd.com>, "Murray S. Kucherawy" <superuser@gmail.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, auth48archive <auth48archive@rfc-editor.org>
Content-Type: multipart/alternative; boundary="0000000000009426e506128f1ac0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/c3VdqxU6Ijd5UGbv-gjEW7xRb7c>
Subject: Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2024 01:15:02 -0000
I'm going to do a read-thru this weekend just to review all the edits and hope to sign off once that is done. On Wed, Feb 28, 2024 at 6:55 PM Eric Rescorla <ekr@rtfm.com> wrote: > I still have to review the changes; I've been waiting for these > discussions to conclude beforehand. I'll try to do that in the next week or > two. > > -Ekr > > > On Wed, Feb 28, 2024 at 9:11 AM Ted Hardie <ted.ietf@gmail.com> wrote: > >> Hi Eric, Justin, >> >> Are you also okay? >> >> Ted >> >> On Tue, Feb 27, 2024 at 6:10 PM Lynne Bartholomew <lbartholomew@amsl.com> >> wrote: >> >>> Hi, Cullen. >>> >>> Glad that all looks good. We have noted your approval: >>> >>> https://www.rfc-editor.org/auth48/rfc9429 >>> >>> Thank you! >>> >>> RFC Editor/lb >>> >>> > On Feb 27, 2024, at 5:25 AM, Cullen Jennings <fluffy@iii.ca> wrote: >>> > >>> > >>> > Thanks looks good to me. >>> > >>> > I am OK to publish this. >>> > >>> > Thank you >>> > >>> > >>> >> On Feb 26, 2024, at 3:50 PM, Lynne Bartholomew <lbartholomew@amsl.com> >>> wrote: >>> >> >>> >> Hi, Justin, Ted, Eric, and Cullen. >>> >> >>> >> Cullen, we have updated this document per your note below. >>> >> >>> >> The latest files are posted here. Please refresh your browser: >>> >> >>> >> https://www.rfc-editor.org/authors/rfc9429.txt >>> >> https://www.rfc-editor.org/authors/rfc9429.pdf >>> >> https://www.rfc-editor.org/authors/rfc9429.html >>> >> https://www.rfc-editor.org/authors/rfc9429.xml >>> >> https://www.rfc-editor.org/authors/rfc9429-diff.html >>> >> https://www.rfc-editor.org/authors/rfc9429-rfcdiff.html >>> >> https://www.rfc-editor.org/authors/rfc9429-auth48diff.html >>> >> https://www.rfc-editor.org/authors/rfc9429-lastdiff.html >>> >> https://www.rfc-editor.org/authors/rfc9429-lastrfcdiff.html >>> >> >>> >> https://www.rfc-editor.org/authors/rfc9429-xmldiff1.html >>> >> https://www.rfc-editor.org/authors/rfc9429-xmldiff2.html >>> >> >>> >> Please let us know whether (1) additional updates are needed for this >>> document or (2) you approve this document for publication in its current >>> form. >>> >> >>> >> Thank you! >>> >> >>> >> RFC Editor/lb >>> >> >>> >> >>> >>> On Feb 26, 2024, at 2:30 PM, Justin Uberti <justin@uberti.name> >>> wrote: >>> >>> >>> >>> This proposal also looks good to me. >>> >>> >>> >>> On Mon, Feb 26, 2024 at 6:42 AM Ted Hardie <ted.ietf@gmail.com> >>> wrote: >>> >>> Hi Justin, >>> >>> >>> >>> Can you confirm you are also okay with this way forward? >>> >>> >>> >>> thanks, >>> >>> >>> >>> Ted >>> >>> >>> >>> On Mon, Feb 26, 2024 at 1:44 PM Eric Rescorla <ekr@rtfm.com> wrote: >>> >>> This works for me. >>> >>> >>> >>> On Sat, Feb 24, 2024 at 9:53 AM Cullen Jennings <fluffy@iii.ca> >>> wrote: >>> >>> >>> >>> First, my huge apologies for the ridiculous time I have taken to get >>> back to this. I was out sick for a while and then dealing with reorgs at >>> Cisco but even with all of that, I should have done this long ago. >>> >>> >>> >>> I agree with Ekr's reasoning on what we should do here to cite both >>> RFC 6347 and 9147 along with the note he proposed for section 5.1.1. I >>> think that should acceptable to anyone else too based on Ekr's argument. I >>> can see an argument that the note is not needed but I think it clarifies a >>> somewhat confusing situation of what does referencing both 6347 and 9147 >>> even mean. I would argue that since 9147 is permitted, not required, in >>> RFC8827 this could be an information instead of normative reference to >>> 9147. However, I think the note clarifies the issue and I am fine with >>> ignoring if the ref is normative or not. So I’m fine with both 6347 and >>> 9147 normative along with the note. >>> >>> >>> >>> Lynne, can you make the following changes ? >>> >>> >>> >>> In 5.1.1 add Ekr's note to the bullet point: >>> >>> >>> >>> OLD >>> >>> * DTLS [RFC6347] [RFC9147] or DTLS-SRTP [RFC5763] MUST be used, as >>> >>> appropriate for the media type, as specified in [RFC8827]. >>> >>> NEW >>> >>> * DTLS [RFC6347] [RFC9147] or DTLS-SRTP [RFC5763] MUST be used, as >>> >>> appropriate for the media type, as specified in [RFC8827]. >>> >>> Note: RFC 8827 requires implementations to support >>> >>> DTLS 1.2 [RFC 6347] and permits the use of DTLS 1.3 [RFC 9147]. >>> >>> (I did not change anything in the old, just added note to end of >>> it). >>> >>> >>> >>> I think that is only change that comes out of this. >>> >>> >>> >>>> On Jan 15, 2024, at 12:36 PM, Eric Rescorla <ekr@rtfm.com> wrote: >>> >>>> >>> >>>> >>> >>>> >>> >>>> On Mon, Jan 15, 2024 at 11:15 AM Cullen Jennings <fluffy@iii.ca> >>> wrote: >>> >>>> >>> >>>> Sorry for the very long delay on this. It’s been an a sort of >>> shitty month for me. >>> >>>> >>> >>>> Hi Cullen, >>> >>>> >>> >>>> I think we should disentangle two issues. >>> >>>> >>> >>>> 1. What we substantively say about what version of DTLS people >>> ought to use. >>> >>>> 2. What we use as a citation where the bare term "DTLS" without a >>> version number is used. >>> >>>> >>> >>>> As you may recall, JSEP doesn't specify DTLS versions and leaves >>> that to S 6.5 or RFC 8827, which has this somewhat labored text encouraging >>> but not requiring you to use DTLS 1.2. >>> >>>> >>> >>>> All implementations MUST support DTLS 1.2 with the >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve >>> [FIPS186]. Earlier drafts of this specification required DTLS 1.0 with the >>> cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this >>> writing some implementations do not support DTLS 1.2; endpoints which >>> support only DTLS 1.2 might encounter interoperability issues. The >>> DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported >>> for SRTP. Implementations MUST favor cipher suites which support Forward >>> Secrecy (FS) over non-FS cipher suites and SHOULD favor Authenticated >>> Encryption with Associated Data (AEAD) over non-AEAD cipher suites. Note: >>> the IETF is in the process of standardizing DTLS 1.3 [TLS-DTLS13]. >>> >>>> >>> >>>> If we wanted to say anything normative about DTLS, we would >>> properly do so in an 8827 bis, but we haven't done so, and I don't recall >>> there being much WG discussion on DTLS versions since DTLS 1.3 was >>> published. So my suggestion would be to try to just address point (2) here, >>> which is to say to provide reasonable references while not creating new >>> normative facts on the ground. I think the text above permits the use of >>> DTLS 1.3, so the current status is your (A), and while I would argue for >>> A'[MUST DTLS 1.2, SHOULD DTLS 1.3] I don't think that's for this document. >>> >>>> >>> >>>> This leaves us with the question of what references to provide. >>> What I suggest here is that we cite both RFC 6347 and 9147 wherever we just >>> say "DTLS", except for S 5.1.1, which actually requires the use of DTLS, >>> and there add a note something like: >>> >>>> >>> >>>> "Note: RFC 8827 requires implementations to support DTLS 1.2 [RFC >>> 6347] and permits the use of DTLS 1.3 [RFC 9147]". >>> >>>> >>> >>>> How does this sound? >>> >>>> >>> >>>> >>> >>>> Below I do address your substantive points which might go into a >>> discussion of an 8827-bis, but if you agree with me here, we don't need to >>> reach those here. >>> >>>> >>> >>>> >>> >>>> >>> >>>>> On Dec 11, 2023, at 7:13 AM, Eric Rescorla <ekr@rtfm.com> wrote: >>> >>>>> >>> >>>>> Let's make sure that we agree on the substantive situation first. >>> >>>>> >>> >>>>> * DTLS 1.3 deprecates DTLS 1.2, so a compliant implementation >>> should be able to use either. >>> >>>> >>> >>>> I suspect we disagree on what deprecate means but probably not >>> relevant to sort this out. >>> >>>> >>> >>>> I should have been clear: RFC 9147 obsoletes RFC 6347. As people >>> probably know, I'm not a fan of any of these tags, so I'm open to arguments >>> that this was wrong, but that's what it says. >>> >>>> >>> >>>> >>> >>>> I want to be careful on use or implement. For sure, I think it is >>> great for an implementation to support both and negotiate the latest thing >>> it can. >>> >>>> >>> >>>> >>> >>>>> * DTLS 1.3 is not yet widely deployed, so a compliant >>> implementation should implement 1.2 and 1.3, at least for now. >>> >>>> >>> >>>> Well, I think I am arguing they need to 1.2 to be a webrtc >>> complaint implantation and it would be very nice if they also do 1.3 >>> >>>> >>> >>>> Even worse that adoption, DTLS 1.3 is blocked by a significant >>> fraction of enterprise firewalls. I would like to keep webertc working in >>> those situations for now. I agree there is a point in time where we decide >>> that things that only do 1.2 just get left behind but I don’t think that >>> anyone is arguing we do that in Auth 48 of this doc. >>> >>>> >>> >>>> Absolutely not. >>> >>>> >>> >>>> >>> >>>> What I don’t want to be in situation of saying you must use 1.3 to >>> be webrtc compliant because I think that will cause a lot of breakage. >>> >>>> >>> >>>> 100% agreed. I also think it is reasonable to argue that we >>> shouldn't have MUST implement 1.3 (see below). >>> >>>> >>> >>>> >>> >>>>> >>> >>>>> Neither of these "shoulds" is intended in the 2119 sense, just in >>> terms of what we expect. >>> >>>>> >>> >>>>> Do you disagree with either of these statements? >>> >>>> >>> >>>> So just trying to reason my way through this. Look at it from point >>> of view of what we are asking implements to implement if they are compliant >>> with this RFC to be. Some various things we could be asking for are: >>> >>>> >>> >>>> A. Must implement 1.2 and may implement 1.3 >>> >>>> >>> >>>> B. Must implement both 1.2 and 1.3 >>> >>>> >>> >>>> C. Must implement 1.3 and Must NOT use 1.2 >>> >>>> >>> >>>> D. I guess a 4th option is could have a MUST implement 1.3 and but >>> is optional to implement 1.2 or not but that seems pretty much the same as >>> C from an interoperability point of view. >>> >>>> >>> >>>> >>> >>>> I was working on the assumption that we were doing A for this draft >>> because that is the situation for 8829 and we were not changing the TLS >>> version part of things in this draft. >>> >>>> >>> >>>> I feel very strongly it is too early to do C and it would be bad >>> for WebRTC to do C at this point of time. And this was caused me to think >>> the refs were not right in the draft. >>> >>>> >>> >>>> On B - I’m just not sure. Part of me feels like mandating this is >>> sort of like mandating webrtc must do both v4 and v6. I have no objections >>> to a very convincing argument either way. I do feel a bit like, is this the >>> right draft for this change. >>> >>>> >>> >>>> That make sense as way of clarifying a path forward ? I agree with >>> you that as long as we are clear what we are trying to get done, we can >>> figure out how to tweak the reference spices to get that taste. >>> >>>> >>> >>>> On the substantive matter, I totally agree that C and D are >>> nonstarters. I think it's between A (or maybe A' [MUST TLS 1.2 and SHOULD >>> TLS 1.3]) and B. >>> >>>> >>> >>>> -Ekr >>> >>>> >>> >>>> >>> >>>> >>> >>> >>> >> >>> > >>> >>>
- [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtc… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Murray S. Kucherawy
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <draft-… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Murray S. Kucherawy
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Sean Turner
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Sean Turner
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Cullen Jennings
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Eric Rescorla
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Ted Hardie
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9429 <dr… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Ted Hardie
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Sean Turner
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Justin Uberti
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Cullen Jennings
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Eric Rescorla
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Ted Hardie
- Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti… Lynne Bartholomew