On Thu, Dec 6, 2018 at 11:24 AM Jared Mauch <[email protected]> wrote:
> > > > On Dec 6, 2018, at 9:05 AM, Spencer Dawkins at IETF < > [email protected]> wrote: > > > > Speaking as an individual who ballots on working group charters ... > > > > On Thu, Dec 6, 2018 at 7:38 AM Stewart Bryant <[email protected]> > wrote: > > > > > > On 06/12/2018 12:57, Gert Doering wrote: > > > Hi, > > > > > > On Thu, Dec 06, 2018 at 10:28:53AM +0000, Stewart Bryant wrote: > > >> However, aren't we moving to a world where new protocols get carried > > >> over UDP anyway? > > > Over HTTPS, you intended to say? > > Some and some. It depends on what aspect of the stack you spend your > > time thinking about. > > > > "you're both right" :-) ... > > > > As noted earlier in this thread, we punted new transport protocols into > UDP encapsulation at roughly the "we can't get SCTP deployed at scale, we > can't get DCCP deployed at scale, and we don't see any reason to think that > any new transport protocol will be any different" stage, at least a decade > ago. So, when I see people talking about SCTP, it's usually in a context > like RTCWeb, where the stack looks like SCTP/DTLS/UDP, and QUIC is only > defined over UDP. > > > > (I suspect the world would have been a slightly better place if we'd > done the DCCP encapsulation in UDP from day 1, because DCCP functionality > could have been really useful when we started encapsulating every known > network protocol in UDP, but that's not relevant to this discussion) > > > > But since QUIC's initial deliverable includes its HTTP mapping, > https://datatracker.ietf.org/doc/draft-ietf-httpbis-bcp56bis/ comes into > play. I would oversimplify that draft as saying "we are way more excited > about applications using HTTP as a substrate now, than we were in 2002", > so, yes, the future smells a lot like HTTPS over (mumble) over UDP, at > least to me. > > > > I don't know that's a perfect plan, but I've been balloting on working > group charters for at least 3 years, assuming that it's a plan. > > Yes, we’ve also seen the security/crypto all the things overreach impact > the routing area as well. We’ve not seen a suitable option to replace TCP > transport that is viable due to the timescales involved. I’ve provided > feedback at the mic in London in SAAG about the problems of this for people > who need very reliable transport, some level of transport security but do > not want or require transport privacy. > Jared, I'm not entirely sure I know what you're talking about here. If I recall your comments at the microphone correctly, they were about the challenges with TCP-AO. However, I wouldn't really call TCP-AO an example of security/crypto overreach. Rather, it was an attempt to fulfill what we understood to be asks from the routing area (key agility, a stronger algorithm than MD5). And of course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate on what you're referring to here? -Ekr > - Jared >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
