Re: [auth48] AUTH48: RFC-to-be 9429 <draft-uberti-rtcweb-rfc8829bis-05> for your review
Eric Rescorla <ekr@rtfm.com> Fri, 15 March 2024 16:59 UTC
Return-Path: <ekr@rtfm.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 190DCC14F690 for <auth48archive@ietfa.amsl.com>; Fri, 15 Mar 2024 09:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.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 2Q1uWvDP9Kpz for <auth48archive@ietfa.amsl.com>; Fri, 15 Mar 2024 09:59:51 -0700 (PDT)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 0ECDAC14F68B for <auth48archive@rfc-editor.org>; Fri, 15 Mar 2024 09:59:51 -0700 (PDT)
Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-dccb1421bdeso2180128276.1 for <auth48archive@rfc-editor.org>; Fri, 15 Mar 2024 09:59:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1710521990; x=1711126790; darn=rfc-editor.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+Lb4cpAeyBeIErUV9/mCbVQYJEeNBFozaj6tG8g28dA=; b=nnSJKJnyMhWrT59pNvltexux9796N0zkSovHyTrS/wwydhKkwMJBQM7/C2RBatdXHX oRwYxrtYp6E0LCsamtZtFUxXmod9wZwwl7ZS4GqO15gfg/Qbmgb/YJSabUPVst3fCS45 0B3/JtWx4Ezqm9+HjqMlxXqxGwMpWs2i4HyLiiZvTWPir/C5+tY62vFulLTZ2Ufht1GW zOVsNIpKdSr4L0PkXmxZ6/dj9ygz7DiOnTj3ibaYa3T0G/Ia8rjZWEFE6mIvpUPRxV7e ZAowKUG5pytjfEM+/ad369+PonomYeIhruUwgGQFXzRDVYGiGvERcSrZsvAip+L2IpAk 2X1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710521990; x=1711126790; 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=+Lb4cpAeyBeIErUV9/mCbVQYJEeNBFozaj6tG8g28dA=; b=lWZCZTkJmgRt1/IhFbfyl+WCaPir8T+UHB89sApzERtiQeWeLDc5DIgBHRj8mGumiv Ng8efbAcSp2JD+79/X9Wb0hdpyHqcBMIsFBCKBdXj3fUD5dnpG3FHNEsmuO3vYW0mEjL uL0FXxppf2ebc8kFGjUc2RzAWqC3xtf/lVZYk6svRhf6Q8YtamgaSfEwgIQU22tKQBkv NWEUyjps7dpkeXS+YNiSntXI0BXKQg7NQ7bsxqH8f5SNQRYiJpVTYJfOwxnPrBfZ/TsZ pDiyW6aEd4kUlusEfSIr6A9AQ+dRLY4TdhFg9iM+GOM1YBezHF/VYYg/WNphK8G/O4Qg dNxQ==
X-Forwarded-Encrypted: i=1; AJvYcCUp02bgq0UgysclVNz+vOts1QOWLLyY8PBmyeWyg5aRmYva66C0NFCqZJaVyESm8jyMiHfP1cXjymsQQKQD6AkPVQ1tRy1nqKTB0NNP
X-Gm-Message-State: AOJu0YwsZExZO7wZ92kLiV+df5Y1eDCSdkhp5w7jJnBx0un8IHzsZf0k UgKcg1EA0tXkHuqVACtbF717roskEeR6CfqUuTdJDn6M07bV6h9ty3hJSmCnCxp42gG1Uc380ed kvkhSiKXLzspKol2SV4qvTE+HxJVfL9oodmeU0Q==
X-Google-Smtp-Source: AGHT+IG5xptv577Uf5lkVATHPaQyPmPhMkra0cnHUNM4DDq47KlggPDWeEC7uk5zq1C+kJaqD2eLOPxcx49qYvQpe1k=
X-Received: by 2002:a25:c5:0:b0:dc6:d738:1fa6 with SMTP id 188-20020a2500c5000000b00dc6d7381fa6mr5119896yba.6.1710521989936; Fri, 15 Mar 2024 09:59:49 -0700 (PDT)
MIME-Version: 1.0
References: <CALe60zA3386cz-dMN62Du2XbnY5=QRV-vG24qjsWZZJUKqyxdA@mail.gmail.com> <536B3389-3A89-44F8-B6F3-BFF562B26091@sn3rd.com> <8663B064-C16A-4E13-8123-B5805A28344B@amsl.com>
In-Reply-To: <8663B064-C16A-4E13-8123-B5805A28344B@amsl.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 15 Mar 2024 09:59:13 -0700
Message-ID: <CABcZeBP1xOy5T+Vb+1YtE_r9dvwsPz=fB4SRtB6AQoMpf6Vk5A@mail.gmail.com>
To: Lynne Bartholomew <lbartholomew@amsl.com>
Cc: Sean Turner <sean@sn3rd.com>, Justin Uberti <justin@uberti.name>, Ted Hardie <ted.ietf@gmail.com>, Cullen Jennings <fluffy@iii.ca>, "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="0000000000009757200613b5efa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/Crngy_rHxbMiUbdo9F6_FFpOLGk>
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, 15 Mar 2024 16:59:56 -0000
I need to find some time to read this, but at this point I think it will be after Brisbane,. On Fri, Mar 15, 2024 at 8:23 AM Lynne Bartholomew <lbartholomew@amsl.com> wrote: > Hi, Eric. > > Checking in with you regarding the status of this document. Please advise. > > Thank you! > > RFC Editor/lb > > > On Mar 4, 2024, at 3:39 PM, Sean Turner <sean@sn3rd.com> wrote: > > > > Many thanks Justin! > > > > spt > > > > Sent from my iPhone > > > >> On Mar 4, 2024, at 02:28, Justin Uberti <justin@uberti.name> wrote: > >> > >> I read through the latest diff and this all looks good to me, please > proceed with publication. Thanks all for your help to get this done! > >> > >> Justin > >> > >> On Thu, Feb 29, 2024 at 5:15 PM Sean Turner <sean@sn3rd.com> wrote: > >> Thanks! > >> > >> spt > >> > >> > On Feb 29, 2024, at 20:14, Justin Uberti <justin@uberti.name> wrote: > >> > > >> > 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